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: RE: [security-services] Proposal: Query Extension for SAML AuthnReq


> So there will be two methods of requesting attributes in conjunction
> with <samlp:AuthnRequest>:
> 
> 1. By reference via AttributeConsumingServiceIndex
> 2. By value via <md:RequestedAttribute>
> 
> Scott is working on (1) in conjunction with errata, and Sampo has
> proposed (2).  In the end, the two approaches should be semantically
> equivalent, that is, the normative language describing each approach
> should be the same.

Well, the errata isn't really critical path for this, what's there is
already "correct" so far as it goes.

If you're arguing that the in-band option should be equivalent semantically,
I'm not sure I agree in principal. As I said in reference to the errata,
stuff in metadata is interpreted loosely because we couldn't seem to explain
to the TC up front why the spec should require support for metadata.

If you look at, for example, md:NameIDFormat vs. samlp:NameIDPolicy, one is
treated loosely and the other has mandatory semantics.

I tend to think we want to maintain that kind of approach here. But that
said, extensions in SAML can't be mustUnderstand, so the effect is that you
can't force an IdP to honor it anyway. So we have to decide whether it's
better to just consider it optional to fulfill in all cases, or draw a
distinction between an IdP that supports the extension and one that doesn't.

Just some thoughts to complicate the issue.

-- Scott




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