Artifact metadata resolution in java OpenSAML and FU question on using the MDQ

[Brent Putman]

On 10/11/17 10:07 AM, Cantor, Scott wrote:
> 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. 
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.

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

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.

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.

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

Just my $.02.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20171011/1c57cd89/attachment.html>