Re: Support for generic authentication tokens

On 8/10/2012 5:44 PM, Ryan Sleevi wrote:
> On Fri, Aug 10, 2012 at 5:13 PM, Mitch Zollinger <mzollinger@netflix.com> wrote:
>> In our phone conversation on Monday, the topic of certificates as first
>> class objects in the Key interface came up. For reference, the interface is
>> defined here:
>> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#key-interface
>> and the associated action ("Discovering certificates associated with
>> (private) keys") is found here:
>> https://www.w3.org/2012/webcrypto/track/issues/15
>>
>> The issue I raised was that "Certificates" as first class objects related to
>> keys treats other authentication mechanisms (Kerberos, OAuth, etc.) as
>> second class citizens. Instead, I would like to propose one of:
>> 1. an "authentication token" which is paired with a key should be a generic
>> "AuthenticationToken" type or -- perhaps even easier -- use the proposed
>> KeyAttribute (KeyAttributes?) attribute instead
>> 2. the concept of an"authentication token" paired with a key be outside of
>> the Key interface
>>
>> Also, as "Certificate" is only applicable to public/private keys, its
>> inclusion in the Key interface seems a bit odd.
>>
>> Our preference is for #2. In the case of #1, we would be forcing a
>> 1(key)-to-many(authentication tokens) relationship. There are many cases
>> where that relationship does not work. Our current authentication protocol
>> has 8 different types of supported authentication and the relationships
>> between key & auth token is actually 1(key)-to-1(token) and
>> 2(keys)-to-1(token), where the later is the common case. The later case
>> (2-to-1) would be unsupported by tying an authentication token to a
>> particular key, unless we're willing to deal with the nuance of including
>> the token as data associated with two Key objects. (Seems a bit hackish.)
>>
>> Mitch
> Mitch,
>
> <editor hat>
> While I can understand the objection to the Certificate object as it
> relates to symmetric keys, I'm having trouble understanding your
> objections on "first class" or "second class" basis. It simply
> reflects the past discussions and seeming consensus of the WG, as
> expressed via our charter, our use cases, our phone calls, and our
> face to face discussions, which have concluded that there is interest
> in Certificates. With the exception of Netflix, I'm not aware of any
> discussions yet for any other types of authentication data, nor have
> there been specific proposals on how that mechanism may look - the
> intent was simply to capture that the WG had decided that such an
> association was "Important" and thus under consideration.

Let me restate the high level concern:
* It's fine to treat certificates as "first class" (assuming that the 
definition of first class is a recognized type / object as opposed to 
some opaque blob or concept) and treat other authentication tokens as 
"second class" blobs or opaque data.
* I don't believe that the Key interface should disallow the "second 
class" blobs in favor of the "first class" certs. It should either be 
inclusive of arbitrary types of associated authentication data or 
(better in my mind) leave the authentication data -- certs or otherwise 
-- as outside the scope of the Key interface definition.


> As I noted in ISSUE-15, it's not clear what the intended semantics
> are, but I think it's clear from past discussions that members are
> interested in some sort of standardized representation for
> Certificates - both as it relates to Keys (specifically private keys)
> and as it relates to the TLS information (as reflected in both the
> secondary API of the charter and the secondary use cases). If this is
> not the case, I'm happy to remove it (thus avoiding ISSUE-15
> entirely).

Clearly I am not opposed to this. (BTW, we use lots of certs, too, 
including X.509 public key certs.)

>   Alternatively, if you believe that these other token types
> are of interest to this WG and that consensus can be reached reached
> to add them, then I think it would be great if you could propose some
> text.

I'm not proposing that we need to treat these additional types as "first 
class" objects. Only that the API should not prevent either the 
inclusion of additional opaque authentication tokens or eventual 
inclusion of such tokens as "first class".

>
> There's nothing that prohibits both 1 and 2 from co-existing, and is
> by no means a statement of "first class" or "second class", although
> I'd agree that if the WG believes we'll go down a particular route, it
> would be nice to know early.
> </editor hat>
>
> Personally, I'd definitely agree with you that Certificates as an
> attribute of Keys seems a wrong interface, which is part of why I
> raised ISSUE-15. However, the change reflected our discussions of the
> F2F, and thus as an Editor it definitely seems appropriate for it to
> be added as the strawman discussed. I definitely agree with you that
> it does not seem appropriate to expose certificates as attributes of
> Keys, and would welcome any alternative proposals you have.

Given the 1-to-1, 1-to-many, many-to-1 and many-to-many possible 
relationships between keys and associated authentication data, I would 
propose that the coupling of keys to such data be more flexible.

Perhaps (given 1 minute of thought; please suggest something better):

|interface KeyAuthBinding {
   readonly attribute Key[] keys;
   readonly attribute AuthToken[] auths;
}

interface AuthToken {
   DOMString toString();
   Uint8Array toArray();
}

interface Certificate : AuthToken {
   readonly attribute DOMString issuer;
   readonly attribute DOMString subjectName;
   readonly attribute integer serialNum;
   ...
}| |

// not suggesting that OAuthAccessToken is in scope; just giving another 
example
interface OAuthAccessToken : AuthToken {
   ...
}
|
We wouldn't need a "special case" token, as we can simply use the 
AuthToken interface to get a DOMString or byte array. This also allows 
the specific "first class" Certificate interface if desired.

>
> In a practical sense, it would seem like Netflix's specialized needs
> could be met either by 1 or via whatever method is decided as part of
> ISSUE-17, so I'm not sure if the spec needs to change to specifically
> accommodate your data types. After all, the whole point of such
> extensibility is to represent data that is opaque to the spec and
> specific to the application, which your use case very much seems to be
> describing. It would seem like you're desiring a WebIDL definition for
> Kerberos or OAuth tokens

Sorry for the misunderstanding. We are definitely not looking for this. 
We can do most of what we need with an opaque token in version 1.

> - which may or may not be in scope for our
> current charter. Perhaps once we can advance a base API past WGLC, we
> or another appropriate group can look at re-chartering to address
> those needs.
>
> Do you have a proposal for #2 that we can discuss as part of ISSUE-15?

Something simple above. Of course, I'm not sure how the above proposal 
fits with the rest of the evolving spec.

Mitch