Re: PartnerID format

[christopher ferris <chris.ferris@Sun.COM>]

Prateek,

<decloak>
Your concerns regarding #3, that the table, mapping a
partnerId to a URL, provides for the ability to check that the 
partner is a registered partner while valid, seem to miss the 
point that the URL-for-artifact-assertion-lookup-service could 
always be checked against a list of registered partner URLs.
</decloak>

Cheers,

Chris

<cloak/> 

"Mishra, Prateek" wrote:
> 
> 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>
> >>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>