RE: Requirement for Isolated Request for Authorization Atributes

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Using URI's to denote roles is an interesting idea and seems to fit.

One of the issues that needs to be considered to build a usable system
is how to scope the trust in an issuer (of role or other assertion).

Folks might wisely trust Phill, but not Nigel to issue role/right
URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==

Thus some of the policy information a relying party will need to have
is who to trust for what. That requires a way if identifying issuers
and scoping what they can issue: sets of roles and resources. 

I think some/most will say that the structure of this information 
is out of scope for SAML. However, if we don't give some thought 
as to how this might work, we could end with very complicated 
configuration issues at each relying party. (From previous experience
I believe that if we do SAML right, we will be able to use SAML structures
to define this information, even though it is not an explicit goal.)

Nigel.

> -----Original Message-----
> From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Wednesday, March 14, 2001 7:07 PM
> To: 'Security-Core (E-mail)
> Subject: FW: Requirement for Isolated Request for Authorization
> Atributes
> 
> 
> [Darren asked me off list about the policy issue, so I 
> responded, then I
> thought that the response was probably worth forwarding to 
> the whole list]
> 
> 
> OK, so we are doing an XML standard and want to support multi-domain
> assertions. This leads naturally to the use of URIs to 
> represent resources.
> 
> So the file xyz.html is actually specified as 
> file://machine.alice.test/directory/directory/xyz.html
> 
> 
> We also have a clear need for what in VMS were called 'rights 
> identifiers'
> and some in the group are referring to as 'roles' (strictly 
> speaking a role
> used to mean a rights identifier that could be enabled and 
> disabled at will
> by an additional authentication step).
> 
> In XML space the natural expression for roles is to use a URN 
> since they are
> a pure name, they do not identify a specific resource:
> 
> URN:dns-date:irrelevant.test:2001-01-02:14.00.01:29482
> URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==
> 
> In neither case can the URN be 'resolved' to a resource, the 
> meaning of the
> URN comes from its use. It is similar in concept to the 
> xmlns="http://..."
> line that appears in much XML. The label does not actually 
> need to resolve,
> the semantics are not necessarily obtained by resolving the 
> URI. What is
> important is only that there are never two semantics bound to the same
> label.
> 
> 
> This approach naturally leads to the conclusion that the statement
> Alice is authorized to access
> file://machine.alice.test/directory/directory/xyz.html
> 
> is structurally the same as:
> Alice is authorized with the rights identifier
> URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==
> 
> In both cases the form is
> <Subject> is authorized for <Resource>[URI Reference]
> 
> 
> However the subject can also be usefully identified by a URI 
> reference.
> After all to disambiguate the account 'Alice', the natural 
> approach would be
> to add in her domain 'alice@nowhere.test'. Rather than tag 
> this form for
> disambiguity with XML I would rather push it down to the URI level
> "mailto:alice@nowhere.test".
> 
> so what we get is 
> <subject-URI> is authorized for <Resource-URI>
> 
> 
> So what is the statement made by:
> 
> URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789== [our 
> rights identifier
> URN]
> is authorized for
> file://machine.alice.test/directory/directory/xyz.html
> 
> 
> I think that the fact that the representation work well 
> indicates that the
> correct level of design consistency has been achieved. It 
> would be possible
> to 'design out' the expression of the policy statement but this would
> require considerable effort and result in a very rigid and 
> limited scheme.
> 
> 
> Now this is a policy statement but it is nothing like the type of
> 'capability' or 'ACL' like structures that are traditionally 
> associated with
> 'policy'. What I believe we all want to avoid touching is a 
> policy language
> or stating that this is a problem SAML should commit to 
> meeting requirements
> for. If on the other hand there is a useful subset of the 
> policy problem
> that can be encoded in this fashion, that is OK.
> 
> 
> 		Phill
> 
> Phillip Hallam-Baker
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> 
> 
>