RE: [security-services] ISSUE: NameIdentifier specification needs tobe clarified

[Scott Cantor <cantor.2@osu.edu>]

> <saml:Resource>
> (URI schemes are available for a number of different resource 
> types but none are recommended for use with SAML)

Does SAML need to recommend them? A URI references a resource fairly
unambiguously (normalization rules aside). The scheme pretty much
depends on the resource...

> Of this list, I think <saml:NameIdentifer> and 
> <saml:Attribute> need the most work. The specification does 
> not provide any guidance for these at all.

There was some text from RLBob discussing possible ways to use Namespace
as a syntax indicator, and then some examples for X.500 and such...

> I strongly oppose this proposal. My understanding of the
> current semantics of <saml:NameIdentifier> is as follows:

Minor nit...be careful about referencing attributes with the namespace.
Unless I'm mistaken, attributes in the SAML schemas are unqualified,
meaning they have no namespace and are in the global attribute
partition. I think if you namespace qualify them, you won't validate...

> (2) Name: provides the name of the subject. Often, this will take form
> of an X.509 DN, kerberos ticket, UUID or uninterpreted binary 
> string.

I thought things like tickets that were non-string-like went in
SubjectConfirmation...?

> Why do we distinguish between Name and Security Domain? Mostly because
> we expect Names to be drawn from a syntax with standard rules 
> for matching etc. It is useful to allow for an "unstructured" security

> domain component and a more structured name component. 

But if you want to be truly interoperable, don't the RP's need to know
what "structured syntax" a given Name attribute uses? Thus, Simon's
suggestion for a URI qualifier that describes the syntax, much as
AttributeNamespace might do for AttributeName...a NameNamespace if you
will.

-- Scott