Re: FW: Requirement for Isolated Request for Authorization Atributes

[Mike Wray <mjw@hplb.hpl.hp.com>]

>From: Philip Hallam-Baker <pbaker@verisign.com>
>Date: Wed, 14 Mar 2001 11:07:01 -0800
>Subject: FW: Requirement for Isolated Request for Authorization Atributes
>List-Post: <mailto:security-core@lists.oasis-open.org>
>
> ...
>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 some contexts it will be sufficient to support representing
resources as URIs - but this is rather inflexible. For one thing,
it supposes a hierarchical name space for resources. There is also
the problem of URI ownership  and uniqueness - anyone using a URI
to denote something needs to make sure it does not get confused with
someone else's use of the same URI to denote something else.
In e-speak we used the concept of Service Identifier to denote resources,
this was a user-definable structure. In XML terms this means using
an open content model where the resource identifier is allowed
to be an XML node. Of course a URI as character data or an element
is a particular case of that.

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

If membership of a role is expressed by conferring a role URI as an
attribute, any system processing assertions needs to be able to distinguish
an attribute used as a role from an `ordinary' attribute. This
is because a role attribute is processed differently. Essentially a role
functions as an implication - having the role implies having the
properties the role has.

An assertion processor also needs to be able to determine authority for
the role - who is allowed to assert possession of the role?
Again there is the problem of uniqueness or role URIs.
In SPKI this is addressed by using abstract names containing the
public key of the name space owner. Only that public key is allowed
to confer the role. This solves both uniqueness and authority.

SPKI also distinguishes conferring a role (which it calls defining a name)
from conferring an attribute. This allows SPKI processors to do the
right thing and treat roles appropriately.

Roles are integrated by allowing role names as subjects in 
attribute assertions - the role can be replaced by any subject
having the role. Roles can also be defined as other roles -
essentially this includes one role in another. This also supports
passing on the ability to define role membership.

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

A good point. Whether an assertion is policy or not is up to the interpretation
placed on it by its processors. SAML should not be restricted just
because some of its assertions might be used for policy purposes.

 
Mike Wray (mike_wray@hp.com)
Internet Security and Solutions Division
Hewlett-Packard