[Openid-specs-ab] SIOP Special Topic Call Notes 22-Sep-22
Tom Jones
thomasclinganjones at gmail.com
Fri Sep 23 13:33:20 UTC 2022
Is there any indication that this would serve as a driver's license?
thx ..Tom (mobile)
On Fri, Sep 23, 2022, 3:42 AM Nat Sakimura via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> 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/20220923/5df7650c/attachment.html>
More information about the Openid-specs-ab
mailing list