dlongley
commented
7 years ago @AdamSobieski,
A less granular permission system might prompt users to select credentials to share with verifiers. A more granular permission system might prompt users as websites request users’ real names, dates of birth, citizenships, etc. It is possible to include multiple granularities into the API design.
I don't think this is a "permission" level consideration. Permissions in the browser have to do with granting origins the ability to do something. What we're discussing here has to do with the query mechanism and how that information is presented to the user.
I think that the Credential Handler API should not be directly concerned with either of these. The Credential Handler API is unlikely to get into many of the details of how queries are expressed or how they are handled. This is the concern of a more specific "verifiable profile" extension spec. There may be other extension specs that also make use of the Credential Handler API, but we (the CCG) would be chiefly concerned with the "verifiable profile" one.
So -- we'd be looking at creating two specs in this space:
-
The Credential Handler API, which is only concerned with getting a request to a credential handler of the user's choice, not the details of that request.
-
A "verifiable profile" extension spec that would define the details of one such type of request and the credential information used to fulfill it.
My expectation for the "verifiable profile" extension spec would be that it would define a very granular (attribute-level) query expression mechanism for the request. This mechanism may also include terms of use. It will be up to individual credential repositories (aka digital wallets) to innovate at the edge to provide the best way to present the attributes being requested and to enable the user to make an informed decision regarding what will be shared should the user consent. This will likely involve some user interaction in "composing" the verifiable profile they wish to present.
To recap the process: the verifier (relying party) website will make a request for a set of attributes. The user will select which credential repository they wish to use to help them fulfill this request. The request will then be forwarded to that repository according to the Credential Handler API spec. Then, it will be up to the credential repository to help the user fulfill the request. Ultimately, the credential repository will return a "verifiable profile" composed of attributes that are backed and expressed by claims in credentials.
How often do users authorize to share information with websites? While users might create or verify their accounts with websites infrequently, users do fill out forms more often. User experience topics may include uses of Credential Handler API to complete forms (e.g. on multitouch mobile devices).
It's unclear how the Credential Handler API would be used to fill out forms. It may be used in lieu of forms, instead. For example, instead of asking the user to fill out a form, the website would request a set of attributes, via the Credential Management API, that could be fulfilled via a credential repository of the user's choosing.
User interface topics include selecting one or more credentials and possibly one or more attributes of or one or more claims from one or more credentials.
I think this is out-of-scope for the Credential Handler API. The details of how to present the relying party's query and how to enable the user to best make a selection can be pushed to credential repositories. They may innovate here as they please to provide the best user experience. All that the Credential Handler API needs to do is ensure that the request from the relying party ends up at the credential repository of the user's choice. It's then up to the credential repository to provide a good experience for the user, whatever that may be, to enable them to fulfill the request.
For a given request, a UA might store and present a user’s previous or expected selections.
While true, it may be best to leave out those sorts of optimizations for version 1. Credential repositories can instead experiment with providing this functionality.
AdamSobieski
Credential Handler API discussion topics include user permissions and related user experiences.
Granularity
A less granular permission system might prompt users to select credentials to share with verifiers. A more granular permission system might prompt users as websites request users’ real names, dates of birth, citizenships, etc. It is possible to include multiple granularities into the API design.
Frequency
How often do users authorize to share information with websites? While users might create or verify their accounts with websites infrequently, users do fill out forms more often. User experience topics may include uses of Credential Handler API to complete forms (e.g. on multitouch mobile devices).
See also: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofilling-form-controls:-the-autocomplete-attribute
Ergonomics
User interface topics include selecting one or more credentials and possibly one or more attributes of or one or more claims from one or more credentials.
Stored Selections
For a given request, a UA might store and present a user’s previous or expected selections.