[Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22
Petteri Stenius
Petteri.Stenius at ubisecure.com
Mon Sep 26 18:58:13 UTC 2022
Yes, the subject value of the different credentials is the same. The subject is also the holder and the vp_token is signed by the subject.
Petteri
________________________________
From: Torsten Lodderstedt <torsten at lodderstedt.net>
Sent: Monday, September 26, 2022 19:23
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Petteri Stenius <Petteri.Stenius at ubisecure.com>
Subject: Re: [Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22
Hi Petteri,
thanks for sharing!
It seems from the example the holder binding uses did:web. Are the different credentials bound to the same DID?
best regards,
Torsten.
Am 26.09.2022 um 18:07 schrieb Petteri Stenius via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
Hi,
The selective disclosure model of Finnish ID system is quite simple:
- There's a relatively small number of claims.
- Each claim is issued in a separate credential.
- A relying party can request specific claims by using scope or claims parameter.
- Resulting vp_token contains one or more credentials with the requested claims.
- The wallet app can refresh credentials so that claims such as age_over_18 have valid information.
Link to more detailed information https://wiki.dvv.fi/display/DHHJD/SIOPv2+POC+-+Guide+for+Relying+Parties
Petteri
________________________________
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf of Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Sent: Friday, September 23, 2022 11:36
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Nat Sakimura <nat at nat.consulting>
Subject: Re: [Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22
It would be great if how Finnish LD-Proof is approaching selective disclosure can be documented. It will help this community.
2022年9月23日(金) 4:48 Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>:
SIOP Special Topic Call Notes 22-Sep-22
Mike Jones
Petteri Stenius
David Chadwick
Joseph Heenan
Torsten Lodderstedt
Bjorn Hjelm
Kristina Yasuda
David Waite (DW)
Petteri reported on the Finnish ID system being developed
They have chosen SIOP
It uses a wallet
The credentials will be JSON-LD
There is selective disclosure for age verification
They are building a wallet from scratch to hold the Finnish identity documents
https://dvv.fi/en/-/development-of-the-digital-identity-card-already-far-along-feedback-from-test-users-guiding-completion-of-the-mobile-application
Public Review Period for Proposed Final Unmet Authentication Requirements Specification
Nat had privately asked if there are multiple implementations of the specification
Torsten said that this a mandatory to implement requirement for IdPs using yes.com<http://yes.com>
He said that there are least four different implementations in the yes.com<http://yes.com> ecosystem
Pull Requests
https://bitbucket.org/openid/connect/pull-requests/
PR #240: Add "type" to OP Metadata (Issues #1566, #1592, #1628)
Torsten, Oliver, and David Chadwick are working on a new proposal for credential metadata
It has a credentials_supported structure
It has a "standard" element - for instance "iso-mdoc"
They do not want issuers to have to invent something on top of the existing credential formats
David said that each standard has their own naming schemes
But we can use common display names to present information to the user
Kristina is not a fan of the structure having the "standard" and the "proof" separately
Some of these things are standard-specific already so we don't have to separately declare the "standard"
Torsten understands Kristina's feedback and is leaning in that direction
Torsten simplified his displayed proposed example to eliminate "standard" and to include, for instance "format": "jwt_vc"
Kristina questioned whether to include @context
She said that, as discussed in the VCWG last week, there are JSON credentials that don't use @context data structures
For instance, a "university_degree" credential may be understood by the parties without @context
@context is ignored in JSON-serialized VCs
Kristina requested that this be described in multiple PRs
For instance, the base PR shouldn't introduce @context
Torsten thinks that it may be premature to write PRs
Mike opined that PRs should be written once there is consensus on how to resolve an issue and not before
Torsten said that the decision to drop the top-level parameter has implications
This would also have to be propagated to the authorization_details and credential issuance parameters
The primary parameter "format" would determine the rest
Kristina said that we already have a "format" parameter
This is an extension point
David Chadwick said that the key issue is whether the different metadata formats can be unified or whether they should be format-specific
PR #294: clarifying that aud is not required in a signed request in SIOPv2, issue #1602
DW asserted that this is ready to merge
We discussed the choice of https://self-issued.me to indicate static metadata
DW suggested we change this to https://self-issued.me/v2
We agreed on the call to change it to https://self-issued.me/v2 and then merge
Testing for OpenID4VC specs
Joseph told us about writing tests for the OpenID4VC specs
He is working with David Chadwick on this
Joseph wrote initial tests for the issuance spec
They use the pre-authorized code route
He is also writing initial tests for the presentation spec
Gail Hodges is asking the certification team about testing for the OpenID4VC specs
Joseph doesn't have enough information to do estimates yet
David Chadwick gave some background on his request for tests
He wants to test the features that are already stable
Then add more tests as additional features mature
As background, Mike described that it's the responsibility of the working group to define testing requirements
and it's the responsibility of the certification team to implement the tests
Joseph reported that Kristina, Torsten, and Joseph wrote a document describing the desired tests
Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1643: Define error codes for the Credential Issuance Endpoint
We discussed when to use the HTTP status code 400
RFC 6750, Section 3.1 (Error Codes) describes the use of 400, 401, 403, or 405 with OAuth error codes
David agreed to update the issue based on Torsten's comments and the information from RFC 6750
Next Call
The next call will be Monday, September 26, 2022 at 4pm Pacific Time
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
https://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220926/7a605d1e/attachment.html>
More information about the Openid-specs-ab
mailing list