FW: Requirement for Isolated Request for Authorization Atributes

[Philip Hallam-Baker <pbaker@verisign.com>]

[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

Phillip Hallam-Baker (E-mail).vcf