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

["Scott Cantor" <cantor.2@osu.edu>]

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

To increase the chance that the result will be successful, not to guarantee
it. I have that general sense across all of these issues. You can't assume
anything at an SP, what you're trying to do is put as much out there as
possible so that you limit the "access denied" results.

> If that's the case, then I contend
> that explicit RequestedAttribute elements in the AuthnRequest should
> be advisory as well.

I'm saying that there's precedent for one being advisory and one being
mandatory. I probably would argue it's more consistent to take that
approach, if it weren't for the general issue of extension criticality.

> 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 don't see a difference. There's no connection at runtime between the
existing index into metadata and passing attribute requirements by value in
a request. Those are two independent approaches that may happen to share
syntax. Same is true for the NameID example...the format URIs are the same
across both mechanisms, but they're otherwise independent, and one is
formally advisory and the other is mandatory.

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

The current interpretation is the former. I think maybe you're still
assuming otherwise?

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

Well, insofar as we're talking the existing mechanism that's not what the
spec says. And since all extensions are optional to understand, you can't
guarantee what an IdP will do if you send it this extension either. So in
both cases, I think the SP is left to assume nothing, and that's pretty much
the general rule in SAML.

The only question here I think is whether to write additional language that
says "if you understand the extension, then you MUST honor it". I'm not
objecting to that, I'm saying that *isn't* what we do now with the metadata
version of this feature. Your original statement was "they should be the
same". I think you're actually arguing they should be different.

-- Scott