| RE: [higgins-dev] AuthZ observation |
|
Welcome to the OpenID recycling problem![1]
Or, more importantly, welcome to one of the primary reasons that XDI and
XDI link contracts (XDI’s portable AuthZ format) are based on XRIs –
so at the very lowest layer of the infrastructure you have the ability assign every
entity (User, Operation, Resource) that participates in a link contract (which ultimately
is just a set of "UserX has OperationY access to ResourceZ" assertions)
a persistent XRI (“i-number”). And at the same time assign them any
number of verifiably synonymous reassignable XRIs (“i-names”). That way, link contracts can use only the
persistent XRIs for all entity references, and real world authorities and applications
can assign and reassign semantic XRI names to these entities as needed. Personally, I don’t think there’s
a lot of choice, because requiring everyone using Higgins or XDI AuthZ to “disallowing
renames of entities” in their namespaces is about as practical as
requiring everyone to stick to IP numbers instead of using domain names ;-) =Drummond [1] See http://middleware.internet2.edu/idtrust/2008/papers/01-reed-openid-xri-xrds.pdf,
a paper I gave at the IDtrust Symposium three weeks ago, for an in-depth
explanation of the OpenID recycling problem. From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim Duane
made this observation: *
If AuthZ allows us to express something like "UserX has OperationY access
to ResourceZ", then we must disallow renames of entities. **
Otherwise, if the "UserX" or "ResourceZ" entities are
renamed, we have a problem where the AuthZ is disconnected. ***
Worse, if UserX is removed, and another one added, they will be unwittingly
granted access. This
is especially true if we allow the AuthZ to be managed by a layered CP, because
the underlying Context might be directly accessed to perform a rename, leaving
the upper "authZ CP" unaware of the fact that it has a disconnected
authZ statement. |