Markdown Version | Session Recording

Session Date/Time: 09 Dec 2024 17:00

OAUTH

Summary

The OAUTH Working Group held an interim meeting to discuss the SD-JWT VC document, primarily focusing on the contentious issue of including or excluding Decentralized Identifiers (DIDs) and refining the key resolution mechanisms. While no final decisions were made at this interim, the discussion clarified technical arguments for and against DID inclusion and highlighted areas for improving the specification's clarity and extensibility regarding issuer key discovery. Further discussion on the mailing list is required.

Key Discussion Points

• Welcome and Logistics: Chairs Hannes Tschofenig and Rifaat Shekh-Yusef welcomed participants, reminded everyone of the IETF Notwell, and outlined the schedule for upcoming OAUTH interims covering SD-JWT VC, Transaction Token and Identity Chaining, Client ID Schemes, Token Status List, and Private Key Attestation.
• SD-JWT VC Document Overview (Brian Campbell):
  • Brian Campbell presented an overview of SD-JWT VC, describing it as a format for verifiable/digital credentials with JSON payloads and selective disclosure based on the SD-JWT format.
  • Recent updates included publishing drafts 06, 07, and 08.
  • Draft 06 updated the media type from application/vc+sd-jwt to application/dc+sd-jwt. It also tightened issuer-signed JWT verification key validation exposition (initially removing DID mentions) and added a status field for the well-known URI registry.
  • Draft 07 reverted the explicit removal of DID mentions and removed the requirement for a well-known portion for VCT type URL definitions.
  • Draft 08 fixed formatting issues.
  • The document's goal is to tighten scope, simplify, and accelerate the RFC timeline to support emerging legal and regulatory frameworks, particularly in the EU.
• Historical Context of DID Inclusion:
  • SD-JWT VC was adopted by the WG after being presented in San Francisco as an aspirational individual draft, profiling SD-JWT for verifiable credentials.
  • A section on obtaining/validating public keys was introduced, initially describing HTTPS (web PKI, X.509) and DID document resolution. An extension point for ecosystem-defined rules was also included.
  • At IETF 118 (Prague), the necessity of DID inclusion was questioned by Brian Campbell and Richard Barnes, leading to a decision to defer the discussion to the mailing list.
  • Subsequent drafts (pre-Brisbane) made key resolution methods optional for verifiers.
  • At IETF 119 (Brisbane), discussions focused on meeting EU requirements and defining metadata.
  • At IETF 120 (Vancouver), a hallway discussion led to GitHub issue #50, proposing to drop all references to DIDs and DID resolution (removal of a single paragraph). This sparked significant debate due to the large number (150-200) of DID methods, raising interoperability concerns for a generic "DID" requirement.
• Contention and Mailing List "Kerfuffle":
  • Brian Campbell described the intense debate following the pull request removing DIDs, characterized by strong language, accusations of process violations, and perceived ideological disagreements. He clarified that the change did not prohibit DIDs but aimed to remove underspecified text that hindered interoperability.
  • The chairs intervened, requesting the online discussion cease and move to this interim meeting.
• Arguments for and against DID inclusion/removal:
  • Stefan: Requested core technical reasons for DID removal. Highlighted existing industrial use cases and ongoing CEN standardization work in Europe that defines functional/interoperability requirements for specific DID methods and how they could work with SD-JWT VC. Suggested the IETF spec could be a basic "umbrella" document, with extensions for specific DID methods defined elsewhere.
  • Richard Barnes: Supported removal, citing the impossibility of implementing/testing against "200+ did methods." Argued that for a specification intended for interoperable code, a general "implement did" provision is insufficient. Also noted the current key resolution text (highlighted in the presentation) is insufficient for offering a clear path forward, as the same URI could be processed in different ways. Suggested a "meeting point" mechanism (e.g., an additional field) for verifier and issuer to agree on key lookup methods.
  • Watson: Raised serious security concerns about the current issuer construction and adding new resolution methods. An ambiguous issuer string, resolvable by multiple methods, could lead to a verifier trusting a credential from an unintended issuer if different resolution methods are applied. Advocated for a clear indication of how an issuer's key should be resolved.
  • Marcus: Argued that many concrete projects and implementations already use DIDs with the specification, refuting claims of non-implementability or lack of interoperability. Viewed DID methods as an extensibility mechanism, similar to the existing "yellow box" extension point for key discovery. Expressed concern that removing DIDs might lead to 200 other custom extensions, worsening interoperability. Recalled a previous consensus to make DIDs optional, questioning why the topic was reopened.
  • Mike Jones: Supported removal, drawing on experience from the DID working group. Emphasized that the specification needs to facilitate writing tests against implementations to ensure interoperability. Generic "did" support, without explicit configuration of methods, does not guarantee interoperability.
  • Daniel: Supported making the spec as small and concise as possible, with specific DID methods detailed in separate, testable extension specs (e.g., within a European ecosystem).
  • Christina: Stressed the need to separate issuer identifier/signature problems from holder identifier/key problems, as solutions may differ. For holder keys, she suggested using confirmation.cnf (RFC 7800) as an extension point where specific DID methods could be mandated, rather than claiming DIDs are simply "allowed" without specific guidance.
  • Hank Linding: Shared experience from the SKIT working group, where initial inclusion of DID methods became a "hard blocker" due to concerns about the trustworthiness of resolvers (how to ensure a resolver does what it's intended to do and nothing else). This led to the removal of DID specifications from the SKIT architecture, suggesting a similar path for SD-JWT VC to avoid "inviting disaster."
• Brian's Recommendation: Continue moving the document forward, including the removal of the paragraph mentioning DIDs, and evaluate other problematic or underspecified areas. Ensure necessary extension points and allowances exist for different deployment models or ideologies. Develop extensions or profiles in appropriate venues (e.g., CEN). Offered to help interested parties in the IETF to pursue a general description of DID usage with JWT-type technologies.
• Chairs' Closing Remarks: Hannes and Rifaat acknowledged progress but stated that the group is "not quite there yet." They will discuss next steps with AD Deb. They urged participants, especially Richard and Christina, to provide specific feedback on the mailing list regarding the clarity and extensibility of the key resolution text.

Decisions and Action Items

• No final decisions were made during this interim meeting. Decisions will be made on the main OAUTH mailing list.
• ACTION: Watson to send an email to the OAUTH mailing list detailing security concerns regarding issuer key resolution ambiguity and the potential for one issuer string to be resolved in multiple, insecure ways.
• ACTION: Richard Barnes, Christina, and other interested parties are requested to provide specific feedback on the OAUTH mailing list regarding the current issuer key resolution text and proposed improvements to enhance clarity and extensibility.
• ACTION: Hannes Tschofenig and Rifaat Shekh-Yusef to consult with AD Deb regarding the best way forward for the SD-JWT VC document given the ongoing discussion.

Next Steps

• Continued technical discussion on the OAUTH mailing list focusing on the precise language for issuer key resolution, ensuring sufficient clarity and extensibility without prescribing specific technologies like DIDs within the core specification.
• The chairs will provide guidance on further work on the SD-JWT VC draft based on feedback and discussions with the AD.