[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: PartnerID format
Here are my choices: (1) Agree (2) (a) or (b) (ip address OR DNS domain name) (3) Oppose this suggestion [Concerns are noted below] (4) (c) [Concerns are noted below] >>(1) As currently written, PartnerID's are constructed in the >>context of a >>relationship between a Source Site and Destination Site. This suggests >>a single site may have multiple PartnerID's, each for use >>with a different >>a destination site. >> >>A number of folks at the f2f#4 argued that this was an administrative >>nightmare and that sites should be associated with a single >>unique PartnerID >>drawn from some "managed namespace". This would ensure that a source >>site could utilize a single PartnerID for all of its >>relationships with >>Destination sites. >> >> >>YOUR CHOICES: Agree OR Disagree >> >> >> >>(2) If we accept the change that a managed namespace is required for >>PartnerIDs, what should this namespace be? Please keep in mind that a >>bounded >>size SAML artifact requirement requires a bounded size PartnerID. >> >>(a) An IP address (4 bytes) >>(b) A DNS domain name (restricted to 30 bytes?) >>(c) arbitrary 4 byte string >>(d) a new namespace proposal >> >> >>YOUR CHOICES: One of a/b/c/d, for (d) please explain your >>namespace proposal >>and >>its strengths relative to (a) thru (c). >> >> >>(3) The assumption in (1) and (2) above is that sites >>continue to maintain a >>mapping >>table of the form: >> >> PartnerID X (Complete) URL for artifact-to-assertion >>lookup service >> >>Such a table would be maintained at each destination site and >>would consist >>of a list of pairs as shown above. >> >>It has further been suggested that we could eliminate this table by >>providing the >>(complete) URL for artifact-to-assertion lookup service AS >>the PartnerID >>within >>the SAML artifact. The destination site simply uses the >>PartnerID as the URL >>for >>the artifact-to-assertion lookup service. >> >> >>YOUR CHOICES: Support this suggestion/Oppose this suggestion. >> [Prateek] My concern here is this choice adds a more detailed layer of provisioning information into the artifact (and potentially into assertions). This level of detail is usually managed by a separate provisioning layer which operated independently of the flow of assertions between sites. By explicitly maintaining a table, we are allowing for a certain amount of important redundancy and checking. This includes, for example, determining whether the artifact has been received is indeed from a registered partner site. Recall, that the receipt of artifact is immediately followed by a callback to an "artifact-to-assertion lookup" service. This call MUST be mutually authenticated. If the destination site does not have a table with a list of valid partnerID's (in whatever form) it will not be able to determine the appropriate set of credentials for this partner. Therefore, we are not able to eliminate the need for a table of some sort at the destination site. A more minor but nevertheless significant issue is that testing and debugging is also impacted by removal of this table. It is quite reasonable that a destination site may choose to "ping" source site services to determine their visibility and availability. This is specially important before full deployment, e.g., when new partnerships are being staged and readied for production. Eliminating the partner table also has an impact in this space. >> >>(4) If we accept the change suggested in (3), we are left with the >>difficulty that >>PartnerID is no longer of bounded size. How can we meet the >>bounded size >>requirement for PartnerID's? >> >>(a) arbitrarily restrict PartnerID to some maximum size >>(e.g., 75 bytes). >>Note that >>this not as onerous a restriction as it may seem, as the >>source site can >>employ various mapping techniques to bind an actual >>ASP/JSP/Servlet to this >>address. >> >>(b) Support two types of PartnerID's: (i) size restricted URL >>(e.g., 75 >>bytes) >>(ii) SHA-1 digest of URL (8 bytes). Further, utilize the SAML artifact >>TypeCode >>and assign different type codes to each choice (e.g., 0x0001 >>and 0x0002). >> >>(c) I do not support the suggestion in (3), so I have no >>proposal in this >>space. >> >> >>YOUR CHOICES: One of a/b/c >> >> [Prateek] For reasons stated above, I would stay with (c) until convinced otherwise. >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC