[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: FW: Requirement for Isolated Request for Authorization Atribu tes
> In some contexts it will be sufficient to support representing > resources as URIs - but this is rather inflexible. For one thing, > it supposes a hierarchical name space for resources. There is also > the problem of URI ownership and uniqueness - anyone using a URI > to denote something needs to make sure it does not get confused with > someone else's use of the same URI to denote something else. > In e-speak we used the concept of Service Identifier to > denote resources, > this was a user-definable structure. In XML terms this means using > an open content model where the resource identifier is allowed > to be an XML node. Of course a URI as character data or an element > is a particular case of that. Agreed, however I don't think we need to get into the specification of what the node structure actually is. I would see that as something that an extension schema, quite likely private. So we might have an assertion with a claim such as <Claim> <Subject>Phill H-B <Attributes> <nsa:profile> <nsa:BadgeColor>Gold <nsa:ShoeSize>7 <nsa:NixonEnemyList>No <nsa:NewWorldOrder>Charter Member .... > If membership of a role is expressed by conferring a role URI as an > attribute, any system processing assertions needs to be able > to distinguish > an attribute used as a role from an `ordinary' attribute. This > is because a role attribute is processed differently. I do not agree. > Essentially a role > functions as an implication - having the role implies having the > properties the role has. A resource can function in the same manner. > An assertion processor also needs to be able to determine > authority for > the role - who is allowed to assert possession of the role? In the case that a relying party is accepting assertions from multiple locations this issue has to be addressed. It is essentially an authorization issue. It can be addressed in a policy language or through SAML assertions Here the hierarchical nature of URIs is useful since the authorized issuer for a particular URI may be uniquely identified. > Again there is the problem of uniqueness or role URIs. > In SPKI this is addressed by using abstract names containing the > public key of the name space owner. Only that public key is allowed > to confer the role. This solves both uniqueness and authority. Back when SDSI was been developed I had suggested a URN that was tied to a public key for that purpose... These days the XML signature KeyInfo element serves the same purpose. I do not agree with Ron's assertion that the name space is entirely subjective and relativist. There is a clear intersubjective agreement as to who owns teenypop.com and a clear utility in maintaining that situation. If the DNS root did fragment then there could be a uniqueness problem in URIs. That is not the only problem there would be however. And in fact the resolution of the problem would be to simply add a 'fragment' element into the DNS name [teenypop.com.icann vs teenypop.com.idealab]. > SPKI also distinguishes conferring a role (which it calls > defining a name) > from conferring an attribute. This allows SPKI processors to do the > right thing and treat roles appropriately. Why does an ambiguity arise? If I am a processor attempting to determine whether a request to access bananarama.mp3 is valid there are three possible types of assertion statement I might have: 1) Direct file:teenypop.com/wherever/bananarama.mp3 2) Indirect - 'Role' urn:dns-date:teenypop.com:2001-02-20:Premium-Content 3) Indirect - 'Attribute' <tp:profile> <sex>female <age>13 <taste>none <subscription>premium <billto>daddy I don't see that a confusion of roles and attributes would occur, nor does a confusion appear between direct and indirect. Either the processor has enough information to make a decision or it does not. > Roles are integrated by allowing role names as subjects in > attribute assertions - the role can be replaced by any subject > having the role. Roles can also be defined as other roles - > essentially this includes one role in another. This also supports > passing on the ability to define role membership. This appears very useful to me, <Claim> <Authority> <Subject>URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789== <Resource>file://machine.alice.test/directory/directory/xyz.html Now if there is a genuine need to distinguish between a role and a resource I don't see a problem with <Claim> <Authority> <Subject>'Alice' <Role>URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789== But we might equally say: <Claim> <Authority> <Subject>'Alice' <Object>URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789== > A good point. Whether an assertion is policy or not is up to > the interpretation > placed on it by its processors. SAML should not be restricted just > because some of its assertions might be used for policy purposes. We need to be clear about the difference between a non-goal and an 'anti goal', something we must avoid permitting at all costs :-) Phill
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC