Re: Overlap with Credentials/Web Payments CG (was Re: CfC to publish a FPWD of Credential Management; ending April 17th.)

Hi Brad, Wendy, Mike,

In many respects I agree with you that there appears only to be an overlap
in naming however I don't believe this makes this a trivial issue.

As you say the Credentials CG is working on very ambitious goals but I
think what also needs to be acknowledged are the significant amounts of
work that have already been done. The group has a large number of W3C
Member participants and intends chartering a WG very soon.

On the other hand we must acknowledge the scope and patent commitments of
the WebAppSec WG and the following stated scope and deliverable from the
group's charter:

Scope:

   - Providing hinting and direct support for credential managers, whether
   integrated into the user-agent or 3rd-party, to assist users in managing
   the complexities of secure passwords

Deliverable:

*Credential Management API*

Create and advance recommendation(s) for a standardized API to address use
cases related to assisted management of user credentials, including
traditional username/password pairs, username/federated identity provider
pairs. The API should allow for explicit and interoperable imperative
mechanism for use and lifecycle management of these common credential types.
Looking at the two excerpts above I don't see a good reason to exclude
input from the Credentials CG which it appears can only enhance the long
term usability of this API. In fact, I see a potential win-win for both
groups. On the one hand the WebAppSec group benefits from significant
research and hard work on the greater identity problem and on the other
hand the Credentials CG has the beginnings of a browser API that will
compliment their work already on the standards track.

If we compare the two bodies of work it is clear that there is some
disagreement around terminology. I believe that the Credentials CG/Web
Payments IG definition of a credential is probably more comprehensive and
would encourage those that haven't, to at least read the terminology
section of the Identity Credentials spec:
http://opencreds.org/specs/source/identity-credentials/#terminology

If I look at the type/interface definitions in the API spec I would suggest
the following but expect that other members of the Web Payments
IG/Credentials CG can provide further/better suggestions:

*Credential*
The Credential object (with properties of id, name and avatar) is really a
very basic identity. From what I can gather it's only use as a stand-alone
super-class is as the model for a rendered UI component that allows a user
to make decisions about the use of that identity (selection from a list
etc).

Proposal:
Rename this object to Identity and have a single property, a URL pointing
to the identity document that represents this identity. Where users choose
to store their identity in the browser this could be a URL that is
recognised by the broser as referring to local storage (eg: of the form
chrome://identity/123). The benefit of using linked-data is that the API no
longer restricts what can be done with the data that is discovered via that
URL.The identity document found at the URL could return the name and
avatarURL properties (or others that make rendering a useful UI control
even easier).

Further considerations:
Should this Identity be tied to an Origin? Wouldn't it be better if it was
linked internally to multiple origins where the user has given permission
for it to be used? If we consider this to be an identity that has multiple
credentials then we need to remember which credentials are shared with
which web apps so we can forget about tying an identity to an origin and
have this restriction at the more granular credential level.

Such a model means that when a web app requests a specific credential type
it is possible for the browser to return credentials from different
identities as the user chooses. i.e. The broser could be aware of both my
work and personal identity and when I visit a site that is able to provide
me with a combined user experience it could request and process credentials
from both.

*LocalCredential*
This object is a locally stored, login credential. It adds nothing to the
Credential object but a password and the algorithm for using it to submit
login credentials appears to simply submit this password as both the
username and password values of the HTTP POST form data? I assume this is a
typo, however I would suggest that using any property of the base
Credential as the "username" is very presumptuous. Does this mechanism only
support username/password pairs? Is it possible to support other scenarios
such as client certificates, OTP's, no username at all?

Proposal:
This object should match the definition of a credential from the Identity
Credentials spec and support the use of linked-data. Different credential
types can be reflected by simply using a different type identifier in the
object and the supported login credential types that a web app supports is
submitted in the get() request in a similar manner to the way the API
proposes the Federation identifiers are submitted as part of the options
object.

Under such a format the LoginCredential object would simply be one of the
credentials linked to the identity with the specific type of
"LoginCredential" or some PURL that is registered to define this such as
https://w3id.org/identity/#loginCredential.

To date the Credentials CG/Web Payments IG have only considered
signed-credentials as a means of validating the content of the claim but in
the case of a LoginCredential one could use other means such as passwords
(or more abstractly a shared secret) however I would warn against
perpetuating this anti-pattern. If a web app is going to exploit this new
API they can just as easily setup some more secure mechanism for ensuring
that the user holds some secret that was defined at registration.

The following identity document (from the spec) may be adjusted to fit this
purpose:

{
  "@context": "https://w3id.org/identity/v1",
  "@id": "https://example.com/identities/bob",
  "@type": "https://w3id.org/identity#",
  "credential": [{
    "@id": "https://example.com/identities/bob#login",
    "@type": "https://w3id.org/identity/#loginCredential",
    "signature": {
       "@type": "SharedSecret",
       "secret": "pa$$w0rd"
    }
  }]
}

*FederatedCredential*
As with the LocalCredential this could easily be supported using
linked-data where provider specific identities can simply be defined as
their own type. Example:

{
  "@context": "https://w3id.org/identity/v1",
  "@id": "https://example.com/identities/bob",
  "@type": ["Identity"],
  "credential": [{
    "@id": "https://facebook.com/user/1234",
    "@type": "https://facebook.com/federatedCredential",
    "claim": {
      "@id": "https://facebook.com/user/1234#identity",
      "name": "Bob Bobman",
      "birthdate": "1985-12-14",
    },
    "signature": {
       "@type": "GraphSignature2012",
       "creator": "https://facebook.com/keys/27",
       "signature": "3780eyfh3q0fhhfiq3q9f8ahsidfhf29rhaish"
    }
  }]
}

The get() options now become much simpler and yet more flexible. An example
supporting locally stored username and password or a Facebook federated
identity:

navigator.credentials
<https://w3c.github.io/webappsec/specs/credentialmanagement/#dom-navigator-credentials>.get
<https://w3c.github.io/webappsec/specs/credentialmanagement/#dom-credentialscontainer-get>({
  "types <https://w3c.github.io/webappsec/specs/credentialmanagement/#dom-credentialrequestoptions-federations>":
[ "https://w3id.org/identity/v1/#loginCredential",
"https://facebook.com/federatedCredential" ],
  "suppressUI <https://w3c.github.io/webappsec/specs/credentialmanagement/#dom-credentialrequestoptions-suppressui>":
true
}).then(function (credential) {
  // ...
});


