[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