Shibboleth Developers

["Scott Cantor" <>]

Thanks, with the caveat that I'm still actively trying to get rid of or punt
as much of this document as I can, mostly to Liberty at the moment.

> Bugs:
> - The NotBefore attribute on line 450 is not allowed 
> according to [SAML2Prof].

True, and these aren't ever pre-issued anyway, so it shouldn't matter.

> Questions:
> - [lines 160--161] Do SPa and SPb reside in the same 
> administrative domain?

I doubt it, or there'd be little reason to bother with all this stuff. All
our web servers have carte blanche, and I get laughed at if I even suggest
changing that when they see the work it would take.

> - In [SAML2Prof, section 3.1], it says the holder of the key is
> considered to be subject of the assertion.  The example in section
> 3.1.6 bends this rule, doesn't it?

No, it leverages it. "considered to be" is not the same as "is". I prefer
the language in the core spec that talks about "correspondence", and in
retrospect I like "associated with for the purposes of some profile" even
more.

BTW, you'll laugh, but that text is the product of weeks of discussion about
how to explicitly *not* rule out impersonation with holder-of-key (the old
1.1 text was much stronger on the "not allowed" side). I found the whole
debate pretty tiring, guess this proves it was also a waste of time.

Those sections are pointless anyway. SubjectConfirmation is totally
meaningless outside of a profile. Shared methods like holder of key are more
like design patterns or syntax suggestions. There isn't much benefit to even
having them, really, because every profile has its own code for dealing with
the implications.

I tried to get rid of HoK entirely on the grounds that the WSS-STP was the
place to define it. There should be an explicit statement about profiles
being the only way to interpret them, but there's not. All part of the
phantom implementer's guide.

> General (SAML2) questions:
> - Do either SubjectConfirmationData/@NotOnOrAfter or
> Conditions/@NotOnOrAfter implicitly refer to the lifetime of
> Subject/NameID?  (Yes, I'm still having trouble with the semantics of
> transient identifiers.)

No, not in the least. They refer to the window in which the confirmation can
happen in a profile, nothing more. Outside the window, you can just treat
the element as not present, but that doesn't mean anything about the rest of
the content of the assertion.

Transients have no requirement on lifetime whatsoever. They can be useless
the instant the assertion leaves the issuer or last for years (dumb, but
legal). The whole point is to not promise anything at all.

> - In [SAML2Core], it says a <subject> element SHOULD NOT identify more
> than one principal.  Allowing SubjectConfirmation/NameID in addition
> to Subject/NameID seems to contradict this goal, doesn't it?

The statement should probably have been worded more specifically to refer to
everything above the confirmations, but NameID got added to SC late. In any
case, the principal is the entity about which the statements are being made,
and subject confirmation doesn't modify that, it just controls who can
attest to an association with the principal in a profile (or in plain
English, it's who can use the assertion as a security token).

You can see why this stuff is so hard when features that were explicitly put
into the spec to support this use case (and which Liberty is using in that
manner) are interpreted as precluding it.

-- Scott