1.   Roll Call

• Attending: Adam, David Chadwick, George, Kristina, Nat, Tom Jones, Torsten, Andrew, Bjorn, Giuseppe, Joseph
• Regret:
• Guest:

2.   Adoption of Agenda (Nat)

3.   Credential Issuance Requirements Overview

Torsten presented an overview for credential issuance requirements

• Need for indifferent flow types for credentials to be issued
• Proof of Possession of Key Material (JWS, blinded proofs, ZKP, and also issuance without proof)
  • From OIDC perspective, need to decouple Proof of Possession from everything in the protocol (request signatures, client authentication)
• Requests
  • Simple request /single credential type
  • Multiple credentials in single request/response
    • micro/mono credentials (same key material)
    • Batch issuance (different key material mDL)
• Presentations as prerequisite for credential issuance (beside inline presentation/identification requests)

Would like to come up with a spec that would cover 80% of requirements in a reasonable timeframe.

Could we use credential manifest to address protocol negotiation.

3 parties in SSI model

• Issuer
• Holder
• Verifier

Now focusing on issuance of credentials from Issuer to Holder.

Main difference between ID Token and credential is that credential is an assertion that is bound to key material that can be used to demonstrate that it was issued to the holder of key material and the assertion can be used elsewhere.

Need nonce by issuer to protect PoP from being replayed.

Torsten doesn't see how current Claims Aggregation would be able to provide such functionality.

Nat : Why wouldn’t a regular resource request work, e.g. GET request with request headers?

Tosten: First, need authorization for the request. Requesting authorization to issue a certain credential is not a resource request. User needs to be involved.

#1276 relates to the request syntax of holder to issuer

Torsten would like to begin a new draft to spec the request/response from holder to issuer.

• Send request from holder to issuer that determines what credential types the holder wants to obtain
• Issuer needs to authenticate and get consent from the user
• Holder needs to request credentials and potentially getting PoP of key material that needs to be sent to resource
• Resource returns required nonce incorporated in PoP
• Credential issuance endpoint issues credential(s)

The sequences don’t have to be in the exact order.

Sequences look like profiles of standard OIDC/OAuth 2.0 for holder to issuer.

Nat asked why Section 8 of Claims aggregation doesn’t work since it defines claims parameters. Could use claims names and scope to request credentials.

Torsten needs a way to specify a credential type

The problem may be that the requirements are not well understood.

Claims and credentials are different. Credentials are defined schemes which may contain claims

What’s needed is a way to request W3C VCs using the W3C VC spec using claims parameter

RAR can be used as alternative to claims parameter

Syntax from DIF Credential Manifest spec can be utilized without creating another way

Allows ability to request a type per resource

We need a complete description of what is needed and then decide how to integrate it into a spec

Torsten and Kristina will write a new draft and submit it to mailing list or repository

Nat suggested individual drafts should be stored in a different directory

4.   AOB

The meeting was adjourned at 15:02 UTC