OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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:

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]