RE: Support for generic authentication tokens

I have to agree with Wan-Teh.

Certificates are commonly-used containers for private keys, and it seems useful for our APIs to be able to parse certificate properties to enable things such as key query. We saw specific use cases where this was requested (e.g. key query by certificate issuer, subject name, EKUs or chaining properties). That in turn implies that certificates need to be a first-class citizen in the API.

I don't think this necessarily means that other sorts of attributes shouldn't be first-class citizens. That said, I haven't seen a specific use case (leave alone one as widely applicable) citing the need for the crypto API to understand the structure of any other authentication tokens.

-----Original Message-----
From: Wan-Teh Chang [mailto:wtc@google.com] 
Sent: Friday, August 10, 2012 5:52 PM
To: Mitch Zollinger
Cc: public-webcrypto@w3.org
Subject: Re: Support for generic authentication tokens

On Fri, Aug 10, 2012 at 5:13 PM, Mitch Zollinger <mzollinger@netflix.com> wrote:
>
> Also, as "Certificate" is only applicable to public/private keys, its 
> inclusion in the Key interface seems a bit odd.

Certificates are common containers of public keys. This is why the crypto API should have the notion of certificates, especially for private key lookup/discovery.

Certificates don't need to be attributes of keys, but the API needs to provide a way to look up the private key associated with a given certificate.  This may just require us to store the public key as an attribute of a private key.

Wan-Teh

Received on Tuesday, 14 August 2012 16:35:33 UTC