Re: [w3ctag/design-reviews] Incubation: Email Verification Protocol (Issue #1169)

dickhardt left a comment (w3ctag/design-reviews#1169)

@martinthomson  -- thanks for the in depth feedback! @samuelgoto may want to add or clarify to my response below.

> 1. Venue

Agree the majority of this belongs in IETF -- but if the browsers are not interested -- then starting in IETF does not matter IMHO. Having it all in one doc enabled us to see the whole flow. Sam and I are planning on splitting this proposal between here and IETF. This would also allow innovation on how the feature is exposed in the browser independent of the protocol. Assuming we move forward with the 3 party model (see below) the non-browser part of this could be a fit for the IETF SPICE WG. WDYT?  

>2. Design -- 3 party model. 

With the browser as the intermediary, the issuer does not learn the RP the user is presenting to. For many sites, login is done with email verification. This protocol will improve user's privacy by not disclosing where they are logging into. This does add a fair amount of complexity as you have noted as the SD-JWT+KB is the binding between the issuer | browser | RP. We thought the privacy improvements were worth it. What do you think?

>2. Design -- SD-JWT
I was reluctant to build on SD-JWT -- but it defines key binding and the '~' mechanism to connect the two JWTs -- which are needed for the privacy feature -- and there are SD-JWT libraries to process the SD-JWT+KB. A selective disclosure is optional in the SD-JWT spec.  

>2. Design -- DNS
Where email goes is controlled in DNS. Starting the delegation in DNS aligns with what people in charge of email have control over. One of the key audiences for EVP are people with their own domain. They often only use it for email and don't host a web page. They set their MX and other mail DNS records. Setting another record is a within their existing infrastructure. 

>2. Design - DKIM
The .well-known has the issuance endpoint as well as the jwks_uri. In my experience, rotating DKIM is rare -- but rotating the JWKS file is pretty common infrastructure practice, and getting keys from a jwks_uri is common from OIDC deployments and JWT processing. 

> 2. Design - active cookies
Using cookies seemed like a good place to start and built on the learnings from FedCM. Note that the user experience fallback is to verify their email how they do it today, so if there are no active cookies, it is business as usual. I'd love for passkeys to also be able to be used -- this would allow the user to authenticate to the issuer without cookies -- the issuer would send a webauthn like request object in its response -- with the advantage that the issuer knows which credentials it will accept as the user has been identified by the email address. This effectively gives an RP the security of passkeys, without having to implement passkeys. Additionally, on mobile, the browser could talk directly to the mail app rather than calling a server. 

> 3. User Benefit -- we have gotten similar feedback. https://github.com/WICG/email-verification-protocol/issues/27

> 4. Usage -- informal feedback from RPs has been very positive. While a site could create a list of who they trust -- I think it is going to follow the pattern of email -- list of domains that are not trusted such as https://github.com/disposable-email-domains/disposable-email-domains. 

> 5. Enrollment -- see above for passkeys. Definitely an area worth more real world exploration.  

> Break down into sections. -- agreed -- we have received lots of feedback and it is clear there is interest in the protocol being used in multiple ways by the browser. A rework is in progress.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1169#issuecomment-3643312231
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1169/3643312231@github.com>