OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-bindings message

[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