RE: FW: Requirement for Isolated Request for Authorization Atribu tes

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

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

Agreed, however I don't think we need to get into the specification
of what the node structure actually is. I would see that as something
that an extension schema, quite likely private.

So we might have an assertion with a claim such as 

<Claim>
   <Subject>Phill H-B
   <Attributes>
	<nsa:profile>
         <nsa:BadgeColor>Gold
         <nsa:ShoeSize>7
         <nsa:NixonEnemyList>No
         <nsa:NewWorldOrder>Charter Member
         ....


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

I do not agree.

> Essentially a role
> functions as an implication - having the role implies having the
> properties the role has.

A resource can function in the same manner. 

> An assertion processor also needs to be able to determine 
> authority for
> the role - who is allowed to assert possession of the role?

In the case that a relying party is accepting assertions from
multiple locations this issue has to be addressed. It is essentially
an authorization issue.

It can be addressed in a policy language or through SAML assertions

Here the hierarchical nature of URIs is useful since the authorized
issuer for a particular URI may be uniquely identified.


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

Back when SDSI was been developed I had suggested a URN that was
tied to a public key for that purpose...

These days the XML signature KeyInfo element serves the same
purpose.

I do not agree with Ron's assertion that the name space is entirely
subjective and relativist. There is a clear intersubjective agreement
as to who owns teenypop.com and a clear utility in maintaining that
situation.

If the DNS root did fragment then there could be a uniqueness problem 
in URIs. That is not the only problem there would be however. And in
fact the resolution of the problem would be to simply add a 'fragment'
element into the DNS name [teenypop.com.icann vs teenypop.com.idealab].

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

Why does an ambiguity arise?

If I am a processor attempting to determine whether a request
to access bananarama.mp3 is valid there are three possible types
of assertion statement I might have:

1) Direct
	file:teenypop.com/wherever/bananarama.mp3
2) Indirect - 'Role'
	urn:dns-date:teenypop.com:2001-02-20:Premium-Content
3) Indirect - 'Attribute'
	<tp:profile>
         <sex>female
         <age>13
         <taste>none
         <subscription>premium
         <billto>daddy

I don't see that a confusion of roles and attributes would occur, nor does a
confusion appear between direct and indirect. Either the processor has
enough information to make a decision or it does not.

> 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 appears very useful to me, 

<Claim>
   <Authority>
      <Subject>URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==
      <Resource>file://machine.alice.test/directory/directory/xyz.html

Now if there is a genuine need to distinguish between a role and a resource
I don't see a problem with


<Claim>
   <Authority>
      <Subject>'Alice'
      <Role>URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==

But we might equally say:

<Claim>
   <Authority>
      <Subject>'Alice'
      <Object>URN:random:a23jzw43598ay3w59aq53w9yh9aq53wh/aw3h789==

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

We need to be clear about the difference between a non-goal and an
'anti goal', something we must avoid permitting at all costs :-)

		Phill

Phillip Hallam-Baker (E-mail).vcf