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] | [List Home]

Subject: RE: [security-services] AI#0087: Extending NameIdentifier schema

> I must say that this is one of the places where I feel that a 
> "loose bag of ANYs" approach to schema design would have made 
> our lives much easier. If the formal definition of 
> "identifier" is "a hunk of string or XML inside an 
> <identifier> element", profiles are then free to specify 
> encrypted things, new formats, or whatever they please. The 
> core spec should still define a useful base identifier 
> compatible with SAML 1.1, but the ANY would make everything 
> else possible.

I agree. That's more or less what I'm proposing as saml2:BaseNameIdentifier.

> So, to the specific use case: Currently our "Issuer" is a 
> URI, while our NameIdentifier is a two part name/namespace 
> pair. At first glance, we could easily define a specific 
> namespace for Issuers, and then just put the URI in the name. 

Spun slightly differently, I have a proposal for that in the last nameid
draft. I defined a format URI for a "provider", which we could call whatever
we want, I just used the Liberty term.

I of course used Format to mean syntax and semantics, not just syntax, and
didn't use NameQualifier in my formulation.

The key aspect is that the value is an identifier that would be expected to
have SAML metadata available on its behalf, which a principal would not

-- Scott

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