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: 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 

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:


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

This approach naturally leads to the conclusion that the statement
Alice is authorized to access

is structurally the same as:
Alice is authorized with the rights identifier

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

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
is authorized for

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.


Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
781 245 6996 x227

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