[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Subject: PartnerID revisited
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!] (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] (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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC