3.1.   Privacy CG (George)

9:00 AM Pacific / 16:00 UTC

https://github.com/privacycg/meetings/tree/main/2021/telcons

Topic will be about mitigating strategies for navigational tracking.

Bounce tracking from an ad tech perspective,

Apple: Single user going to more than 10 RPs will break. Apple rewrites cookies to be strict. Will delete cookies.

Google is trying to separate identity traffic to ad traffic. Looking for parameters in redirect calls that look like OIDC flows and will perform special handling for each classification.

Will a whitelist for IDPs solve the issues? If yes, where is the whitelist stored and how is it presented? Perform interstitial while user logins to IDP from RP.

Browser could also check .well-known metadata. Not sure if Sign-in with Apple behaves the same way. Need to experiment with different browsers and IDPs.

3.2.   SC17 (Tony/Kristina)

The liaison request text is complete. 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.

4.1.   mDL Interop (Kristina)

• ISO/IEC 18013 Part 5 - mDL
• ISO/IEC 18013 Part 7 - mDL
• ISO/IEC AWI TS 23220-2
• ISO/IEC AWI TS 23220-4

Digitizing identity and putting it on phones, starting with driver’s license

OIDC is specified as the protocol that reader devices can use to fetch the credentials from Issuing servers using user access tokens.

Interoperability event planned for October in Europe and November in the US to address privacy concerns.

There are 2 ways that the Reader can also get mDL :

Directly from the user's wallet in normal flow.

Using OIDC to get it from Issuing authority.

Will not be available in version 2 when verifiable credentials are supported.

Also privacy violation.

Kristina pointed out the identity provider is not always controlled by the issuer, so it’s not always a direct call to the issuer.

The terminology being used is offline and online access. ACLU is complaining about online access due to lack of access to specs, but may be backing off after reviewing.

A privacy profile group is in the process of being chartered by Kantara.

4.2.   EIC

September 13 - 16, 2021 in Munich, Germany

OIDF will have presentations about OIDC, SIOP,

Kristina co-presenting with Torsten about OIDC for SSI and will share a presentation for feedback.

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

Security issues cited.

David pointed out concerns with reusing redirect_uri for post response mode.

From an authentication request perspective, the difference between the on- device flow and the cross device type of flow is just the mode parameter = post

If additional parameters are desired, a new response_type would need to be defined which is a more significant change..

Clarify the text to say it’s different from form_post in that the post is from the SIOP device directly to the RP’s redirect_uri instead of through the browser.

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

5.2.   R40 - Proposal for issue #1270

Related to #1270 - proposal text was discussed in mailing list

Roland to review text.

5.3.   PR 42 - Remove vp hash

Will leave open for further discussion and then merge

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

Torsten would like text to align with discussion about schema and type in Presentation Exchange and would likely be in OIDC 4 Verifiable Presentations spec.

There is a schema element in PE that determines the credential type that the verifiers are asking for. Wallet should use the same term and definitions to request issuance of a credential from the credential provider.

For presentation request, the verifiable credential type and issuer should be in the request, so the wallet can know which issuer to a ask for the requested credential.

End to end Flow :

1. Verifier asks for the presentation of a certain credential (OIDC4VP)
   • Request syntax uses Presentation Exchange
     • Claims parameter contain syntax from PE to determine credential type
     • Schema parameter in claims object can be simple string or URI
2. Wallet receives request and use exact values in request to credential provider

Torsten will provide proposal for text

The credential type has to be a URI so that it can be globally unique. But VC has the concept of an @context which maps the URI to a local friendly string, which can be a OIDC claim

Use text from PE 1.0 as starting point

Tom stated that request form RP can be very generic, e.g. proof of ability to work which is not a URI, but can be satisfied by lots of URIs. Do RPs have to specify the exact URI in request?

VC’s @context contains the unique URI to identity which exact credential it is. The VC itself can just specify the user friendly name

In current PE, the schema is an array of strings, each representing an alternative. OR logic. The wallet returns a response satisfying one of the requested credentials.

Standards organizations would need to create the URIs and the local jurisdictions would need to create mappings to friendly names.

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