Support for generic authentication tokens

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

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