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

[Tom Scavo]

On Wed, Nov 8, 2017 at 5:59 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 11/8/17, 5:41 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>> If I said that, I lied, since the SourceID is 20 bytes by definition.
>
> No, the SourceID of a type 2 is the URL, which I think you noted.

No, The SAML V1.1 Type 0x0002 Artifact does not even have a SourceID field.

> The language in the spec treats it that way, or at least I think it does.

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

> I know my API does, rightly or wrongly, and has for a long time.

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.

>> I would say that's a problem. If you do that, how can a responder
>> detect malformed identifiers with the {sha1} syntax?
>
> By doing what we're more or less saying, treating it as an identifier that either matches something or doesn't. There's no such thing as malformed when it's simply a string that matches something the server knows about or not.

AFAIK, the MDQ server implementations out there today essentially
maintain three things: a list of entityIDs, a list of hashed enttyIDs,
and a mapping between them. So far all practical purposes, the MDQ
spec addresses SAML V1.1 Type 0x0001 Artifacts and SAML V2.0 Type
0x0004 Artifacts only. If you want to support SAML V1.1 Type 0x0002
Artifacts, implementations will have to maintain a list of
ArtifactResolutionService endpoint locations and a mapping between
them and the list of entityIDs. That seems like a lot of work for an
artifact type that is thinly deployed.

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

> SAML itself does not allow us to fix the fundamental fact that a conflict is possible. The spec was broken from the first day it shipped in this area because they didn't care about scale, only small circles of trust. SHA-1 was the nod toward scale, but you can't avoid a conflict if you can have one type of artifact with a mix of SHA-1 and non-SHA-1 source IDs.

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

> So if a server encounters metadata such that it would see the same SourceID apply to two different entities, that's a case it just has to deal with in its error handling on the back-end.

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

Tom