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

[Tom Scavo]

On Wed, Nov 8, 2017 at 9:59 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 11/7/17, 6:28 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>> The only thing that matters is what the responder does.
>
> I think this is the crux of the question.

Yes, I came to the same conclusion. I believe the SAML profile boils
down to the following three requirements:

- Each entity known to the responder MUST be associated with its entityID.

- Each entity known to the responder MUST also be associated with the
SHA-1 hash of its entityID.

- A responder MAY associate a particular entity with other
identifiers, including identifiers with the {sha1} syntax.

The latter could be tightened up, I think.

> I don't really share that view because it sits less well with me that clients are sending non-SHA1 data in the field if we believe that's somehow "wrong" to do.

Well, clients shouldn't have to worry about SHA-1, they should only be
concerned with the SourceID. From the client point of view, it's a
straightforward technical operation:

1. Base64-decode the artifact
2. Extract the 20-byte SourceID value
3. Hex-encode the SourceID value
4. Issue a metadata query using the {sha1} syntax

The use of the {sha1} notation is an unfortunate historical accident.
SHA-1 is irrelevant to the client.

> If others don't have a problem with that being done, then I'm not averse to just ruling that non-SHA1 cases just don't functionally work within the spec and leaving it at returning a 404.

Yes, that's my preference but if others want to give the responder
more flexibility, I'm okay with that as long as the spec is suitably
rewritten to guide the responder in the right direction. For my own
benefit, I rewrote section 2.2 along these lines (see attached). I
think that could be tightened up a bit, though. I was trying to give
the responder some flexibility since I thought was desired.

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MDQ protocol patch.pdf
Type: application/pdf
Size: 62558 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20171108/c048410a/attachment-0001.pdf>