Re: [plasma] Binary value encoding in AuthenticationTypeWSToken

Dan Griffin <dan@jwsecure.com> Thu, 28 June 2012 23:16 UTC

Received-SPF: pass (mail108-am1: domain of jwsecure.com designates 157.56.237.149 as permitted sender) client-ip=157.56.237.149; envelope-from=dan@jwsecure.com; helo=BY2PRD0511HT001.namprd05.prod.outlook.com ; .outlook.com ;
From: Dan Griffin <dan@jwsecure.com>
To: Jim Schaad <jimsch@nwlink.com>, "plasma@ietf.org" <plasma@ietf.org>
Thread-Topic: [plasma] Binary value encoding in AuthenticationTypeWSToken
Thread-Index: Ac1UpEx2LOyAAUCbTlWCGw46xov1XAANO6kAACnfWTA=
Date: Thu, 28 Jun 2012 23:15:52 +0000
Message-ID: <B66E1F139A0F29418103E63A6124AC1C09FE08F6@BY2PRD0511MB427.namprd05.prod.outlook.com>
References: <B66E1F139A0F29418103E63A6124AC1C09FDFC0B@BY2PRD0511MB427.namprd05.prod.outlook.com> <018501cd54d9$3dae6c50$b90b44f0$@nwlink.com>
In-Reply-To: <018501cd54d9$3dae6c50$b90b44f0$@nwlink.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_B66E1F139A0F29418103E63A6124AC1C09FE08F6BY2PRD0511MB427_"
MIME-Version: 1.0
Subject: Re: [plasma] Binary value encoding in AuthenticationTypeWSToken
Precedence: list

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:jimsch@nwlink.com]
Sent: Wednesday, June 27, 2012 7:54 PM
To: Dan Griffin; plasma@ietf.org
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: plasma-bounces@ietf.org<mailto:plasma-bounces@ietf.org> [mailto:plasma-bounces@ietf.org]<mailto:[mailto:plasma-bounces@ietf.org]> On Behalf Of Dan Griffin
Sent: Wednesday, June 27, 2012 1:42 PM
To: plasma@ietf.org<mailto:plasma@ietf.org>
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?

Re: [plasma] Binary value encoding in Authenticat… Jim Schaad
[plasma] Binary value encoding in AuthenticationT… Dan Griffin
Re: [plasma] Binary value encoding in Authenticat… Dan Griffin
Re: [plasma] Binary value encoding in Authenticat… Jim Schaad