Re: Coming back to CREDENTIAL.

I noticed a lot of people were getting CC'd on here that may not be all 
that interested in the discussion, so I've moved them to BCC for this 
email. For anyone on that list, note that it's a public discussion on 
the webappsec mailing list which is archived here:

https://lists.w3.org/Archives/Public/public-webappsec/

Mike, if you're aware that certain people really do want to be CC'd 
here, please feel free to add them back.

On 09/01/2015 04:32 AM, Mike West wrote:
> On Tue, Sep 1, 2015 at 1:08 AM, Dave Longley
> <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>>
> wrote:
>
>> +1 - Password management has very few stakeholders that might have
>>  an opinion on the API (vendors of password managers are the only
>> ones I can think of) so I see little danger in forging ahead with
>> that recommendation as is.
>>
>>> Hooray.
>
>> +1 - Like you mentioned though, there may be a need to
>> change/narrow the naming -- as it depends on whether or not the
>> scope of the API ends up including other kinds of credentials and
>> federated login and so on.
>
> I think the goal is to be able to include other kinds of
> credentials, regardless of whether the initial thing shipped in UAs
> does so.
>
> How narrow would you like the naming to be?

I agree with that goal. I was only speaking to the situation where
others may push for the API to be limited to passwords
(and to defer the extensibility features for a later date).
If that's where it ends up, then I think the "credentials" terminology
should not be used and terminology like "passwordManager" should be
instead. Again, that's not my preference, however, as I'd like to see a
common, extensible, credential API created.

>
>>> I mean an earlier phase of discovery that enables the
>>> protocol-based `get()` you've outlined here. How does the browser
>>>  create an internal registry of stored identity credentials that
>>>  support a protocol?
>
>> In the Credential's CG work, your browser can discover a URL to
>> your IdP (given a user secret) and a JSON-LD document at that URL
>> declares the IdP's supported services.
>>
>> For other protocols, one approach could be to have the IdP register
>>  itself with your browser. So, upon visiting your IdP, it could
>> register a credential in your browser (with your permission) that
>> declares its supported protocols. That credential could later be
>> used to initiate the generation of an RP-origin-specific
>> credential. This requires some level of cross-origin stuff and a
>> prior visit to your IdP.
>
> I'd really like to come up with a scheme that doesn't require Google
> (to pick a random example) to add JavaScript to `accounts.google.com
> <http://accounts.google.com>`, because selling that to the login and
> security teams is going to be difficult at best.

My understanding is that the API we're creating is meant to make login 
on the Web easier and more secure. If it can meet those goals, I'd think 
that would provide sufficient incentive to add its use to 
`accounts.google.com`.

>
> That said, we've apparently adopted the discovery mechanism defined
> at
> https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig.
>
>  Do other protocols define similar discovery mechanisms?

I don't have enough direct implementation experience with various 
protocols to provide a good answer.

SAML 2.0 has a section on publishing metadata at a well-known location 
(Section 4 of 
http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf). 
An overview of the uses of this metadata can be found on Wikipedia: 
https://en.wikipedia.org/wiki/SAML_2.0#SAML_2.0_Metadata.

However, whether or not that optional feature (or similar ones in other 
protocols) are commonly found in implementations in the wild is another 
issue entirely.


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

Received on Wednesday, 2 September 2015 14:28:25 UTC