Re: Solutions to the NASCAR problem?

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
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 03:39:34 UTC