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

["Tom Scavo" <trscavo@gmail.com>]

On Sun, May 4, 2008 at 7:59 PM, Scott Cantor <cantor.2@osu.edu> 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.

I don't disagree with that.

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

Understood.  In the case of AttributeConsumingServiceIndex, however,
what is the point of specifying such an index in the request if what
it points to is advisory only?  If that's the case, then I contend
that explicit RequestedAttribute elements in the AuthnRequest should
be advisory as well.

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

That's different since NameIDPolicy doesn't refer to metadata.
NameIDFormat and NameIDPolicy are totally independent.  Moreover,
recall that RequestedAttribute has an isRequired attribute.  I believe
that attribute gives RequestedAttribute more clout than NameIDFormat.

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

Right, so if the IdP can't or won't honor the SP's request, is it free
to return whatever attributes it wants or should it return an error?
For me, the answer to that question is fairly clear.  If the IdP can't
or won't satisfy the request, including any RequestedAttribute
elements by value or by reference, it should return an error, end of
story.

>  Just some thoughts to complicate the issue.

Yes, you're good at that, eh :-)

Tom