I'm referring to how the client authenticates to Plasma in the first place, 
i.e. part of the work the client has to do before a single Plasma call is made. 
The client will have to know:


1.       What kind of credential to get

2.       Where/how to get it

3.       What Plasma AuthenticationType type to map it to

4.       How to do the encoding for that mapping

The draft text doesn't appear to address #3 at all. How can you expect 
interoperability? My first question remains unanswered.

From: Jim Schaad [mailto:[email protected]]
Sent: Wednesday, June 27, 2012 7:54 PM
To: Dan Griffin; [email protected]
Subject: RE: [plasma] Binary value encoding in AuthenticationTypeWSToken

Please let me know what text is unclear in the document.

This is A correct type.  There is no ONE correct type of token to be returned.  
This is strictly a choice of the server.  The server can use an XML based 
token, such as SAML or an ASN.1 based token, such as CMS or a non-structured 
token, such as an index in a database.

There is no requirement in the document that the client understand the token 
returned to the client.  In fact the requirement is just the opposite.  The 
token is to be treated as an opaque blob by the client.  If data such as 
lifetimes is to be returned they are returned as wst namespace attributes.

Jim


From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]]<mailto:[mailto:[email protected]]> On 
Behalf Of Dan Griffin
Sent: Wednesday, June 27, 2012 1:42 PM
To: [email protected]<mailto:[email protected]>
Subject: [plasma] Binary value encoding in AuthenticationTypeWSToken

We're using AuthenticationTypeWSToken to transmit a SAML token - is that the 
correct type?

If so, just wanted to clarify - the Value member of that type is a hex binary 
string, which seems like an odd choice. Wouldn't XML make more sense?

_______________________________________________
plasma mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/plasma

Reply via email to