Re: [arch-d] Proposed IAB program on Wholistic Human-Oriented Discussions on Identity Systems (WHODIS)

[Christopher Wood <[e-mail]>]

Hi Ekr,

Sorry for the delayed replay, and thanks for the feedback. Please see inline below.

> On Jun 27, 2023, at 7:49 PM, Eric Rescorla <[e-mail]> wrote:
> 
> Hi Chris,
> 
> Thanks for sending this.
> 
> I have a few points here.
> 
> First, I'm struggling a bit with the way that this program is
> described:
> 
>    The identity ecosystems that support these use cases are
>    individually and collectively vast, including classical forms of
>    identities such as email addresses, phone numbers, and
>    certificates, to new forms of identities built on standards such as
>    OAuth [1] and Verifiable Credentials [2].
>    
> This seems to conflate two concepts:
> 
> - Identifiers such as email address and phone numbers
> - Credentials such as certificates, OAuth, and VC
> 
> To take a concrete example, certificates are a credential which can
> carry a variety of different identifiers, including email addresses,
> phone numbers, and (in the WebPKI), domain names. However, there are
> of course other types of credential which can attest to these same
> identifiers (E.g., VC) [0]. Of course, these aren't entirely
> independent concepts, but they are largely decoupled; even systems
> which tie back to cryptographic identities (e.g., blockchain-based
> systems) often try to attach some kind of human-readable attribute to
> that keying material.
> 
> For this reason, my take would be that this work ought to focus on
> credential systems, not identities.

I think you’re right in that the current text is conflating these two concepts, and we may be biting off more than we can chew. Credentials seem natural to discuss given their technical nature, whereas identifiers are more vague and ill-defined (is an IP address an identifier?). We plan to discuss this topic during the IAB Open at 117, and I think orienting it around the split between credentials and identifies will help us determine an appropriate initial scope for the program.

> Second, I think that you should probably try to focus on some subset
> of the landscape, which, as you say, is vast. As a super-rough categorization,
> you might think of identity being broken down into:
> 
> - Primary authentication via public keys, passwords, passkeys, etc.
> - Secondary (often called federated) identity systems like FedCM,
>   Google Auth, Facebook Connect (or whatever it's called now), etc.
> 
> These seem superficially similar, and of course RPs will often accept
> both (e.g., log in with your password or Google Auth), but technically
> they are quite different. I would focus on the second category and
> eschew the first.

This is an interesting take. Is your suggestion to focus on the second due to the well-defined nature of the first group?

> 
>   In working towards these goals, the program could collect important
>   use cases addressed by existing identity mechanisms, discuss
>   functional requirements (e.g., trust model, access control, support
>   for roles, etc.) essential for these use cases, and showcase how
>   existing identity mechanisms meet or exceed these requirements.
> 
> This seems to expand the scope quite a bit beyond identity. I would
> try to hit just identity first.

I think you’re right that the surface area with this list is enormous. Our thinking was that these adjacent topics provide context for the credential (and identity) mechanisms used in practice, and that context may be helpful in practice. Given that it’s optional work, I wouldn’t consider this a hard requirement for the program. It’s merely a suggestion.

Best,
Chris