1.   Roll Call

• Attending:
  • Brian Clinkenbeard
  • David Waite (Ping Identity)
  • Kim Cameron
  • Kristina yasuda
  • Nat Sakimura
  • Tobias Looker
  • Adam Lemmon
  • Edmund Jay
  • Tim Cappalli
• Regrets:
• Guest:

2.   Adoption of Agenda (Nat)

• As agenda was not circulated before the call, it was dynamically created and agreed.
  • External Organizations and Events
  • SIOP

3.   External orgs and events

No Updates.

4.   SIOP Discussion (Tobias)

Tobias shared Self-Issued Provider document : https://hackmd.io/YL3juOZrRH65XV51bZR6dQ?view The document discusses how to get SIOP adopted into existing OpenID infrastructure and the interactions between existing providers and clients.

Looks at problems and solutions for SIOP and whether to make SIOP an extension of OIDC.

Self-Issued today returns

• self-issued response which is an ID token or assertion signed in alternative manner to solve NASCAR problem
• allows users to select their providers and request down client registration

Document looks at additional syntax needed to make self-issued responses and what's needed in the request to request a self-issued response and the discovery metadata.

Default Self-Issued behavior is current section 7 of OIDC Core.

Request syntax should align with OIDC Core.

How to make the request will be separate issue. (e.g. contacting an OIDC provider w/o http server)

Kim stated problem of the ISS field in responses where it can be any issuer ID and how to convince RPs that you're the authoritative issuer.

Current spec relies on binding between Issuer and discovery metadata for keys therefore current processing will not work for self-issued responses.

Existing OIDC providers will need special handling for self-issued responses.

The way RPs indicate to OP that it supports self-issued responses is via an explicit parameter in the request.

Current SIOP request is not an OIDC request. The goal is to make SIOP request syntax closer to to normal OIDC request.

Needs a clean way for RP to indicate it supports SIOP responses and for responses to indicate they are SIOP responses.

Kim has concerns of ISS impersonation if ISS field is allowed to be any string.

Current problem of spec is that metadata is tied to issuer field.

Kim would like SIOP to support PWAs, VCs.

Would like document to list problems, solutions, desired features etc before diving into details.

Should be based on VCs spec.

Tobias would also like the ability to support subject identifier portability irregardless of ISS. e.g. changing providers but keeping same DID identifier

David suggested using cnf claim that could correspond to transport mechanism like mutual TLS etc. The ID Token's cnf claim would represent the holder which could be the DID id.

Brian pointed out other groups solving portability problem of using UUID v5 which will be unique as subject identifiers. Can change domains without affecting subject id. Might be subject to impersonation if UUID is known.

Current way of using key fingerprint as sub id makes impersonation more difficult.

5.   SIOP Requirements Wiki (Kristina)

Kristina went over document for requirements of SIOP : https://docs.google.com/document/d/1ZjsxzaMUkKx6wfL9yJIUITFSB6L08SmCd2AKAcVQkhk/edit

6.   AOB

The meeting was adjourned at 14:57 UTC