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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [security-services] HolderOfKey and SenderVouches are slippin gthru 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>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC