[Openid-specs-digital-credentials-protocols] [agenda] DCP WG + SIOP call
Lee Campbell
leecam at google.com
Thu Nov 21 17:05:23 UTC 2024
Notes:
Kristina: co-chairs + Gail had a call with CEN. Working on EUDI standards
and would like to have a liaison. This process has been started and chairs
think this a positive step and are excited about it
Where should the mdoc profile for openid4vp go?
-
Kristina: OpenID4VP has lots of options and we need a profile to select
a set of options for interoperability. We have three options
-
OpenIDVP is a framework, we can’t mandate options
-
Put the mdoc profile in the HAIP document, but this would require a
refactor of that doc. We could make a HAIP a collect of 4 mini profiles
that could be used independently
-
Create a new document/spec for the mdoc profile, but this seems very
tough given timelines. There are also lots of things common to the
profiles, so we’d still need a place for common options
-
Paul: Seems obvious not to do option 1), its why we made HAIP in the
first place.
-
Paul: There will be lots of overlap, say 99%, separate docs seem like
lots of redundancy. Prefer Option 2
-
Daniel: Prefer Option 2 also. But need dog names
-
Torsten: If we do a high assurance profile, things like encryption
should be independent of the credential format. Would lean to option 2
-
Tim: Why is 2) and 3) separate.
-
Kristina: Option 2 is one big HAIP doc
-
Oliver: In favor of option2. But need to clarify using custom schemes
with mdoc.
-
Kristina: Need to communicate this to ISO
-
Martijn: Surprised it can’t go into OpenID4VP. It would have been nice
to have known this months ago. Need to figure out what happens with -7.
Doesn’t sound like there is any other realistic option than 2), but unsure
if thats actually a good option.
-
Torsten: Apologies for not communicating. But does this really cause
additional issues as the timeline would be roughly the same regardless of
where it goes
-
Martijn: Yeah figuring this out will take some time to figure out with
ISO.
-
Torsten: Even with OpenID4VP you still have to deal with SD-JWTs
etc..though I think we can get this to success
-
Martijn: Haven’t had chance to review HAIP in detail yet, but HAIP
mandates lots of things and we need to ensure we don’t mandate the wrong
things for mdocs. Hopefully this can be done quickly.
-
Kristina: Consensus on option 2 to move forward and there is a draft PR
-
Andreea: Would these 4 profiles in HAIP be driven by the EUDI
requirements?
-
Kristina: Specs are driven by who is at the table providing
requirements. This is the EU and the ISO folks, but the aspiration is for
this to be an internationally adopted spec. But happy to take requirements
for other groups and address them
-
Andreea: If a version is referenced in the implementation acts, might it
be different to evolve?
-
Kristina: Maybe ETSI will have to profile it, depends how much things
diverge
-
Martijn: Is everything in HAIP driven by these EU, or does the browser
API count. Do we need more things related to mdocs or not?
-
Kristina: EU wants us to add an mdoc profile to HAIP.
-
Martijn: Would be good to know from an ISO perspective if more
requirements will come as it impacts everyone who uses mdocs for browser
transmission. Would be good to have clarity on that?
-
Christian: Wouldn’t be fine to reference the sections that are relevant
-
Kristina: Depends on who drives the requirements for a given section.
Are they just ISO requirements or not
-
Martijn: DCP can make its own choices, just need to be clear and
communicate what we’re doing with ISO
-
AI for co-chairs: Document if there additional requirements on the mdoc
profile from outside of ISO
Add intent to retain:
-
Martijn: Understand the questions. Maybe we need to be more prescriptive
about processing vs retaining.
-
Lee: <Made some excellent points>
-
Updated the issue. Will go back to ISO with questions in two weeks.
Make the claim set order mandatory or not:
-
Martijn: Should change it to any set that satisfies the request should
be able to be returned.
-
Paul: This is just a badly formed RP request. They could rewrite it in
the correct way.
-
Martijn: Wallet could have the chance to fix it.
-
Hitcham: Wallet could have a chance to pick a more privacy preserving
option that the RP might not be aware of it.
-
Kristina: This is driven by the verifier at the end of the day
-
Martijn: Just disagreeing with the mandate that the wallet has to follow
this.
-
Joseph: Makes conformance testing harder. Privacy concerns would
overrule this, but it does make it harder
-
Lee: Makes writing libraries harder. Leaning towards making it explicit
-
Gareth: Leaning towards making it open
-
Paul: Is any good reason other than testing?
-
Daniel: Original recommendation was for implementations. Should not be
user choice
-
Martijn: For testing we can follow the recommendation and expected
behavior that you comply. Expect everyone to follow the recommendation but
don’t want to force everyone to do it.
-
Oliver: There could be a requirement to fulfil ‘required if present’
(from DHS) and this would solve it
-
Daniel: Some questions over if have this requirement or not.
-
Torsten: From CA DMV, if a RP wants to comply with Real ID rules, they
would only request RealID rules.
-
Kristina: No conclusion on this for now, but not mandatory could be fine
Whats happening with the implementors draft for Open4VCI
-
Kristina:
OpenID4VP PRs:
-
Kristina: There are 15 open PRs, mostly editorial.
-
Look at the ISO related ones as a priority
What to do if the RP doesn’t have DNS name when using x509
-
Kristina: OAuth experts please comment on this issue
Value Matching (#307) and Issuer matching (#322)
-
Kristina: These might be able to be done with value matching. This is
under debate
HAIP - Add mdoc
-
Kristina: There is a google doc and a pull request. Please provide
feedback
-
Torsten: Do we need to change the repo name
-
Probably yes
On Thu, Nov 21, 2024 at 3:27 AM Kristina Yasuda via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
> Hi All,
>
> Below is the suggested agenda for today's DCP WG + SIOP call:
> https://zoom.us/j/94085567252?pwd=cHNFMExFalhlM2MrOFhoN3J6eDRuZz09
>
> We have three focus topics for today, as highlighted below. It's a packed
> agenda, so we will start on time, will not wait 3-5min as usual.
>
> 1. OIDF Antitrust Policy at www.openid.net/antitrust applies
> 2. IPR reminder/ Note-taking
> 3. Introductions/re-introductions
> 4. Agenda bashing/adoption
> 5. Events/External orgs
> 1. Update from meeting with CEN
> 6. *[Focus 1] Where to define mdoc profile over browser API (options
> summarized below) (10 min)*
> 7. VCI (heads-up):
> 1. change credential type identifier vc+sd-jwt to dc+sd-jwt
> https://github.com/openid/OpenID4VCI/pull/415
> 2. Define claims display description and claims path query
> https://github.com/openid/OpenID4VCI/pull/276
> 8. VP
> 1. a lot of new PRs, important for ISO and ID process:
> https://github.com/openid/OpenID4VP/pulls
> 2. *[Focus 2] Issues Important to resolve before ISO mtg Dec 3-5th
> (today is the last call with full participation before the ISO mtg since
> next week is Thanksgiving) (35-40min)*
> 1. intent_to_retain:
> https://github.com/openid/OpenID4VP/issues/321; has PR -
> https://github.com/openid/OpenID4VP/pull/338
> 2. mandatory processing in claims set https://github.com/openid/OpenID4VP/issues/290
>
> 3. value matching: https://github.com/openid/OpenID4VP/issues/322
> and https://github.com/openid/OpenID4VP/issues/307
> 4. x509_san_dns: https://github.com/openid/OpenID4VP/issues/320
> 9. *[Focus 3] mdoc profile for OID4VP over Browser API (10min)*
> 1. PR is in:
> https://github.com/openid/oid4vc-haip-sd-jwt-vc/pull/122
> 2. Issues: https://github.com/openid/OpenID4VP/issues/219; h
> ttps://github.com/openid/OpenID4VP/issues/327
>
> Options on where to define mdoc profile over browser API:
>
> 1. put mdoc profile in OID4VP. if we do this, we cannot mandate
> anything (response encryption, session transcript structure, etc.), so
> probably not a good idea
> 2. put mdoc profile to HAIP. If we do this, HAIP needs to be
> refactored, so it becomes collection of 4 profiles that can be used
> independently:
> 1. Issuance of IETF SD-JWT VC using OpenID4VCI;
> 2. Presentation of IETF SD-JWT VC using OpenID4VP;
> 3. Presentation of IETF SD-JWT VC using OpenID4VP over W3C Digital
> Credentials API
> 4. Presentation of ISO mdocs using OpenID4VP over W3C Digital
> Credentials API
> 3. put mdoc profile into a separate document, and keep HAIP as-is. If
> we do this, we would need to go through the process of adopting a new
> document, and work on 4 documents with tight deadlines. If we do this, one
> question is where to put Browser API profile that is common to both mdoc
> and sd-jwt vc.
>
>
> Thank you!
> Kristina
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241121/863cc652/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list