[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Proposal: Query Extension for SAML AuthnReq
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]