OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: FW: Requirement for Isolated Request for Authorization Atributes


URNs do indeed (if they wish) refer to real, accessible resources; there 
are a bunch of RFCs that explain how one would do the mapping.  However, in 
practice you're right that URNs aren't usually accessed (dereferenced).

There's a reason why we may *want* to have role identifiers be real 
pointers to accessible/machine-readable resources.  I imagine that the 
universe of roles is not just flat; it can have order and structure (e.g., 
being a senior administrator might open up privileges that being a junior 
administrator doesn't, or something like that).  RDF or XML Topic Maps 
could be used to express an ontology of roles, and a role identifier could 
be a pointer into a definition in one of those languages that has a 
machine-understandable relationship to other role definitions.

         Eve

At 11:07 AM 3/14/01 -0800, Philip Hallam-Baker wrote:
>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
>
>...
>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
>
>

--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC