3.1.   SC17 (Tony/Kristina)

The text is complete.

Kristina sent the updated version last week.

Nat needs to get a clearance from the LC and then Kristina can submit it for the US NB pre-review before sending it to SC17.

Will get it approved at plenary on September 24-25 and then forward to the US NB.

4.1.   mDL Interop (Kristina)

mDL 18013-5 was published.

It defines an offline exchange of mDL between mDL app and reader and online exchange between reader and issuing authority/IDP and verifier.

OIDC is defined as protocol but there are privacy concerns, which will be clarified and addressed.

In-person events in the US (November) and EU separately.

Pre-event "OIDC Workshop" for explaining OIDC including its privacy features.

Kristina is the lead organizer.

5.1.   PR 33 - Cross Device SIOP

• https://bitbucket.org/openid/connect/pull-requests/33
• https://bitbucket.org/openid/connect/issues/1269/add-security-considerations-for-cross
• https://bitbucket.org/openid/connect/issues/1273/mitigating-security-risk-by-using-webauthn

Torsten defined a new “post” response mode which post the response directly to th RP’s redirect_uri.

David pointed out there may be security concerns since it’s a new mode.

It’s reusing redirect_uri which is user facing, and may have various web applications and security, firewall features and normal processing rules which expects it to be the completion of a browser request and not a POST from somewhere else.

A separate endpoint will create other interconnected issues with SIOP, due to metadata being non-authoritative.

A separate endpoint makes it easier for Developers. (Vittorio)

6.1.   1276 Section 2.2. - Missing parameter to determine the credential type.

Kristina pointed out that Torsten probably wants a concrete type of VC.

The presentation spec has something similar as follow. Perhaps we can incorporate similar text from it.

8.1. Embedded Verifiable Presentations A Verifiable Presentation embedded in an ID Token (or userinfo response) is requested by adding an element verifiable_presentations to the id_token (or userinfo) top level element of the claims parameter. This element must contain the following element:

credential_types Object array containing definitions of credential types the RP wants to obtain along with an (optional) definition of the claims from the respective credential type the RP is requesting. Each of those object has the following fields:

type REQUIRED String denoting a credential type claims OPTIONAL An object determining the claims the RP wants to obtain using the same notation as used underneath id_token. format OPTION String designating the VP format. Predefined values are vp_ldp and vp_jwt. Here is a non-normative example:

(Source) https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html#name-embedded-verifiable-present

6.2.   1315 Allow other grant_type other than code (Nat)

Comments from Torsten in pull request #39

https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca#comment-238240377

I don’t see a benefit of limiting the grant type to code. Why not using CIBA or device as well? I basically think an endpoints design should never depend on the type of OAuth/OIDC flow used to obtain (access) tokens. The current text goes:

Successful and Error Authentication Response are in the same manner

as [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)

with the code parameter always being returned with the Authorization Code Flow. ** DISCUSS ** ‌ it was pointed out that if we were to expand it, specifics need to be defined as well, such as a constrained set of parameters etc. for interoperability and associated security considerations.

Since it is in the setup phase, it happens only once (sort of) per IA. Is there a concrete need for other flows?

7.1.   EU Entry Considerations for EIC

• Required to wear N95 Mask
• Check if your country is listed in risk area: https://einreiseanmeldung.de/#/

The meeting was adjourned at 00:02 UTC