Shibboleth Developers

[Tom Scavo <>]

http://shibboleth.internet2.edu/docs/draft-cantor-saml-sso-delegation-01.pdf

Nits:
- [line 320] s/representinga/representing a/
- [line 340] s/Muliple/Multiple/
- [line 366] s/included/included in the request/
- [line 370] s/included/included in the request/
- [line 374] s/included/included in the request/
- [line 381] s/element/element in the request/
- [line 451] s/$/>/  (This typo was probably copied from [SAML2Prof, line 
370].)
- [line 459] s/SubjectConfirmationData/saml:SubjectConfirmationData/
- [line 463] s/SubjectConfirmationData/saml:SubjectConfirmationData/

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

Questions:
- [lines 160--161] Do SPa and SPb reside in the same administrative domain?
- [line 248] s/access/authenticate to/  ?
- [line 326] s/authenticate and authorize/authenticate/  ?
- [line 386] s/establish/declare/  ?
- 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?

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.)
- 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?