Simon:
>>For the people who want this draft published (and perhaps have a pending >>implementation), would you please humour me by offering some usage >>scenarios, other than debugging or toys, which would meet security >>review and which are not covered by the four points which the >>patent-holder notes as potentially encumbered? > > I'll offer one based on attribute certificates (see RFC 3281). If the > attribute certificate policy does not use a critical certificate > policy identifier that is within an arc registered to RedPhone > Security (e.g. iso.org.dod.internet.private.enterprise.23106), then > the most straightforward deployments would not encounter problems with > this IPR Statement. RFC 3281 specifies ways to carry access > identities, group memberships, roles, and clearances in attribute > certificates. As long as these are not coupled to signed agreements > such as contracts, as is their normal use, then I cannot see problems > with this IPR statement. What's the point of a certificate if you don't ultimately couple it with a contract? Identities, group memberships, roles, and clearances are all attributes defined by non-technical, real-world agreements, often documented in the form of a contract.
I can think of many that are not tied to contracts, especially in the manner described in the paragraph numbered 2 in the IPR statement. The authorization data needs to be used to "locate" the agreement. I've worked with many identification and authorization systems, and this is not a traditional aspect of any of them.
Russ
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf