FW: PartnerID format

["Mishra, Prateek" <pmishra@netegrity.com>]

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] 
Sent: Tuesday, September 18, 2001 11:12 AM
To: 'Mishra, Prateek'
Subject: RE: PartnerID format


1. Agree

2. Scheme 4a

3. Support

4. a

N.B. An SHA-1 hash is 20 octets (160 bits) in length. I don't know if this
is a typo or you are proposing a truncated SHA-1 hash in 4 b.

I feel strongly about #1, but could live with #2 a,b,c or #4 b.

> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Monday, September 10, 2001 2:50 PM
> To: 'security-bindings@lists.oasis-open.org'
> Subject: PartnerID format
> 
> 
> Discussions at the f2f#4 and at the bindings con-call on 
> September 6, 2001
> raised several issues concerning the "PartnerID" component of a SAML
> artifact (Section 4.1.3, draft-sstc-bindings-model-05). I 
> have split the
> discussion into several sub-parts, so that folks can 
> separately agree or
> disagree with each sub-part. Please respond with a set of choices and
> rationale (if appropriate).
>  
>  
> (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.
>  
>  
> (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
>  
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>