RE: [security-services] Proposal: Query Extension for SAML AuthnReq

[sampo@symlabs.com]

Scott Cantor wrote:
>> 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.

Failing to make matadata madatory was great disservice to the
community.

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

Any one claiming to support an extention MUST support it properly.

The point is that vendors who claim to do it, must be obliged to
do it correctly or else not claim. If customer puts in RFP
a requirement that extension MUST be supported, then the vendor
can't pitch unless they support it correctly.

That being said, until there is certification of deployments, you
can't really mandate much behaviour on them. Many vendor implementations
allow the extenstions to be turned off or only partially honored, e.g.
by interpretting the requested attributes in different way and
returning whatever set of attributes they feel like. SP has to be
on guard at all times. Nevertheless, in deplyments, it is hoped
that expressing the required attributes leads to greater chance
of success.

> Just some thoughts to complicate the issue.
>
> -- Scott

Should I create a new cut of the draft with this feedback or do
we need more discussion?

Cheers,
--Sampo