[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