digital-credentials
digital-credentials copied to clipboard
WICG
require in-context in-content explanation and an element for user-initiated presentation
Sites could (either required or as an optional upgrade) present a button for user initiation of presentation within a structured in-content element on the page, explaining the purpose and validation of their request. Browsers could confirm that the content was visible when the user initiated the button, and pass on a normalized version of the text to the wallet so that the wallet would have a record and binding of the context of the request.
The goal is to prompt sites to provide in-context explanation, enabling both informed consent and accountability for sites that request or use credentials inappropriately.
Some sample markup and a mockup image just as a strawman; I'm confident this syntax could be improved.
<div class="request">
<p class="request-overview">
Agency X would like to access your name and identity number to confirm your eligibility for Program Y.
</p>
<p class="request-purpose">
This data will be used to confirm your identity, income level and citizenship status.
</p>
<p class="request-sharing-retention">
This data will not be shared with third parties. Data will be retained only for program eligibility.
</p>
<p class="request-validation">
<a href="z.gov/validation/example.com">Data Protection Authority Z has validated this request for government-issued credentials.</a>
</p>
<permission type="credentials" lang="en-US" request="[OpenID4VP protocol string]">
<p class="request-privacy">
For more information, see the <a href="privacy.html" rel="privacy-policy">Agency X Privacy Policy</a>.
</p>
</div>
(This is a proposal for one of the suggestions in https://github.com/WICG/digital-credentials/issues/44. This would also build on, but extend beyond, the user intent suggestion in https://github.com/WICG/digital-credentials/issues/134.)
This would be useful for raising the bar to using the API, hopefully discouraging use cases that have other, reasonable alternatives like Passkey authentication.
I'd work the syntax to be driven by id and an HTML attribute, like so we could grab the innerText and perform intersection tests with the viewport. It'd look like this:
<div class="request" id="example-identity-context">
...
<permission type="credentials" lang="en-US" request="[OpenID4VP protocol string]" for="example-identity-context">
...
</div>
Wait! what's this <permission> element? That's not a (standard) thing in HTML.
Also, there's not guarantee that the surrounding text has any meaning or anything to do with the permission request. Even if the browser claims it's visible, it might not be (e.g., the text color, font, or even language etc. might not match or mean anything... it would be a huge race to the bottom).
On the other hand, it's might just be good practice to do what is proposed above without enforcing a structure that's going to be impossible for browsers to actually validate. I wonder if it should be enforced by policy instead (i.e., if you are going to request credentials, you are required to display this text.... but that's outside the scope of the spec, apart from maybe providing some authoring guidance or best practices)
<permission> is a reference to another WICG proposal, PEPC (Page Embedded Permission Control). Having the prompt button be browser-generated but embedded within the web content itself would make it possible for proposals like this where the immediately surrounding context is explanatory before the user initiates the presentation and gets a permission prompt or chooser.
I understand it could be a race to the bottom where the surrounding context isn't used in an explanatory way. But to be clear, the very bottom, with no contextual explanation at all, is the current proposal in the spec and is being implemented by Google and others. Making it clear what the site has to do also makes their deceptive behavior stand out (and something that can be addressed through policy means) as opposed to the misbehavior being identical to the demos and the intended behavior.
Right, but as WebKit have pointed out previously, the problem with PEPC is that developers still need to do:
<permission...>
<!-- fallback -->
<button onclick="callDCAPI()">Identity</button>
</permission>
Because the entry point is navigator.credentials.get(). If you have two entry points (declarative and imperative), then the whole things kinda falls apart leading to duplication.
Because the entry point is navigator.credentials.get(). If you have two entry points (declarative and imperative), then the whole things kinda falls apart leading to duplication.
What if we didn't have an imperative entry point at all?
