4.1.   mDL Interop (Kristina)

ISO mDL specification has reached final status.

There will be an interoperability event in Europe and the US in October and November, focusing on offline presentation using NFC, Bluetooth, Wi-Fi and online presentation using OIDC.

Kristina will provide event details and application info by the end of this week or early next week.

4.2.   EIC

• OpenID Workshop. Kristina and Torsten will talk about SIOP, OIDC4VP and claims aggregation. Slides to be circulated to this group.
• Kristina will be giving talk about SIOP talks on Wednesday.
• OpenID.net does not have a specific blog entry regarding the OIDF Workshop so there is a discoverability problem. Nat will coordinate with Mike Leszcz to update the site.

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

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

Tobias updated the issue with some questions for the group on what the type could indicate:

Credential type could just refer to a logical set of claims that are grouped together similar to how OIDC scope is used as shorthand for a set of claims.

Credential type could also infer the format that claims will be returned as (JWT, JSON-LD, etc...)

Could also indirectly infer other aspects such as assurance information about the claims.

At what point are we overloading and at what point is it better to have separate conventions to request those other pieces of information in subsequent responses.

Torsten proposed to use the Presentation Exchange syntax.

Simplest form is that a credential type is a logical set of claims. E.g. A drivers license credential type is first, last name and driving privileges and an ecosystem identifier. Information about format and assurance will be delegated to other requests and parameters.

Vittorio: How to resolve ambiguity between credentials which are meant to be part of some mechanism for verification (stuff for machines, e.g keys and signals ) and credentials such as passports, health insurance. Terms seemed to be used interchangeably but they are different. Do you rely on reader and context to differentiate which flavor of credential it is? What is the method of communication and language?

Verifiable credentials here are the counterparts for an actual document but credentials are also parts of a mechanism that you use for enforcing some kind of validation (passwords, signals). The word credential has different concepts depending on context. Is the difference defined somewhere? Should the term “verifiable credentials” always be used when talking about passports, insurance?

Tobias: The terminology of what the “credential type” will be called is in another issue. We are talking about a type annotation used to refer to a group of claims and whether that type annotation should convey the format that the claims will be returned and assurance information.

Vittorio: We should make it clear what credentials are and their types for people new to VCs. Human credentials (passports, insurance) cannot be coded the same way as mechanism credentials (certificates, passwords).

Jeremie : In a trust framework, the type and assurance will not be optional. The framework will specify what the issuers and verifiers will agree upon prior to any requests. The metadata will contain a lot of this information and not per request. The final format will use a URI to supplant the entire request.

Vittorio: It’s not a matter of determining format. One is a mechanism and the other is a declaration of sorts.

Nat: For human consumed credentials, there are also verification methods defined and strength of credential. Paper driver’s license can be physically examined or shine some light on it to determine authenticity or could have cryptographic material inside that can be checked.

Vit: A digitized document that has ways of determining validity is different from credentials which are tied to one particular protocol to transport them. User credentials and verifiable credentials should be talked about separately to avoid confusion.

Kristina: We should focus the discussion on “human consumed” credentials.

Nat: In this draft, we avoid the OAuth credential which contradicts with the OIDC credential. We are also trying to avoid W3C verifiable credentials if possible.

Tobias: We are talking about credentials as a set of attributes cryptographically signed by an authority and potentially bound to a proof of possession mechanism for presentation to relying parties. We are considering the terms “identity credential” and “claim set”. The “credential type” is referring to a shorthand notation for a set of claims.

Vit: It might be useful to try to make the context clear, and find ways of differentiating traditional, mechanical protocol level credentials from the people credentials

Vittorio will add his comments to issue #1271 regarding the terminology issue

Tosten has proposed some syntax for requesting “credential type”.

Going forward, “identity credential” will refer to a group of claims similar to OIDC profile scopes. OIDC providers can advertise what types of identity credentials they offer.

We need to decide whether type can infer the format or have a separate parameter in the request. We also need to decide whether to use JSON syntax or flat query parameters.

Torsten’s proposal has a schema parameter to denote the set of desired claims.

There are 2 issues:

1. Requesting set of claims

   • There are currently several ways to request claims:

     • Claims object

     • Scopes

       Do we want to introduce another way? If yes, we need to rationalize it.

2. Request format of returned claims

Torsten’s proposal is not adding a new way to request claims but more like enriching the current format.

6.2.   #1286 - Section 5.3 - Issue credential in the token response

#1286 - Section 5.3 - Issue credential in the token response

Torsten is proposing that the “identity credential” can be issued in the token endpoint instead of adding a new separate endpoint.

Tobias commented that there is a limiting issue where credential refresh would require End-User authentication and consent each time. Also will introduce complexity with 2 ways of getting an identity credential.

Feedback is requested from implementers on what is desired.