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

[I reordered Hal's points slightly]

Hal Lockhart wrote:
> I do not think we need any property of the AssertionID except uniqueness. 

You of course mean "global uniqueness", because otherwise a
monotonically-increasing integer would suffice. 

> How about:
> saml://my.domain.com/AssertionID/something/meaningful/to/me/0000001

This is precisely what Issue: DS-4-04 is concerned with. The question therein is
essentially "is it a good idea to use a URL-style URI for something like

The research I did indicates that it is questionable whether it is a good idea
to simply use a URL-style URI as shown above and consider the "problem solved". 

> I assume if you ask for an Assertion identified only by ID, you will get
> that one or an error. 

Part of the question is "to whom do you address the request?". If the answer is
"you figure it out from stuff within the AssertionID", then I claim we're
(perhaps needlessly) overloading the semantics of AssertionID. Also, the claim
that "we [do not] need any property of the AssertionID except uniqueness" is

We have an "Issuer" element in both of the assertion schemas presently on the

We ~can~ choose to refer to assertions in a globally unique fashion by using a
"non-globally-unique-identifier" and Issuer together. I'm curious to hear
well-researched arguments about the pitfalls of doing so. One plausible approach
is to recast the AssertionID to look something like..


We will have to have a similar discussion about the syntax of an Issuer
identifier. I strongly suggest (i.e. agree) that it be based on DNS domain names
in some fashion -- I think that is quite semantically appropriate in this case.
But the exact syntax of the Issuer identifier will require some thought and we
should spawn yet-another-thread for that discussion. 

> I also suggest we not worry to much about uniqueness over long time periods,
> since assertions are stamped with both a issue instant and a validity
> interval.

Agreed. Thus it seems to me that if we refer to assertions using a combination
of "non-globally-unique-identifier, Issuer", the non-globally-unique-identifier
can degenerate to simply an integer of some (not terribly huge) size.

> I think we can go with byte for byte matching, 7 bit ascii, no escapes, no
> control characters, etc.

Yes, we will  have to carefully and precisely specify this sort of encoding
stuff for whereever URIs appear in our schema -- and also for our schema as a
whole. We need to take a good hard look at "Character Model for the World Wide
Web 1.0" <http://www.w3.org/TR/charmod/> at least at the point when we're
polishing our schema, if not before. I'm not a XML schema expert (INAXSE) -- I'm
counting on Eve & DaveO (at least) to be able to help out with such stuff --
i.e. answering questions like "can we do something more specific and appropriate
for designating in the schema, the precise syntax of elements whose values are
supposed to be 'URIs'?".


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

Powered by eList eXpress LLC