OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: URIs as general-purpose identifiers, and identifiers in general

This message..

composition of AssertionID (Issue: DS-4-04: URIs for Assertion IDs)

..provides the references cited in the below discussion.

It's been asserted here in the SSTC that it is a good idea to use URL-style
as identifiers for various things. 

I did a bunch of research, and attended a BOF (Future of URIs (FURI)) at the
last IETF meeting on this topic, and the consensus is that THERE IS NO
CONSENSUS. Except there is consensus that there is a large amount of confusion
misunderstanding. The FURI BOF minutes will repay a careful read, imho. Oh, and
the FURI BOF was instigated by W3C folk involved in the URI Planning Interest

The FURI BOF minutes..

  Future of Uniform Resource Identifiers BOF (furi) 
  [50th IETF, Minneapolis MN, Mar-2001]

A URI, of either URL or URN form, MAY be a resonable identifier for something
scrutinizing entities/parties have answers available to many of these

      Identifier relationships: 
      *  Is this URI used as a name or locator?
      *  Is this URI globally available or do I need local information
         to use it?
      *  Is there a gateway available that can help me use this URI?
      *  Is this URI persistent?

      Resource relationships: 
      *  Is the Resource identified by this URI an abstract thing or an
         instance of one?
      *  If this Resource is an abstract Resource, can you give me an
      *  Is this Resource a collection or part of one?
      *  If this Resource is a member of a collection, what is the URI
         for the collection?

  [19] URI Relationship Discovery via RESCAP

For example, the "tag" URI scheme is attempting to define a URI scheme wherein
some of the above questions about relationships are answered in their design,
and would thus be useful as a more general-purpose identifier..

  [15] "Tag" URI Scheme

  see also the thread on uri list "Proposal: 'tag' URIs", 
  initiated by Tim Kindberg <timothy@hpl.hp.com>...

Although it's an interesting example of someone trying to address the
URI-as-general-purpose-identifier issues, the "tag" URI design is nascent and
not yet baked, so I'm certainly not advocating that SAML use it. 

Below's an attempt to sketch out the categories of requirements we have for
SAML identifiers, and note an approach for each..

1. Identifiers for relatively transient objects, such as Assertions and

The overriding requirement is for this to be "unique" in some context. If we
assume that we have another element within Assertions that identifies who, say,
issued the object, then these identifiers can be simple numbers. When needing
"global" uniqueness, we then identify the Assertion using the combination of
the Assertion identifier and the Issuer identifier. Request identifiers are
associated with the underlying protocol session -- thus establishing the
context (cf. LDAP MessageID) within which they are unique. Both of these
identifiers can even be reused since we're assuming that Assertions have a
validity period and Requests are associated with a particular underlying
protocol session (tho this claim requires embellishment and/or further thought
in the context of store-and-forward protocols). 

2. Identifiers that have the property of identifying the security domain, and
thus the administrative domain, issuing the Assertion. 

The specific example is "Issuer". Nominally, URN-style URIs or unadorned,
"absolute" DNS domain names (see RFC1034; aka "Fully-Qualified [DNS] Domain
Name" -- FQDN) can meet these needs (more about Issuer in another message). 

Of course one could use URL-style URIs here, but absent a scheme intended
specifically for use as an identifier (e.g. the proposed "tag" scheme), one'll
have a bunch of the subtle issues noted in the msg cited at the beginning of
this msg and also noted by Eve as "cf. XML Namespaces" in this msg..


3. Identifiers that provide "endpoint" identification/location, as well as
hints about the protocol, and protocol options/features to use, to "reach out &
touch a Resource". 

URL-style URIs are of course designed to meet just such a requirement. One
putative need for such a endpoint identifier in Assertions is one whose purpose
is to identify where to go to obtain more information about an Assertion, and
perhaps about the Issuer's Assertion services in general. An example (from the
msg cited at the beginning of this msg) is the postulated (and likely misnamed)
"Source" element..

  <Source>saml://example.org/send-yer-SAML-based-requests-here   -- optional

4. XML-specific identifiers, e.g. schema type names and element names. They
should of course follow the XML specs. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC