3.1.   DIF

No Updates

3.2.   W3C

TPAC was last week. Discussions were mainly centered around data model and types language related to privacy issues using DIDs.

4.1.   SIOP Requirements Document

https://bitbucket.org/openid/connect/src/master/SIOP/siop-requirements.md

Should start extracting the requirements from the document and put them into the draft

Christina asked whether the draft should be separate or part of OIDC SIOP. Can start as a separate document and WG can decide to merge later.

4.2.   prompt=create

Skipped

4.3.   Claims aggregation

Still waiting for feedback and comments Members are asked to review the document https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md

Takahiko and Tobias had volunteered.

5.1.   Ephemeral Identifier Subject type

http://lists.openid.net/pipermail/openid-specs-ab/2020-November/007943.html

Tobias would like to extend the concept to cryptographically verifiable subject identifiers or subject types. Identifiers that feature some form of cryptographic proof of control so that the identifier is portable allowing portable identifiers across providers.

Purpose of this draft is to fix oversight in OIDC Core of missing ephemeral subject identifiers.

Nat is working on ISO 27551 and was made aware that ephemeral subject identifiers don’t exist. Nat was planning to add a couple of lines to OIDC Core errata, but Mike said that cannot be done.

A separate document with it’s own security and privacy considerations is better so people can just read it for anonymous authentication use cases.

Tobias wants to explore the ability to expand behaviors around subject id and subject claim in id_tokens specifically cryptographically verifiable identifiers.

Nat prefers a new specification be written up since ephemeral subject types is currently needed before ISO 27551 publishes.

The only requirement for ephemeral subject identifier is that for each authorization request the sub value will be different. There is no crypto associated with it except that it’s cryptographically random to ensure that the subject is not correlatable.

It can be used for age verification in attribute based authentication.

Need to have the ability to recognize that the ephemeral identifier is ephemeral There is a identifier type that explains types in OIDC section 8

This draft adds the “ephemeral” type which is per client but not per id_token.

Kim states that being able to identify what kind of identifier and its characteristics based on the value would be nice.

It’s not a self describing identifier so context is lost when stored.

James suggested prefixing identifiers with type strings e.g. “temp:”, “did:”

Tobias needs a global namespace cryptographically verifiable identifier that can be transferred to another OP to retain consistent identification with a given RP.

James stated the current public identifier already does that except no OP supports importing it. Tobias would like it to behave pairwise with particular RPs.

David cautions that if it’s not cryptographically verifiable, any OP can assert that identifier simply by knowing the value, so it needs cryptographic proof of ownership

Tom suggested putting expiration date on identifier allowing people to specify their its lifetime, so it would fit DIDs, GDPR

Nat thought about adding structured identity to the draft, but will need to consider the syntax (self contained vs metadata)

5.2.   OpenID Credential Provider

https://mattrglobal.github.io/oidc-client-bound-assertions-spec/

Tobias went over the document to be used as a potential work item.

This extends the traditional open ID provider to become the provider of credentials, which are these types of cryptographically bound end user assertions, essentially an ID token with actual binding so some key material that’s supplied by the wallet.

Draft defines a new “openid_credential “ scope.

The signed request object is used to prove position over the key material that the client would like, the credential bound to.

Also defines how to request claims and credentials.

The draft also features the concept of different formats for the credential (e.g. JSON-LD, JWT).

Brian has doubts about overloading the typical signed request authentication flow.

The identity assurance draft that that's been worked on at the moment is about defining kind of a namespace for some claims that have greater kind of assurance is than the standard open ID claims and the syntax to support requesting those given different levels of assurance.

This spec is about obtaining an end user assertion that features some form of authenticated binding so you can store it in your wallet and reprove it.

For WG to consider taking up this document as a work item, it needs to be sent to the mailing list for commenting and consideration.

Tobias to send the draft to the list.