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)

Jeff Hodges wrote:


> Analysis...
> 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.


I do not think we need any property of the AssertionID except uniqueness. I
infer from Phill's response to a question of mine that he agrees.

I assume if you ask for an Assertion identified only by ID, you will get
that one or an error. I asked Phill to clarify what you get if you specify
Id plus other things and he agreed to do so.

While I am in total awe of the scholarship represented by you message, it
seems many of your concerns go away if we agree all we need is uniqueness.

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

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

How about:

Am I off base here? Do other people think we need to worry about all this


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

Powered by eList eXpress LLC