Re: Support for generic authentication tokens

On 8/18/12 6:02 AM, Ryan Sleevi wrote:
> On Tue, Aug 14, 2012 at 5:44 PM, Mitch Zollinger <> wrote:
>> On 8/10/2012 5:44 PM, Ryan Sleevi wrote:
>> 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
>> 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 that Mitch and I are, I believe, in violent agreement that
> Certificates are not in-and-of-themselves attributes of Keys, in spite
> of what was discussed at the F2F, I've gone and removed them as
> attributes of Key.
> I think we're better served by having certificate queries independent
> of key queries, both from the potential for blocking (based on the
> underlying implementation) and for the possibility of user interaction
> being needed. This seems to suggest a query mechanism of some sort.
> While I don't have a particular proposal for this query mechanism, I
> would propose that in order to limit scope creep, and given that
> Certificates themselves are more aligned with our secondary API goals
> from our charter, that the current query mechanism be limited to just
> Certificates. This is partially to accomodate the fact that it's not
> clear what data is meaningful or applicable to the wider Internet
> community, so it's not clear what the constraints are for the API.
> Certificates, however, I would naively posit are "well understood"
> (there is a many-to-one relationship with asymmetric keys,
> particularly public keys).
> We should preface further discussion of this with
> / crypto-ISSUE-15
> Mitch, does that satisfy your needs?



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

Received on Tuesday, 21 August 2012 08:58:48 UTC