3.1.   OpenID Connect Claims Aggregation (Edmund)

No change yet. Only one comment so far. WG is asked to read the spec again and provide feedback.

Adam asked for more examples (e.g. concrete request flows, requests, responses).

Kristina asked if there is overlap with the credential provider draft.

Edmund replied that there are overlaps.

Tobias also stated there are overlaps. They essentially achieve the same thing, which is creating a vehicle for claims to be communicated, such that they can be indirectly presented downstream to a relying party. OpenID Credential Provider seems to handle the front end requests whereas aggregation works on the backend to return claim and credentials.

Adam and Edmund will discuss off-line for the next course of action.

3.2.   SIOP v.2 (Kristina)

There was a comment on whether the spec could support VCs and JSON-LD signatures and not just VCs and JWTS.

Filed some issues based on some feedback. (#1199, #1198)

openid:// scheme doesn’t work on iOS. May need a Nascar kind of interface to solve it.

People seem to be OK to pass parameters by value or reference, but if passing a request object, key material is also passed in the header.

If it’s a DID, you have to know how to resolve it.

Members are requested to review it and file issues. Adam and David volunteered to review.

3.3.   Portable Identifiers (Tom/Tobias)

It is for portable identities and identifiers as it is portable keys. You cannot move DID from one method to another so "portable identifier" is misnomer. DID is inherently tied to some kind of domain.

Tom mentioned the capability in the side tree that allows change in method.

Tobias: We're trying to tease out is how can we establish a domain for subject identifiers that have a proof control mechanism, that is separate to that of the provider, tha thet subject may be using for authentication. how would I maintain coherence with my relationship, with the pseudo relying parties using a consistent subject identifier when I want to essentially change from one provider to the other.how would I maintain coherence with my relationship, with the pseudo relying parties using a consistent subject identifier when I want to essentially change from one provider to the other. How would I maintain coherence with my relationship, with a set of relying parties using a consistent subject identifier when I want to change from one provider to the other. Similar to Modrna account porting. Tom: Wrote draft with ability to have redirection on DID. So that you can say “Yeah, this used to be my did, but I don't want to use this anymore. I want to use this other one instead.”

Tom would like to try redirection instead of portability.

John: but that assumes the redirection stays around.

David: If the old identifier was a DID then is the current identitifer a DOES?

Tom: Redirect may not be wrong word, maybe reload/reassign.

John : Account Porting needs the old provider to play a role. How do you know you’re redirected to the right place unless it’s signed. There has to be a trust chain.

Tom: Trust is a major problem of DIDs

Tobias: If you have identifiers that have a cryptographic proof of control element, you don't actually have the ability to have a bi directionally verifiable transfer of Control of ownership or association to the identifier itself. The question is the longevity of providers. Most people's accounts are predicated on the continued existence of providers. If providers disappear, associated people's identities would disappear also.

Is there a way a viable mechanism to use through cryptographic kind of identifiers such as DIDs to establish a domain where providers can share their domain, like a DID method or whatever it may be, some level of indirection to kets that can evolve over time that model providers can share their domain. People within that kind of realm can transfer between those providers and are isolated from risks like they provider going out of business, or they're provider choosing to no longer deliver them, identity services.

May require legislation to keep old provider functioning in some way to redirect to the new provider.

Cryptography method may be able to solve this problem.

Authenticating in some way to the old RP with the new identifier, containing enough information to prove that you also control the the old identifier which can then be validated that the two are linked without having to rely on the old one being operational, assuming the relying party cached enough information so that they do so.

Solution is more robust if it doesn’t rely on continued operation of the old infrastructure provider.

Sudden (and Planned) death problem cannot be solved by this.

In the case of Modrna, as telcos are regulated entities, it could work. But for "Self-sovereign", being regulated like telco is philosophically not good.

We should explore a cryptographic base solution where the account holder can use their new new identifier to prove control of their old identifier so that the metaphysical thing that the identifier was for can continue its existence with a new identifier.

John: Rollover and caching of Discovery Information. RPs may need to keep more information around, you can't always assume that they can completely resolve the old method, et cetera. Cacheing at RP etc. Probably a tractable problem.

ACT: Tom is going to make a write-up. John will review.

4.1.   SIOP Special calls (Kristina/Tim)

Coming up in two days.

Topics:

• Portable identifiers.

4.2.   Bi-Weekly Web Browser Calls (Tim)

Met last week. Vittorio went over the framework for submitting use cases.

ACT: People to submit use-cases to github https://github.com/IDBrowserUseCases/docs There is a template which describes the various characteristics on the scenarios that we want to capture. Fill out a template and create a pull request.

5.1.   DIF (Kristina/Tom)

The recording is available.

Key rollover PR was merged into DID-Core

Proposal for a new WG: "Secure Wallet". We could make a suggestion to change the scope if we wish.

• https://docs.google.com/document/d/18H2hVjHZEBjbnzod8tLogJIEzySdecbk9d-QBJaqHP0/edit#
• https://medium.com/decentralized-identity/dif-face-to-face-jan-2021-highlights-89e78cb80f54?source=friends_link&sk=bc5716fdcea0d85e1ee3a970b48ac742

5.2.   W3C (Kristina/Tim/John/Mike/Tony)

n/a

5.3.   IETF/GNAP

• GNAP people seem to be interested.
• GNAP always assumes that there is a backend component so there is mismatch.