Re: Technical Review of WebAppSec Credential Management API [2/3] (was Re: Overlap with Credentials/Web Payments CG)

Brad,

You may have been referring to my mention of "identity".
To clarify I don't think the API should be called an Identity API I was
merely pointing out the fact that under the current data model, the base
Credential class is more of an "identity" than a credential.
The sub-classes LocalCredential and FederatedCredential are closer to
actual credentials.

I think we are all in agreement that there is a many-to-many relationship
between identities and associated credentials.
Also, I think most will agree that an entity (person) can have many
identities stored in many places (including locally).
I think trying to encapsulate this in the API would be (as you say) like
stepping into a tar pit. This is the challenge that the Credentials CG are
taking on and will hope to build on this foundation in doing so.

Personally I support the suggestion of having a Credentials class where the
type is defined by a property that is a URI as opposed to sub-classing
Credential.
(The spec may define a type such as PasswordCredential identified by a URI
like http://w3c.org/webappsec/credential/#passwordcredential or similar.)
Similarly, each FederatedCredential from each provider would be identified
by it's own URI.
This means there is no need for an "acceptPasswords" option either.

The get() call may look something like this:

navigator.credentials.get({
  types: ['http://w3c.org/webappsec/credentials/#password',
'http://facebook.com/oauthCredential',
'https://accounts.google.com/credentials']
}).then(function(...) {
  // ...
});


This provides scope for relying parties to accept obscure credentials in
the future that we haven't considered like government issued id's etc.

Adrian

On 15 April 2015 at 20:53, Keiji Takeda <tkeiji@w3.org> wrote:

> Hi all,
>
> Just for brainstorming, how about using
>
> "Security Credential Management API" instead of "Credential Management
> API."
>
> "Security Credential" is a common word in security domain and may fit
> usage in this context.  (Though it makes the name little bit longer.)
>
> Keiji Takeda (as an private individual)
>
>
> On 4/15/15 2:04 PM, Gregg Kellogg wrote:
>
>> Just want to add my voice to the chorus suggesting that there is overlap
>> between what WebAppSec wants to provide using their Credentials API and the
>> focus of the Credentials CG.
>>
>> Not that Wikipedia is the ultimate authority on all things, but their
>> definition [1] of Credential does seem more closely aligned with the goals
>> of the CG, whereas the Use Cases of the WebAppSec credential are focused on
>> login flows (obviously, this is in the charter of the WG), which aren’t
>> mentioned in the Wikipedia definition. To reduce confusion in the general
>> developer community that both of these groups are addressing, I think it is
>> important that any Credentials API be, at least conceptually, inclusive of
>> a broader use of the term Credentials.
>>
>> Manu said:
>>
>>  In the "Future Work" section, the spec suggests that perhaps this API
>>> could be used to mediate the relationship between people, identity
>>> providers, and websites. However, all credentials are stored locally in
>>> the browser, effectively limiting the "identity provider" to a very
>>> small set of super providers and then cutting them out from being able
>>> to provide more useful credential data.
>>>
>>
>> I agree that any FPWD needs to take into consideration uses of credential
>> beyond login, and “Future Work” should be consistent with the CG use cases,
>> if not describe them directly. Specific storage may be too narrow a
>> concern, but to the degree that the API is predicated on direct user agent
>> access to this information (as would seem to be indicated by the
>> restrictions on a promise), then the API footprint may need some room for
>> ping-pong like flows requiring a callback.
>>
>> Mike said:
>>
>>    I don't think anything in the proposed API would prevent interested
>>> folks from defining
>>> a `HotNewCredential` type, and offering it to developers.
>>>
>>
>> This works when there are a relatively few different types of
>> credentials, but the use cases promoted by the CG consider an unbounded set
>> of different credential types. An extension mechanism should probably start
>> from an abstract credential definition, and consider a more strictly
>> bounded login/password of federated login as instances of this.
>>
>> Wendy said:
>>
>>  As I see it, the chief inquiry here before FPWD is whether the proposed
>>> credential management spec in WebAppSec is incompatible with other
>>> technologies in use or in development, not whether there are bigger and
>>> greater things that could also be done.
>>>
>>
>> I think the bigger issue is the conceptual space carved out by the use of
>> the term “Credential”, particularly when it doesn’t align with one
>> well-known definition [1].
>>
>>
>> Brian said:
>>
>>   From my Outsider position, it appears that there is not a tremendous
>>> amount of conflict here.
>>> There are two groups doing good work that, at a minimum, bump into each
>>> other or
>>> will at least appear to publicly. I encourage the groups to collaborate
>>> and perpetuate the
>>> thoughtful and problem-solving perspective. I acknowledge that will take
>>> at least a
>>> short extra amount of time to find the overlap and opportunities to
>>> produce a superior
>>> set of standards, but I believe it will be worth it.
>>>
>>
>> Big +1
>>
>> Dave said:
>>
>>  There are a number of other details, some decided, some TBD, but below
>>> are some basic idea
>>> that I believe need to be known so that we can work together to future
>>> proof the Credentials Management API:
>>>
>>
>>  1. We use Linked Data for extending credentials.
>>> 2. We expect credentials to be stored by third party IdPs and the
>>> mechanism for fetching them to be standardized.
>>> 3. Once credentials have been authorized, they are typically authorized
>>> for use at a particular domain …
>>> 4. We'll need to consider that "credentials" aren't just "for login".
>>>
>>
>> +1’s, particularly on points 1) and 4).
>>
>>  As you mentioned earlier, I do think we could resolve these conflicts by
>>> renaming the spec to
>>> "Password Management API". Though, I think changing the name
>>> "Credential" to "Identity” would
>>> still cause conflict with the Credentials CG as we also use that term
>>> (something else would likely>
>>> be fine). That being said, I agree with Adrian that there could be a
>>> much greater upside if we work
>>> together to make minimal changes to the API and fill out the future work
>>> section in the spec with
>>> some of what the Credentials CG is working on (at least at a high level).
>>>
>>
>> I can definitely see the case for renaming the WebAppSec from Credentials
>> to Login or Password Management, but I think there is a great opportunity
>> to create room for more traditional uses of credentials as envisaged by the
>> CG; this should explicitly provide for an extension mechanism.
>>
>> Dave also said in issue #256 [2]:
>>
>>  One possible minimal change to future proof the API would be to make the
>>> Credential base class
>>> more generic and create a new LoginCredential class that extends it.
>>> That LoginCredential class
>>> is then the base class for LocalCredential and FederatedCredential. In
>>> the future, there would be
>>> something like LinkedDataCredential that extends Credential. Then, in
>>> order to select which path
>>> (legacy or future) you want to work with, you include that when making a
>>> call to navigator.credentials.get()
>>>
>>
>> +1 create a more generic class of Credential and make LoginCredential a
>> subclass of that; this leaves API space for a LinkedDataCredential (or
>> whatever) that the CG’s work can hang off of without running into technical
>> or conceptual incompatibility.
>>
>> In summary, I think the publication of the FPWD should be delayed until
>> these issues have been addressed to the minimum degree necessary to allow
>> for the CGs work. As the CG moves to become a WG in it’s own right, there
>> needs to be some way to either hand-off the work at the end of the
>> WebAppSec, or ensure that the spec supports extensions by other
>> specificaitons
>>
>> Gregg
>>
>> [1] http://en.wikipedia.org/wiki/Credential
>> [2] https://github.com/w3c/webappsec/issues/256#issuecomment-93427814
>>
>>
>
>