[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)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC