Identifiers in SAML

[Hal Lockhart <hal.lockhart@entegrity.com>]

My analysis of core-12 is that there are appear to three general kinds
identifiers in use.

1. Unique

Examples: AssertionID, RequestID (InResponseTo) and ResponseID

These need to be globally unique at least for the period of their validity.
Although it is true they are likely to be short lived, I suspect any
solution which allows them to be unique between independent administrative
domains which do not communicate with each other, will also make them unique
for all time. In any event I don't think it is wise to depend on the fact
that they have short lifetimes.

They are opaque from the perspective of anybody but the issuer, but the
issuer will need to be able to interpret them so as to find the thing they
refer to.

Anybody ought to be able to compare two of them and determine if they are
the same.

It seems to me the simplest scheme would be to combine a DNS name and some
locally meaningful number. I really don't see the need to worry about the
reissue of DNS domains like "tags" does, but I could be persuaded otherwise.
All of this suggests some kind of URI.

I think it is desirable that these id's NOT be dereferencable. IMO this will
just cause trouble. Given that, they should look like they are not
dereferencable. This means a URI tag that does not work, like "samlid:" Note
that a lot of software today will automatically treat anything that looks
like a DNS name as a link with "http:" in front of it.

Core-12 currently takes the position that any string is ok as long as the
implementation makes it unique. (negligible probability of duplcation) If a
random value is chosen it must be at least 128 bits and should be 160 bits.

My gut reaction is that we should specify more, but I can't honestly think
of any problem that this causes.

2. Unbounded Values

Examples: Issuer, Security Domain, Subject, Attribute, Resource or Object

These all have meaning external to SAML that is shared by more than one
party. While some communities of interest my want to define enumerated lists
of legal values, in general, the number of possible values will be
unbounded.

It is also interesting to note that in many cases the "meaning" of these
identifiers can remain completely outside of the security systems as long as
the processing rules are well defined. For example, one administrator can
configure an Attribute Authority to know that certain subject has attribute
X in domain Y. And another administrator can configure a PDP to know that
any subject with attribute X in domain Y is allowed to access object Z. And
the system will work just fine although only the admins have any idea what
it "means" to have attribute X.

The examples fall into two subclasses:

2a. Issuer, Security Domain

These would seem to stand by themselves and "feel" like DNS names somehow.

2b. Subject, Attribute, Object

These are implicitly or explicitly qualified by security domain (This is
clear for Subject and Attribute, less so for Object. But I am assuming that
the PEP is in a security domain distinct from at least one of the other
components, so it seems to me that objects belong to a security domain.) 

The domain could be specified as a distinct element, as core-12 does for
SubjectName and Attribute, or combined into some kind of URI as a single
element as others have proposed.

Core-12 does not specify an object security domain, but assumes the object
unambigiously identifies a particular resource. In some cases, object will
be a URI, but not in others. In the former case, it will be dereferencable,
but as the target of an application request, not as something to be
dereferenced by the RPs or APs.

3. Enumerated Values

Examples: AuthenticationCode, Action, Authentication Protocol, Status Code,
Completeness Specifier (perhaps)

All of these will have values drawn from relatively short lists (scores of
values at most) and have broadly agreed upon semantics. Currently some of
these are "hard coded" into core-12 others are just defined as strings with
the idea that the TC or other groups will define enumerated values.

It seems likely that these will be qualified by a namespace name.

Some would put Attributes in this category, but this seems doubtful to me.

I see no reason for any of these to be URIs.
-----------------------------------------------------
Final thoughts:

It seems to me like a good idea if these three categories all look different
from each other to help people understand their distinct characteristics. It
follows that if you disagree about the categories you will not agree with
this idea. In particular, the distinction betweeen #2 and #3 could be
debated.

It seems like a bad idea to use naked DNS names for anything, because of the
general tendancy to interpret them as a link prefixed with "http:".

Hal