Re: Support for generic authentication tokens

On Fri, Aug 10, 2012 at 5:13 PM, Mitch Zollinger <> 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:
> 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.)
> 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.

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

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.

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 - 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?

Received on Saturday, 11 August 2012 00:45:10 UTC