NASCAR. Was: Use cases updated w/ glossary and roles

On 2014-08-01 18:39, Dave Longley wrote:
> On 07/31/2014 11:38 AM, Stuart Langridge wrote:
>> On 31 July 2014 16:29, Tim Holborn <timothy.holborn@gmail.com <mailto:timothy.holborn@gmail.com>> wrote:
>>
>>     On 1 Aug 2014, at 1:27 am, Stuart Langridge <sil@kryogenix.org <mailto:sil@kryogenix.org>> wrote:
>>     > could someone summarise what the NASCAR problem is?
>>     http://indiewebcamp.com/NASCAR_problem
>>
>>
>> Thank you, Tim! That's what I thought it might mean. I therefore think that the term is being overapplied in criticism of the use cases. Specifically, when people complain about the NASCAR problem I think that they mean that they get repeatedly presented with a million little icons all the time and they're almost all irrelevant almost all the time. However, the use case document seems to flag any solution as having a NASCAR problem if you are ever presented with a list of choices, even once. Michael Williams identifies that this is avoided by remembering the choice made, which seems sensible, but it seems to me that if the web payments initiative is specifically designed to allow me to choose between many ways to pay, then actually giving me that choice is rather inherent to the process, isn't it?
>>
>
> The NASCAR problem, at its core, is about who gets to set the available options, not that there are options that you may choose from. It's not really about the UI. The UI issue is merely symptomatic.
>
> In an ideal scenario, a person gets to define, for themselves, the set of options made available to them for performing a particular action on the Web. The current state of login on the Web is quite far from ideal; instead, the site you want to log into sets the available options and, in general, is only even capable of showing you options from a select few large identity providers. This limits competition in the identity provider space, creates lock in, leaks information to identity providers about the sites you log into, and prohibits people from being able to choose whatever identity provider(s) they want.
>
> So, solving this problem doesn't mean that a person wouldn't still be provided a UI with a set of identity providers to choose from. It means that the *person* gets to choose that set and that the person may put *any* identity provider that implements a standard protocol into that list.

Nicely described!

In my world not even the UI would be provided by the login-site, it would either be built-in as in WebAuth

     http://webpki.org/papers/PKI/webauth.pdf#page=4

or be provided by the login-site through issuer-defined signed code as in WebCrypto++

     http://webpki.org/papers/PKI/pki-webcrypto.pdf#page=2

Anders

>
>
> -- 
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com