Assertions

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

Following on from Nigel's post we need to discuss the format of the auth
assertions themselves. I had hoped that we would be able to actually discuss
the subject at the F2F. 

Essentially there are two parts to the assertion, 'envelope' type data and
the data encoding the assertion.

In the X-TASS proposal I proposed that we do two types of auth data:

1) Using a URL to identify the resource to which authorization is granted
2) Using an extension schema

One question that then comes up is do we want to actually define an
extension schema?


Nigel pointed out:

>-----
>If I understand this correctly one of the key ideas is that URIs are
>used to denote authorizations. Determining the correspondance between
>URIs and resources to which access is granted is application
>specific. I think we should go a little further than this for SAML, as
>S2ML does, otherwise I wonder what degree of interoperability will be
>possible. 

I have been attempting to work out just what interoperability we get with
any scheme. Ultimately we can develop any scheme we like to define 
resource access permissions, however there will always be a point at which 
some sort of local configuration gets made. 

For example at the F2F bubble diagrams that appeared to consider the
following types of query were drawn:

[Attributes]	Is Alice Creditworthy? What is here height, weight and shoe
size?
[Rights]		Is Alice in the Finance group? What rights are
assigned to Alice?
[Resource]		Is Alice allowed to access the personel.html file?
What files can Alice access?


In addition we need to have a link to authentication data:
[Assertion-Holdership]	Presenting the assertion establishes authenticity
[Token-Holdership]	Presenting a token that stands for the assertion
[KeyInfo]			Link to symmetric or asymmetric
cryptographic keying material
[Username/Password]	Ugh
[SecureID type token]	Need to support


We also need a link to account information, consider the case in which there
is some charging mechanism associated with access. We need to know who the
accessing party is in this case so the right account is debited. 

In the general case however we might not want the relying server to know who
was accessing the server, merely that they were authorized to do so.


		Phill


Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

Phillip Hallam-Baker (E-mail).vcf