<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 10/11/17 10:07 AM, Cantor, Scott
wrote:</div>
<blockquote type="cite"
cite="mid:3526D1A0-C5F1-40E5-8326-8BC4E7FBCD1D@osu.edu">
<pre wrap="">
Even SAML 2 artifacts are not *required* to use the hash as the SourceID. And the SP doesn't have any way to know whether it was or not at the time it makes the request. I might argue we should change how this is characterized in the draft but we did use the {SHA1} tag for this, which is a little odd. Ian might care to comment. </pre>
</blockquote>
Yes. I have actually been meaning to bring this up since I worked
on dynamic MDQ last year, and would up punting it from 3.3.0 b/c of
time. Probably would have when I get back to the dynamic resolver +
MDQ work (OSJ-181). But here goes.<br>
<br>
IMHO the issue with the {SHA1} thing right now is it assumes too
much about the actual on-the-wire implementation in use - at least
as far as supporting the SAML artifact binding, which I imagine was
the main driving use case. The feature isn't wrong in and of
itself. It's perhaps useful to specifically be able to say "here is
the SHA1 hash of an entityID, please resolve it."<br>
<br>
For SAML artifact though, as you say, the problem is that when the
requester (SP or IdP) sees an inbound artifact with a SourceID (SAML
1 Type 1 or SAML 2 Type 4), it does not in fact know that the
SourceID in the artifact is actually the SHA1 hash of anything. It
just isn't formally defined that way. It's a byte array. SHA1 might
be the 99.9 % case in the real world (or maybe not if one considers
the SourceID metadata extension), but it just sits very wrong with
me.<br>
<br>
It seems to me that an MDQ requester can only form questions to the
MDQ server/oracle based on data and knowledge that it actually has.
If what it has is a SAML SourceID, then that's probably the question
it should be able to ask. So something like {SAMLArtifactSourceID}
or something, could be shortened obviously. Or maybe it's more
generalizable to something like {OpaqueEntityIdentifierThingy}, or
whatever. Of course whether or not the MDQ server is configured to
answer that kind of question/profile is up to the particular server
and/or implementation.<br>
<br>
I also wanted to bring it up for purposes of thinking about possible
future extensions/profiles of MDQ. It seems to me they need to be
thought of as generally requester-centric (what kinds of question
can/would a requester need to ask), and less server-centric (what
kinds of questions does the server care to be able answer). <br>
<br>
Just my $.02.<br>
</body>
</html>