Re: Solutions to the NASCAR problem?

On 24/11/2015 03:38, Anders Rundgren wrote:
> On 2015-11-23 23:30, David Chadwick wrote:
>> the user has multiple key pairs, one pair for every web site he visits.
>> I called the user's key pair for the consumer site, the consumer SOP
>> public key (not to be confused with the consumer's own X.509 SSL key
>> pair). Is it clearer now?
> 
> No, you have still not told us *how* does the issuer get a copy of a
> consumer

I have talked to some fido developers and they have said that they can
give our code access to public keys. So assuming this is true, then our
code will send this to the issuer in a new message, asking for a signed
credential to be returned. This is all additional to standard FIDO messages

David

> public key (which it through SOP principles does not have any access to),
> without the user performing at least one manual operation (which in my
> guess would be like a one-time NASCAR thing).
> 
> Anders
> 
>>
>> On 23/11/2015 20:51, Anders Rundgren wrote:
>>> Hi David,
>>> This statement of yours is the only thing I don't get:
>>>
>>>   "The user sends the consumer SOP public key to the issuer and
>>>    the issuer assigns the attribute to that"
>>>
>>> How does the user send the consumer SOP public key to the issuer?
>>>
>>> Regards,
>>> Anders
>>>
>>> On 2015-11-23 21:21, David Chadwick wrote:
>>>>
>>>>
>>>> On 23/11/2015 18:14, Anders Rundgren wrote:
>>>>> On 2015-11-23 17:47, David Chadwick wrote:
>>>>>>
>>>>> <snip>
>>>>>>> Agreed.  I was actually referring to "my model" where key metadata
>>>>>>> plays a
>>>>>>> major role.  A scaled-down version of this can be found in this
>>>>>>> one-page
>>>>>>> doc:
>>>>>>> http://webpki.org/papers/decentralized-payments.pdf
>>>>>>> The certificate could surely be replaced by an account-ID, but I'm
>>>>>>> old-school you know :-)
>>>>>>>
>>>>>>
>>>>>> Your model is similar to mine, but is dealing with a step after mine
>>>>>> has
>>>>>> completed.
>>>>>
>>>>> To me they look pretty different.  There's no "before-step" in my
>>>>> model.
>>>>>
>>>>> When you have received your virtual credit-card, you can start
>>>>> shopping
>>>>> wherever you want.
>>>>>
>>>>>> Mine deals with presenting a credentail/assertion, then
>>>>>> stops. FIDO already has a process for OKing a transaction.
>>>>>> Comparing our models, your wallet is my authz module, your cert is
>>>>>> replaced by a FIDO key pair, so no identity is associated with the
>>>>>> public key.
>>>>>
>>>>> I still don't understand how your (per/site) credential bootstrap
>>>>> process works from a users perspective.
>>>>
>>>> That is the registration process. There are multiple ways of achieving
>>>> this
>>>> i) turn up in person - easy if the issuer is your employer or club
>>>> ii) send an activation code in the post to the users home
>>>> iii) use a set of registration authorities like banks or post offices
>>>> etc.
>>>> Everybody today has to register for all their credentials: passports,
>>>> driving licenses, credit cards, rail cards, bus passes etc etc. They
>>>> are
>>>> all tedious processes but essential to stop fraud since this is usually
>>>> the easiest place to crack.
>>>>
>>>> regards
>>>>
>>>> David
>>>>
>>>>>
>>>>>> The web site sends its authz policy to the wallet/authz module and it
>>>>>> compares this to the credentials held by the user. It either presents
>>>>>> matching ones for the user to choose between (more than one match) or
>>>>>> consent to (exactly one match) or say Sorry you cannot proceed
>>>>>> (insufficient credentials).
>>>>>
>>>>> I think I have got that.
>>>>>
>>>>> Regards,
>>>>> Anders
>>>>>
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> David
>>>>>>>
>>>>>>>> Usability is always hard to get right, but we have experimented
>>>>>>>> with a
>>>>>>>> GUI for over a year and think it is intuitive and easy to use.
>>>>>>>
>>>>>>> *This* is the thing I'm Interested in.  How is the consumer key
>>>>>>> sent to
>>>>>>> the issuer from a user perspective?
>>>>>>>
>>>>>>>
>>>>>>>> I am not aware of any additional security issues with this scheme
>>>>>>>> that
>>>>>>>> are not always present when users and technology are involved.
>>>>>>>
>>>>>>> You're probably right :-)
>>>>>>>
>>>>>>> Regards
>>>>>>> Anders
>>>>>>>>
>>>>>>>> regards
>>>>>>>>
>>>>>>>> David
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Anders
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>> Anders
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
> 
> 

Received on Tuesday, 24 November 2015 09:55:09 UTC