Re: Use case: Authenticate using eID

On 2013-04-26 21:29, Richard Barnes wrote:
> On Apr 26, 2013, at 11:12 AM, Samuel Erdtman <samuel@erdtman.se> wrote:
> 
>> In addition to the privacy issue of the eID being a super cookie, in
>> Sweden the eID certificate contains pii that must not be accessible to
>> arbitrary sites. Are we going to ask the user to approve eID keys and
>> certificates to be accessed by different origins, should this
>> possibility be available for all certificate and keys or is it limited
>> to eID keys if yes how are they going to be identified as eID key.

>> This is getting closer to my suggestion that we could have a
>> certificate attribute for the origins that a key should be available
>> to.
>>
>> Sent from my iPhone
> 
> The above is a good summary of why non-domain-created keys aren't in scope for the current API.
> There are too many open questions.

IMO, Samuel's suggestion would be a suitable replacement for the current
much more limited Web Crypto proposal for addressing pre-provisioned keys.

A nice thing is that the exact method for specifying origin can evolve
without changing the API.  Long-term the "ACL" should be an attribute
associated with the key rather than being a part of the key itself
like in the Android Wallet.

Whats missing is a generic method for getting key attributes such as
certificates.

Anders


> 
> Managing access to things like eID keys sounds like a good area for some experimentation to happen.
> There might be some prior art to draw on from how TLS client certs are managed nowadays,
> but I'm not sure that will address everything.
> 
> This is something the PolyCrypt team is hoping to start playing with in the next couple of months…
> 
> --Richard
>

Received on Friday, 26 April 2013 17:20:38 UTC