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

[Tom Scavo]

On Mon, Nov 6, 2017 at 9:25 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> I may not be interpreting the diff correctly but I think you're
>> basically saying that a client may use the {SHA1} syntax even if the
>> identifier that follows is not a SHA-1 hash (let alone the SHA-1 hash
>> of the entityID). Ugh. The MDQ protocol spec isn't even published yet
>> and it already has an inherent bug.
>
> It will never be published, so it is what it is. It's a meaingless issue in the scheme of things. The {SHA1} syntax

I think you may have misunderstood me. I'm talking about the MDQ
protocol spec. IMO, if the client uses the {SHA1} syntax, and the
responder can not map the hash value to an entityID, that's it---the
responder's job is done. There shouldn't be any normative language
beyond that.

For instance:

<quote>
Responder implementations MAY support arbitrary mappings of entity
identifiers to SAML artifact SourceID values that are not actual
digest values. Because clients have no way to distinguish such cases,
they would be expressed with the same syntax.
</quote>

That statement doesn't clarify anything for MDQ clients or responders.
Moreover, the above normative requirement is wholly redundant by
virtue of section 2.2.3. Additional Identifiers.

>> However, you can't say the same thing about entities that support the SAML2
>> artifact profile. AFAIK, there is no such extension element for SAML2.
>
> The extension applies in either case.

The namespace prefix used in the metadata profile (saml1md:) makes the
intent fairly clear. If there's a corresponding profile for SAML2, I
don't know what it is. Can you give a reference please?

Thanks,

Tom