Re: composition of AssertionID (Issue: DS-4-04: URIs for Assertio nIDs)

[Jeff Hodges <jhodges@oblix.com>]

Phill wrote (in
http://lists.oasis-open.org/archives/security-services/200106/msg00057.html;
although I've extracted specific statements and altered their order a bit)...

> The reason for using a URI [for AssertionID] is that it allows the 
> issuer to tie the assertions in to the backend processing infrastructure 
> of their choice. 
> [...]
> Therefore SAML should not attempt to impose restrictions on the structure
> of the identifiers since these would be arbitrary.

These two statements are contradictory, because specifying that the syntax of
the AssertionID is a URI (e.g. by typing it as "uriReference" in the SAML
schema) IS imposing a restriction on the structure of the identifier. 

This highlights one of the key reasons why some of us are uncomfortable trying
to satisfy multiple requirements via a the postulated non-compound, elemental,
URI-based, AssertionID. 

These requirements are separable: on one hand you have needing to uniquely,
unambiguously identify assertions, and on another you have needing to provide
some basis for "[tying] assertions in to [some other] infrastructure" (to
paraphrase your words). 


> They MAY choose to issue identifiers that have internal structure, they MAY
> use random strings.

I nominally agree with this in the sense that if we were to nominally adopt an
assertion identification approach similar to this (as I've waved about in other
msgs in this and related threads)..

  <assertionID>
    <serialNumber>123123123123</serialNumber>
    <Issuer>some-issuer-identifier</Issuer>
  </assertionID>

..then I think we should consider specifying it along these lines..

  <assertionID>
    <id>AF1E43AAB9D5</id>
    <Issuer>some-issuer-identifier</Issuer>
  </assertionID>

..wherein the <id> element is explicitly of type "binary" (see section 3.2.8
binary, of http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/). This ~would~
allow implementors/deployers to put any structure they want (modulo some finite
length restriction) into <id>, including URIs (they'd just have to encode 'em
in either hex or base64). <id> in any case would still have the nominal
semantic of being simply a "serial number". 



> They are not required to make the assertions locatable but MAY choose 
> to do so.

And along the lines of the above statement, Phill said (in
http://lists.oasis-open.org/archives/security-services/200106/msg00087.html)..

> As far as identifiers go:
> 
> 1) Allowing the optional use of a URI for anything that is potentially
> downloadable means that if an application wants to provide that feature they
> may.
> 
> Thus allowing URLs as one form of assertion ID makes a lot of sense.


I feel that ensuring that any given assertion is "locatable" or "downloadable"
is separable from the particular syntax used for "assertion identifier" in the
sense that we can define a SAML-specific url scheme with which one may wield
SAML assertion identifiers. For example..

  saml://example.com/issuer/id

We could define that the semantics of this URI are that a SAML-speaking entity
SHOULD (if it wants/needs to dereference this SAML URI) contact "example.com"
using the SAML request/response protocol (SAMLRRP), and perform a SAMLRRP
operation (likely a request) on the assertion identified by "issuer/id". 

In defining something like there, there are no hard-and-fast requirements for
the thing identified by the URI to contain within itself that same identifier. 

Extant, deployed, examples of protocols having such an "external" URI scheme
are: FTP, LDAP, SMTP, NNTP/NEWS, telnet, etc. 

Anyway, the above proposal for a "saml" URI scheme and attendant URI definition
isn't an idle proposal -- I think it is something we should definitely do
(assuming that we do ultimately define a saml-specific protocol). I think it
will prove quite useful. 

JeffH