W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

Support for generic authentication tokens

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Fri, 10 Aug 2012 17:13:55 -0700
Message-ID: <5025A3C3.5000308@netflix.com>
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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:
and the associated action ("Discovering certificates associated with 
(private) keys") is found here:

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.)

Received on Saturday, 11 August 2012 00:14:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC