[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: IMI TC Minutes, Oct 15th 2009
1. Call to order/roll call John Bradley Individual Scott Cantor Internet2 Marc Goodner Microsoft Corporation Michael Jones Microsoft Corporation Dale Olds, Novell Lost voting status None Gained voting status None 2. Approve minutes from previous call Sep 17th http://lists.oasis-open.org/archives/imi/200909/msg00007.html 3. SAML 2.0 token profile http://tools.oasis-open.org/issues/browse/IMI-24 http://www.oasis-open.org/committees/download.php/33841/draft-imi-saml2-profile-01.pdf http://www.oasis-open.org/committees/download.php/33840/draft-imi-saml2-profile-01.odt Questions, beginning of thread: http://lists.oasis-open.org/archives/imi/200910/msg00008.html SIP should be IMI 1.0 - Agreed In 2.3.3, why is the AuthnStatement mandatory, rather than optional? AttributeStatement cannot be required, it would require some statement to always be present which would be odd It is an authentication protocol, seems like it could always be present Claims could be transferred to RP that are not part of a authN step SAML protocol always requires AuthnStatement, so this requirement aligns nicely with those existing implementations AuthnStatement is between the selector and the STS, not to the RP, add clarifying language to call that out Agreed to add example to cover NameID 2.3.4 states that “The <saml:SubjectConfirmationData> element, if present, MUST NOT contain a NotBefore or Recipient XML attribute.” Why is that the case? The NotBefore restriction is copied from the SAML 2.0 SSO profile for use of bearer tokens and is just a way of avoiding spurious problems because there's no use case involving the attribute. The Recipient restriction is to avoid the need to special-case non-auditing cards and to deal with the fact that in the general case, IMI doesn't assume that the IdP has in hand the *location* of the RP endpoint (which is what Recipient is populated with). Expanded explanation here: http://lists.oasis-open.org/archives/imi/200910/msg00010.html In 2.4.1, why is the token type not urn:oasis:names:tc:SAML:2.0:assertion as per the IMI 1.0 spec example, rather than http://docs.oasisopen.org/imi/ns/token/saml2/200908, which seems like an unnecessary introduction of a new identifier? Mike to investigate impact of introducing new toke type to existing/upcoming implementations Section 2.5 on metadata, Scott has reviewed the WSFed text on metadata and believes this is clear enough that no other changes are required Section 2.6, needs more consensus on language, some cautionary language is warranted Suggestion to describe threats rather than a simple recommendation against the feature Agreed at minimum to add threat description Should have a new draft before next call 3. SAML 1.1 token profile http://tools.oasis-open.org/issues/browse/IMI-23 New draft: http://lists.oasis-open.org/archives/imi/200910/msg00009.html Name format convention not a MUST, use entire claim URI as claim name SHOULD accept in the split format, and encode in that format for claims that are URL General agreement on approach 5. Other business None Next call is Oct 29th 6. Adjournment |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]