[mdx] Small change proposed to draft-young-md-query-saml-07

[Tom Scavo]

On Wed, Nov 8, 2017 at 7:37 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 11/8/17, 7:21 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>> I don't know about that, all I know is that our MDQ profile does not
>> support SAML V1.1 Type 0x0002 Artifacts. The PDF I attached earlier
>> today makes this explicit.
>
> Nevertheless the SP has been sending source locations in the {SHA1} field since I shipped the code.

Claim: There are very few SP deployments using that code, and of those
few, even fewer have IdP partners that assert SAML V1.1 Type 0x0002
Artifacts. If there is even one such "perfect storm" deployment, I'd
be surprised.

>> I don't understand. A client should be able to detect the artifact
>> type up front, but even if it doesn't, responder behavior should be
>> well defined.
>
> Consider the case of a type 4 artifact whose SourceID is the SHA-1 hash of an entityID and another one whose SourceID is the same, but was from a different entityID not using the SHA-1 convention and who just happened to pick that SourceID.

That is a far-fetched example but even so the MDQ spec is (or should
be) very clear about what happens in this edge case. (I will followup
with an outline of server behavior in a subsequent message.)

> It's up to the federations to prevent such a conflict, and since federations don't exist in SAML terms...you see the problem from a formal point of view. That's all I'm saying.

Yes, I understand. As an aside, let me ask: Will the SAML
implementation profile be amended to address this issue? If every
implementation supported the SHA-1 hash of the entityID, then the
deployer would at least have the power to work around an integration
issue if one arose.

Tom