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

Cantor, Scott cantor.2 at osu.edu
Tue Nov 7 06:42:29 PST 2017


> I think you may have misunderstood me.

All I was responding to was the comment about it having a bug before it's published, and I was pointing out that we don't have any expectation it will ever move beyond the draft stage.

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

As long as it's understood that it doesn't have to be a hash, and that's all the change does.

> That statement doesn't clarify anything for MDQ clients or responders.

I disagree, obviously. Pointing out that a client could unknowingly send a value that isn't actually a hash of an entityID seems relevant.

> Moreover, the above normative requirement is wholly redundant by
> virtue of section 2.2.3. Additional Identifiers.

That section refers to something that would be labeled as other than {SHA1}. At least, that's how I understood it.

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

The prefix is both non-normative and just a matter of XML machinery, and the SourceID notion is not unique to SAML 1. There's no reason not to apply it.

-- Scott



More information about the mdx mailing list