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

[Cantor, Scott]

On 11/8/17, 7:21 PM, "Tom Scavo" <trscavo at gmail.com> wrote:

> The SAML V1.1 spec defines the Type 0x0002 Artifact to have a
> SourceLocation field of type URI.

Fair enough. The API that I care about and am not changing nevertheless unifies the notion and treats them as the same thing.

> I don't know about that, all I know is that our MDQ profile does not
> support SAML V1.1 Type 0x0002 Artifacts. The PDF I attached earlier
> today makes this explicit.

Nevertheless the SP has been sending source locations in the {SHA1} field since I shipped the code.

> That seems like a lot of work for an artifact type that is thinly deployed.

I'm not asking anybody to do anything new, I'm just telling people what servers are going to receive. If they 404, then the result will be as with any other 404. If not, then it will work.

> Personally I don't think we should support SAML V1.1 Type 0x0002
> Artifacts. Doing so will break MDQ server implementations.

Saying they're allowed to do something doesn't mean requiring them to do it.
 
> I don't understand. A client should be able to detect the artifact
> type up front, but even if it doesn't, responder behavior should be
> well defined. (I keep saying that, I know. Tomorrow I will write down
> what I think that means.)

Consider the case of a type 4 artifact whose SourceID is the SHA-1 hash of an entityID and another one whose SourceID is the same, but was from a different entityID not using the SHA-1 convention and who just happened to pick that SourceID. It's up to the federations to prevent such a conflict, and since federations don't exist in SAML terms...you see the problem from a formal point of view. That's all I'm saying.

> If we assume 1) the entityID is globally unique, and 2) there are no SHA-1 collisions, then I don't see the problem.

Then you're ignoring artifacts whose SourceID is not the SHA-1 hash, which is the entire basis of this conversation. Either disallow them for the purposes of MDQ, or we adjust the text. What we won't do is change the syntax from {SHA1} to something else. So either allow that it's not always a hash because life isn't perfect, or ignore that it's not always a hash as being outside the spec's goals. The proposed change was to do the former.

-- Scott