RE: [security-services] HolderOfKey and SenderVouches are slippin gthru the cracks(!)

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Now it is my turn to get very annoyed.

Holder of Key is absolutely critical to our intentions for SAML. If SAML
cannot specify an attribute assertion whose subject is identified by the
holder of a key we have been sold a pup.

The processing model is irrelevant in that instance as Prateek points out.
There is nevertheless a need for interoperability between implementations.

The error the group has fallen into is the belief that the subject
confirmation is only relevant to an authentication authority. There is no
reason why that should be the case, nor any intrinsic reason why a SAML
installation should require such a server at all.

I know that some people would like to restrict the capabilities of SAML to
exclude this functionality but that is a mistake. The lack of a sanction in
the standard will not prevent that use, it will merely lead to incompatible
identifiers for the same function.

If we have to we will cut a URI off the xmltrustcenter.org arc but people
should not believe that blocking this in committee will block it in the
marketplace.

	Phill

> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Thursday, April 04, 2002 11:35 PM
> To: 'Jeff Hodges '; 'security-services@lists.oasis-open.org '
> Subject: RE: [security-services] HolderOfKey and SenderVouches are
> slippin g thru the cracks(!)
> 
> 
> Jeff,
> 
> I am not able to understand why it is helpful to define these 
> constants
> without providing a processing model for them. Indeed, you 
> will recall that
> even when the bindings group presented a concrete processing model 
> (e.g.,the SOAP profile) there was a fair amount of 
> controversy and effort in
> clarifying the role and meaning of these identifiers. 
> 
> It took a substantial amount of effort to characterize the intended
> semantics and even now I would say that "sendervouches" tends to upset
> people (and I dont just mean irving :-). 
> 
> [jeff]
> >I don't think they (HolderOfKey and SenderVouches) are necessarily
> >specific to
> >a particular profile, unlike eg artifact-01. Any number of 
> applications
> >of SAML
> >may make use of them. 
> 
> >E.g. some requester sending SAML queries via the SAML SOAP binding to
> >some SAML
> >responder for whatever purpose is an application of SAML and may well
> >need to
> >make use of HolderOfKey and/or SenderVouches. Such an 
> application's use
> >of SAML
> >may never be defined as a "profile". 
> 
> But in such a context the exact contents of the 
> <SubjectConfirmationMethod>
> are simply irrelevant to inter-operability. The SAML SOAP 
> binding transports
> queries to and responses from a SAML responder. The exact 
> format of the
> contents of a query or a response are constrained only by 
> SAML schema. Why
> worry about some specific constants here?
> 
> Finally, introducing these constants without context makes 
> them available
> for arbitrary use. As we have not provided any examples of 
> their use, it
> would be easy for a group of vendors to begin to use them in 
> some quite
> startling ways. At the same time, if we did retain them in 
> the SOAP profile
> we may end up with a nasty collision of semantics. 
> Admittedly, this can
> happen even in the presence of a detailed example of use but 
> is IMHO much
> less likely.
> 
> = prateek
> 
> 
> Therefore I think we can and should simply define them along the lines
> that I
> suggested. 
> 
> JeffH
> 
> ----------------------------------------------------------------
> 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>
>