[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed core/bindings/profiles clarifications
For discussion tomorrow, here is a summary of proposed clarifications to the spec based on the questions that arose during the interop event. Most of them are minor, a couple are normative additions intended to clarify what I felt was intended in the original text, and one is a small schema fix to avoid clunkiness. This omits the authn context issue. I have fixed schemas for that in circulation before I apply the fix to the documents and invite some wider testing. Should be done this week. -- Scott A. Use of confirmation data in SSO profile Described here: http://lists.oasis-open.org/archives/security-services/200412/msg00028.html B. NameIDPolicy/@Format attribute Attribute should be made optional with associated processing rule in Authentication Request protocol to clarify that omitting or setting this to "unspecified" URN has the meaning "send me any type of identifier". C. Clarify use of NameQualifier in NameIDMgmt protocol Questions arose related to Thomas' earlier question about directionality. We need to add more clarification that name qualifiers (if they're used at all) are set at "creation" of the identifier and never change when using the persistent format. They can be omitted only when they match specific message/assertion content described in section 8.3. Subproposal: Is there a use case for name qualifiers with older SAML formats? I believe this is a source of interop headaches in SAMLv1. D. Clarify use of ProtocolBinding attribute in AuthnRequest Need to clarify that ProtocolBinding is mutually exclusive with AssertionConsumerServiceIndex in AuthnRequest. Also need clarification that metadata indexes are (as now described in that spec) unique within all like elements within a role. E. URL encoding in Redirect Binding Address some minor points here, such as that RelayState is to be omitted if no value is present, and that all parameters are to be URL-encoded before creating the string that is fed into the sign/verify operation. F. Sanity check on handling of RelayState in POST Binding I believe there was some misunderstanding or something, but the RelayState value (like any form value) has to be HTML-"safed" if you will, such as by replacing quotes with entities, etc. This is just basic rules of the road for forms. It's not a SAML thing. Need to add something to the effect that all the usual encoding is necessary here. G. Single Logout Questions http://lists.oasis-open.org/archives/security-services/200412/msg00063.html http://lists.oasis-open.org/archives/security-services/200412/msg00064.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]