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: composition of AssertionID (Issue: DS-4-04: URIs for Assertion IDs)

I took an action as noted in "focus group" minutes by Eve..

> NEW ACTION: Jeff to send out email about possible URI constraints and 
> identity definitions we should consider imposing in the case of SAML's 
> unique identifiers.

Below's what I came up with to kick off this discussion. It's organized like 

  Further thoughts...
  Notes and References...

There's many subtleties to all of this, and I've undoubtedly either/both 
overlooked some or made too much of some. It's taken a while to find and wade 
thru (or skim) applicable docs, and then write this up -- much longer than I'd 
originally thought, so apologies for its tardiness. It's time to have other 
eyes'n'minds take a look at this.



From the focus group minutes [1]:
> >- URIsForAssertionIDs: What are the pros and cons?  What other
> >  methods are there?
> DS-4-04: URIs for Assertion IDs: (still open after today)
> Eve, with help from Dave, gave a short tutorial on the problems with
> URI  identity in XML namespace names.

There followed a brief discussion in which we touched upon various aspects of 
this problem space. We terminated the discussion upon issuing the above "new 
action". (the discussion as-documented in the aforementioned minutes is 
attached below for reference [1])

Further background, in the form of the specs for AssertionID and Issuer from 
draft-sstc-core-07 are excerpted at [2].

Relevant, recent discussion on security-services@lists.oasis-open.org...

Hal said in 

> 5. In 1.3.1 I don't understand the intended purpose of AssertionID. 

PHB replied in

> The AssertionID provides a unique reference for the assertion. ...

