[Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22
Torsten Lodderstedt
torsten at lodderstedt.net
Mon Sep 26 16:23:45 UTC 2022
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>:
> 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
>
> He said that there are least four different implementations in the 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
> 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/88e71ef7/attachment.html>
More information about the Openid-specs-ab
mailing list