As I suggested previously I think some close collaboration between our
groups over the next few weeks could result in a greatly improved spec that
is a benefit to both of our goals. While I respect the constraints you are
operating under I think we should not forget our higher goal of trying to
improve the Web platform.

To that end I am happy to commit time and resources to assisting in this
effort. Ripple Labs is a relatively new member of the W3C but we consider
this work hugely important. If it will help the cause for me to become an
active member of this WG then I am also happy to do so.

I don't wish to speak for them but I am sure that if you are willing to
delay the FPWD for a few weeks there are other members of the Credentials
CG and Web Payments WG who will make similar commitments for the sake of a
better API a few weeks later.

What is the most efficient way for this group to assist in updating this
spec?
How do we take this forward in a manner that both the Credentials CG and
WebAppSec WG benefit?

Adrian
Ripple Labs

On 14 April 2015 at 10:19, Brad Hill <hillbrad@gmail.com> wrote:

> I think the subject of this thread is an excellent summary of the core
> issue here, and the more I read, the more I'm convinced that the only
> overlap is in the name of this spec and the CG.
>
> The Credentials CG is working on a very ambitious project to reinvent how
> authentication, identity, federations and attested attributes are exchanged
> on the web.
>
> The Credential Management API is attempting to make incremental
> improvements to existing browser (and plugin) technology for ease-of-use
> affordances around saving what might accurately be termed legacy
> username/password and username/realm pairs.
>
> These differences are also in-keeping with the style and charter
> obligations of the different types of groups.  A Community Group has much
> looser patent commitments and a broader scope to explore and invent.  A
> Working Group is chartered with a specific scope, strong patent commitments
> within that scope, and member organizations *very* carefully review that
> scope before choosing to participate.
>
> Given that WebAppSec has just completed a rechartering, and the scope in
> that charter, I don't think that we _can_ work on something with much more
> detail than the abstractly extensible model that Mike has specified.
>
> The overall construction might be arranged differently, but getting into
> the details of things going on in the Credentials CG, which involves
> technology around payment instruments, claims, blinding, signatures,
> credential brokering, linked data formats, etc. is seriously beyond our
> charter and risks the ability for many of our participating organizations
> to continue to do so, were we to put it into the charter.  (and I don't
> think there is any energy or enthusiasm for another rechartering process at
> this time)
>
> Really, I see the goals and use cases targeted here as different enough
> that neither one is a threat to the other - even if they were to continue
> to share the term "credentials".
>
> But, unfortunately, as a point of order within this group, I'd like to ask
> that we confine discussion to the shape of the abstract API.  If we can
> improve it to make it more future-proof, we should of course do so, but
> providing a direct implementation for the Credential CG and Payment IG's
> use cases is not what we are chartered to do, members of those groups have
> not joined the WG or executed contributor's agreements, and we cannot take
> potentially encumbered technology into our specifications, especially that
> which is beyond our charter scope.
>
> Sincerely,
>
> Brad Hill
> Co-Chair WebAppSec WG
>
>
>
>
>