> Within SAML 1.0 the principle use of an AssertionID would be to allow
> one assertion to reference another (see previous Tim discussion) thus
> allowing statements of the form `this assertion was constructed from
> that assertion'.

> The principle use of the AssertionID however would be in systems built
> around SAML, they provide the basis for audit and accountability for
> example. If a system is built that allows for second order logic
> (assertions may be true or false and other assertions may make
> statements about validity (c.f. TASS meta-assertions)), then an
> assertionID is essential. 


The stated purpose of the AssertionID element is as an "assertion unique 
identifier" [2]. The stated syntax of this identifier is a URI [3]. Implicit 
in this line of thinking is a notion that URIs may be created (aka "minted") 
in a globally decentralized, non-colliding fashion due to the properties of 
the URI "space" [4].

The following is stated in [2] about AssertionID..

> The URI is used as a name for the assertion and not as a locator. It
> is only necessary to  ensure that no two assertions share the same
> identifier. Provision of a service to resolve  an identifier into an
> assertion is not a requirement. 

Also, as far as I can tell, [2] postulates (in section 1.3) that a requester 
need supply only an assertionID in a SAMLQuery in order to obtain an 
assertion. It does not make clear any distinction between newly minting an 
assertion and retrieving an already-existing one.

Thus it seems that there is a tacit assumption in [2] that an assertion may be 
uniquely identified and minted/retrieved using only an assertionID, regardless 
of the quote above.

So it seems that an assertionID is being asked to both..

  A. identify, globally and uniquely, assertions;
  B. provide at least a hint about where to direct requests for minting
     or retrieving assertions. 

..but again, this is to a fair degree inferred from a rough, incomplete, draft 
spec ([2]).

Additionally, there are many subtleties to using URIs as identifiers rather 
than straight-ahead resoure locators. See the minutes of the "Future of URIs" 
Birds of the Feather session held at the 50th IETF meeting [11],


It is an arguably good design principle to separate functions between various 
data items such that their roles in life are unambiguous.

[2] already has an "Issuer" assertion element. If identifying assertions is 
predicated on using the tuple "assertionID, Issuer", and some method for 
guaranteeing non-colliding Issuer names is used (e.g. DNS domain names, and 
things built upon them), then the assertionID can be quite simple, e.g. an 
integer (as is done in PKIX [10]).

In using the "assertionID, Issuer" tuple to identify assertions, and also 
provide guidance about where to go to make requests about or for them, the 
role of the Issuer element may arguably be (too) overloaded. E.g. if the 
overall SAML design calls for assertions to (perhaps optionally) specify 
within their structure where a receiver of an assertion may go to make queries 
about the assertion, then the requirements for persistence and 
location-independence for that particular identifier may conflict with the 
requirements of simply globally and uniquely (and perhaps persistently) 
identifying the Issuer security domain.

So it may be the case that to..

  case 1) globally uniquely identify an assertion one needs the combination of 
"assertionID, Issuer",

  case 2) uniquely identify assertions in the context of a given security 
domain, one needs only "assertionID" (it doesn't need to be disambiguated from 
assertions from other security domains; in this case the assertionID starts to 
look a lot like a serial number),

  case 3) one needs to cover either of the prior cases, and also needs to 
specify where to go (and "how" to "go") to make requests to the security 
domain in question. I.e...

  <Issuer>some-issuer-identifier</Issuer>  -- perhaps optional
  <Source>saml://example.org/send-yer-SAML-based-requests-here   -- optional

Tho there are good arguments for not making Issuer optional (case 2), thus the 
overall set of identifying information might be structured something like 

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

Further thoughts...

There's tons of subtle-but-important details in all of this that need to be 
considered in nailing down a design. Some of them are..

D1. if one uses a URL or URL-like flavor of URI as an identifier, we need to 
specify how comparisons between said identifier and other blobs of data are 
made. [3] details some of these subtleties in sections 1.5 and 2.1. The 
lowest-common-denominator option of specifying that such comparisons are made 
by performing a byte-by-byte octet string comparison will only technically 
work if certain restrictions are specified for the URI-based values. The SAML 
specs may need to consider/specify/incorporate one or more or all of..

  * charset restrictions for all or some SAML elements,
  * charset specifications, and bounds on said specifications, for SAML
    elements whose value syntaxes are URI [3],
  * charset(s) specified/allowed by underlying protocols and interaction 
    thereof with the prior items in this list,
  * [perhaps others/more]

Of note is "Character Model for the World Wide Web 1.0" [14] which defines an 
algorithm called "String Identity matching" (in section 6), which has 
implications for the above. (it also has implications for SAML in general, see 

D1.1. See also [16] [17] for further musing about internationalization for URI 
and other identifiers.

D1.2. See also "Considerations for URI and FQDN Protocol Parameters" [18] for 
further musings about using DNS domain names and/or URI as identifiers in 
protocol elements.

D1.3. If URI are used as identifiers in protocol elements, software modules 
that handle them (this includes people as a boundary condition ;) may wonder 
just what the heck their semantics are, because their semantics can be so 
varied. "URI Relationship Discovery via RESCAP" [19] touches upon and 
enumerates these questions, as well as sketch a protocol-based approach that 
specifies a service providing such info. Additionally, the more recent I-D, 
"URI Resolution using the Dynamic Delegation Discovery System" [20], also 
provides some relevant background info.

D1.4. Registration issues -- URI (nee URL) schemes should be registered, same 
with URN namespaces. See [9] for pointers to relevant RFCs on how to 
accomplish such registrations.

D2. some-issuer-identifier -- should this simply be a DNS 
fully-qualified-domain-name? Should it be a URN [6]? Should it be something 

D3. use of URNs -- URNs have semantics of persistence and 
location-independence. Their use may or may not be appropriate in the context 
of SAML assertions depending upon the semantics of the thing they're being 
called upon to identify [6] [7]. E.g. it is questionable to use a URN to 
identity a given non-persistent, indeed likely ephemeral, artifact such as an 
instantiation of a SAML assertion. However, it is

D4. if URNs are used, what namespace identifiers are appropriate? Any? Only a 
selected one(s)? Formal or informal? [7] [12]

D5. the DOI work [13] is likely not appropriate for SAML's purposes due to 
that effort's Intellectual Property emphasis and also because of the implied 
(required?) dependency upon the Handle System. The latter is an nascent, 
intended-to-be-scalable-to-the-Internet, naming and name resolution system 
[13] (I haven't yet read the internet-drafts in detail).

D6. The emergent "Character Model for the World Wide Web 1.0" MAY have various 
implications for SAML's specification, beyond that noted in D1.

D7. IMHO, "tag:" URIs [15] are not appropriate for our problem space, given 
their present specification, but reading about them and the discussion thereof 
on the uri@w3.org list is educational.

D9. If an artifact is not persistent, then it's identifier may be reused under 
certain conditions. Something to keep in mind and think about.

Notes and References...

[1] URIsForAssertionIDs discussion, from Focus subgroup concall, 22-May-2001:


>- URIsForAssertionIDs: What are the pros and cons?  What other methods
>    are there?

DS-4-04: URIs for Assertion IDs: (still open after today)

Eve, with help from Dave, gave a short tutorial on the problems with URI 
identity in XML namespace names.

Thomas: The DOI people are working on this general 
problem.  (http://www.doi.org, http://www.handle.net/)

Eve: It would be acceptable to use URIs if we apply constraints.  E.g., 
they should be absolute (or even should be absolute URNs) and we should 
define what equality means.  Dave: Solving the "whole URI problem" is way 
bigger than SAML's scope.

Jeff: There was recently an IETF BOF on the future of URIs, and W3C was 
investigating these issues, but nothing has really happened.

Eve: See W3C's Character Model spec for recommendations on normalization 
and internationalized URIs.  (http://www.w3.org/TR/charmod/)

Dave: Cautioned that we have to be concerned with real-world websites and 
their behavior, which is not precisely the same as the standards.  For 
example, http://www.jamcracker.com and http://www.jamcracker.com/index.html 
point to the same resource, but how can people know that?  BobB: Aliases, 
symbolic links, etc. are a problem if you have policies on different 
aliases that conflict.

Hal: We can take a hard line on URIs for assertion IDs, but for resources, 
we may have to deal with the vagaries of real-world URIs.

Evan: URIs are opaque strings, and XML makes data's structure more transparent.

Hal: There will probably be more cases than just AssertionID where 
identifiers will have properties of uniqueness (RequestID?) and are just 
"internal to SAML."  We should pull out the description of these properties 
into a separate section and have it referred to from the various sections.

Hal: We should register a new URI scheme, e.g. "saml:"  Thomas: We could 
just use URNs and have the same effect.  Jeff: It's pretty easy to register 
a new scheme with IANA.  (http://www.ietf.org/rfc/rfc2717.txt)   Eve: It's 
surprisingly hard to register a new URN namespace 

NEW ACTION: Jeff to send out email about possible URI constraints and 
identity definitions we should consider imposing in the case of SAML's 
unique identifiers.

[2] from draft-sstc-core-07: 

> 1.4.2 Element <AssertionID> 
> Each assertion MUST specify exactly one unique assertion identifier.
> All identifiers are  encoded as a Uniform Resource Identifier (URI)
> and are specified in full (use of relative  identifiers is not
> permitted). 
> The URI is used as a name for the assertion and not as a locator. It
> is only necessary to  ensure that no two assertions share the same
> identifier. Provision of a service to resolve  an identifier into an
> assertion is not a requirement. 
> The following schema defines the <AssertionID> element: 
> <element name="AssertionID" type="string"/> 
> 1.4.3 Element <Issuer> 
> The Issuer element specifies the issuer of the assertion by means of a
> URI. It is defined  by the following XML schema: 
> The following schema defines the <Issuer> element: 
> <element name="Issuer" type="string"/> 

[3] Uniform Resource Identifiers (URI): Generic Syntax

[4] URIs encompass both URLs and URNs. The former [5] often (but not always) 
depend upon the Domain Name System (DNS) namespace, which enables the 
capability to mint globally unique URLs in a decentalized fashion. The latter 
[6] define a hierarchical namespace that is DNS-independent but centrally 
mediated [7] in order to provide "location independent identification of a 
resource, as well as longevity of reference".

This picture is from [8]...
        |         ________________                              |
        |        |  ftp:          |                             |
        |        |  gopher:       |                             |
        |        |  http:       __|____________                 |
        |        |  etc        |  |  urn:      |                |
        |        |_____________|__|            |                |
        |                URLs  |               |                |
        |                      |_______________|                |
        |                             URNs                      |

URIs, URLs, and URNs are described by a plethora of documents. An attempt to 
tie them all together is given in [9].

[5] Uniform Resource Locators (URL)

[6] URN Syntax

[7] URN Namespace Definition Mechanisms

[8] Naming and Addressing: URIs, URLs, ...

[9] Uniform Resource Identifiers: Comprehensive Standard

[10] PKIX Certificate and CRL Profile

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

[12] URI.NET -- a clearing house for information on URIs in general and on 
specific URI schemes and software

[13] Digital Object Identifiers, The Handle System
http://www.doi.org, http://www.handle.net/

[14] Character Model for the World Wide Web 1.0

[15] "Tag" URI Scheme
see also the thread on uri list "Proposal: 'tag' URIs", from  Tim Kindberg 


[16] Internationalization: URIs and other identifiers

[17] Internationalized Resource Identifiers (IRI)

[18] Considerations for URI and FQDN Protocol Parameters

[19] URI Relationship Discovery via RESCAP

[20] URI Resolution using the Dynamic Delegation Discovery System


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

Powered by eList eXpress LLC