[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) http://lists.oasis-open.org/archives/security-services/200106/msg00025.html ..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 URIs 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 Group. The FURI BOF minutes.. Future of Uniform Resource Identifiers BOF (furi) [50th IETF, Minneapolis MN, Mar-2001] http://www.ietf.org/proceedings/01mar/ietf50-39.htm#TopOfPage A URI, of either URL or URN form, MAY be a resonable identifier for something if scrutinizing entities/parties have answers available to many of these questions... 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 instance? * 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 http://www.ietf.org/internet-drafts/draft-mealling-uri-rdf-00.txt 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 http://www.taguri.org/ http://www.taguri.org/2001-04-26/draft-kindberg-tag-uri-00.txt see also the thread on uri list "Proposal: 'tag' URIs", initiated by Tim Kindberg <timothy@hpl.hp.com>... http://lists.w3.org/Archives/Public/uri/2001Apr/0013.html 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 Requests. 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.. http://lists.oasis-open.org/archives/security-services/200106/msg00051.html 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.. <assertionID> <serialNumber>123123123123</serialNumber> <Issuer>some-issuer-identifier</Issuer> </assertionID> <Source>saml://example.org/send-yer-SAML-based-requests-here -- optional </Source> 4. XML-specific identifiers, e.g. schema type names and element names. They should of course follow the XML specs. JeffH
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC