Re: Subject: PartnerID revisited

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

(See substantive comments at the end.)

> Following the discussion on last week's con-call here are some
> voteable proposals:
>
> (1) Proposal that the bindings group DROP further consideration of
> the "modified" SAML artifact proposal, wherein the SAML artifact
> contains some "bounded-size" URL which can be directly used
> as the address of a artifact-to-assertion-lookup service.
>
> Agree/Disagree
>
> [NOTE: There appeared to be consensus on the con-call to agree with this
> proposition last week, so here is your last chance to object!]

Agree.

> (2) Proposal that the bindings document be limited to precisely the
> following
> web browser profiles:
>
> (a) SAML artifact with a "small" bounded size artifact.
>      (because of URL size limitations in existing browsers)
>
> (b) FORM post.
>
> Agree/Disagree
>
> [I guess this is an "obvious" corollary of (1) but its always good to
>  be concrete]

Agree.

> (3) Each site implementing the SAML artifact profile MUST select
> a "Partner ID" URL. This URL MUST be drawn from a namespace owned or
> controlled by the site. There are no further requirements for this URL, it
> does
> not
> have to be the address of a web page or a service or anything at all.
>
>
> Agree/Disagree (please provide alternative and rationale)
>
> [NOTE: This corresponds to the notion that the URL is being used to "name"
>  the site only. We have given up on the notion that it stands for a "real"
> resource or service]
>
>
> (4) The SAML artifact be architected in the following way:
>
> TypeCode: 0x0001
> Partner ID: 20 byte SHA-1 hash of URL associated with the partner
> AssertionHandle: exact format TBD but maximum size of 20 bytes.
>
> Agree/Disagree (if you disagree please give rationale and alternative)
>
>
>
> (5) [Bob Morgan] Proposition (4) overly constrains the PartnerID format.
> Its format should be left unspecified but with a maximum size (20 bytes).
> However, we would RECOMMEND that sites use the approach of (3) and (4).
>
> [After all, why should SAML intervene if a source site chooses to negotiate
> a partner ID with each of its destination sites or use some peculiar
> PartnerID convention with each of its partners?]

>
> Agree/Disagree

Regarding all the above, let me clarify my point that you refer to in (5).

I think it is good practice to distinguish between (a) the proposed
artifact format:

 TypeCode: 0x0001
 Partner ID: 20 byte value, must be unique among participating sites
 AssertionHandle: 20 bytes, must have some TBD uniqueness/unguessability
                  properties

which is a fine format IMHO, and (b) a particular registration scheme, as
defined by (3) and

 Partner ID: 20 byte SHA-1 hash of URL associated with the partner

This is in the same way that we distinguish between the DNS as a protocol,
and particular registration schemes such as top-level domains based on ISO
two-letter country codes.

If you look at SAML overall, the specification of lots of elements remains
wide-open (eg, Issuer, Subject) and will, I think, be profiled for use by
particular deployments.  At this point this is a lot of what we're doing
in Shibboleth, eg when we say a Subject NameIdentifier has to be generated
in a privacy-preserving (aka blinded) fashion by a Shib-compliant issuer.
So I think the SAML spec has to be alert to not going too far into doing
what deployments have to do; that is, not to preclude legitimate
differences between deployments.

So I think the Artifact specification (and btw it's time to come up with a
better name than "artifact", isn't it? wish I had one) can normatively
specify the size of the fields and the general properties of the values.
But the proposed registration scheme can only be a suggestion at best.
Among other things, it seems to me it would need an operational registry
in order to be of actual use in the real world, else how would a relying
party receiving such an artifact know how to find the site that generated
it?  Description of such a registry would include generation rules such as
those above, but would be a different kind of document from the SAML spec.

 - RL "Bob"