[Openid-specs-ab] Spec Call Notes 8-Apr-21

nadalin at prodigy.net nadalin at prodigy.net
Fri Apr 9 01:25:39 UTC 2021


I assume you mean RFC 7515 section 3?

 

From: Tom Jones <thomasclinganjones at gmail.com> 
Sent: Thursday, April 8, 2021 5:35 PM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Nadalin <nadalin at prodigy.net>
Subject: Re: [Openid-specs-ab] Spec Call Notes 8-Apr-21

 

by jws may i assume you mean 3-part jose?




Be the change you want to see in the world ..tom

 

 

On Thu, Apr 8, 2021 at 4:46 PM nadalin--- via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net> > wrote:

Clarification, ISO 18013-5 DOES use JWT when using the OIDC flows(and in future when 18013-5 uses SIOP), and non-OIDC flows use MSO (mdoc) but use JWS and not JWT.

 

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net <mailto:openid-specs-ab-bounces at lists.openid.net> > On Behalf Of Mike Jones via Openid-specs-ab
Sent: Thursday, April 8, 2021 11:18 AM
To: openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net> 
Cc: Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com> >
Subject: [Openid-specs-ab] Spec Call Notes 8-Apr-21

 

Spec Call Notes 8-Apr-21

 

Nat Sakimura

John Bradley

Mike Jones

Filip Skokan

Vladimir Dzhuvinov

Brian Campbell

George Fletcher

Adam Lemmon

Tim Cappalli

Bjorn Hjelm

Oliver Terbu

Kristina Yasuda

Tom Jones

Joseph Heenan

 

OpenID Connect Federation Draft

              Roland reported on the Federation Draft progress

              We did three interop events last year

                           There are three independent implementations - by Vladimir Dzhuvinov, Henri Mikkonen, and Roland Hedberg

                           The specification has been iteratively updated to address issues found

              People had been able to largely implement in an interoperable fashion

              Issues from Torsten and Brian were also discussed and addressed

              Leif Johansson pointed out a remaining dependence upon Web PKI

                           jwks_uri uses Web PKI

                           It can be avoided using entity statements with "jwks", but that interferes with key rotation

              Or we can introduce signed_jwks_uri (which apparently we discussed ~2 years ago)

                           This is in Roland's code

                           Roland has asked Vladimir and Henri to also add it

                           Then they'll do interop on the new feature

                           John recalls the signed jwks_uri discussion

                           John asked about how to trust the signature

              Vladimir asked if there had been thoughts of using the Accept header

                           John said that we have used metadata parameters instead of that design pattern

              Mike asked with what key you sign the keys

                           Roland said that the entity statements are self-signed

                           But you're trusting  it because the key is protected by the trust chain

              Roland will create a spec update adding signed_jwks_uri

                           Mike and John will review

                           Roland will ask Vlad and Henri to ask review

              Next Steps

                           Mike said that we could either do another Implementer's Draft or take the spec to Final status

                           John said that he thought we should do another Implementer's Draft

                                         He wants to see the near-final draft be widely circulated

                           Roland reports that Leif is involved in a project that may also be building or deploying it

                                         Roland will check in with him

                           John reports that the spec has come up on Internet2 calls

                           Vladimir reports that there are no real deployments yet - just interoperating implementations

 

Claims for Verifiable Credentials Objects

              Mike summarized some recent discussions on using W3C Verifiable Credential objects with JWTs

              The VC spec defines "vc" and "vp" claims, which are used as part of the W3C-define JWT representations

                           The values of these claims are not complete Verifiable Credential or Verifiable Presentation objects

              The W3C VC spec defines representations for four things, which are the combinations of two sets of two things each:

                           JWT and JSON-LD representations

                           Verifiable Credential and Verifiable Presentation representations

              Mike sent a proposal to the working group defining four JWT claims for these four kinds of objects

                           vc_jwt, vp_jwt, vc_ld, and vp_ld

              John asked where these would be used

                           They could be used in the ID Token, in UserInfo Endpoint responses, and in other sets of IANA JWT claims

              John asked whether we should overload claims, using the same claims for JWT and JSON-LD representations

                           People were opposed to overloading

              Mike tried to respond to Tom's e-mail comment about instead using claim names defined for particular use cases

                           Tom talked about ID Proofing versus Authentication Proofing

                           Tom said that healthcare people have turned data structures into strings and put them in amr values

                           Oliver says that VCs contain a type property

                           Kristina said that VCs and VPs are becoming part of identity for some use cases

                           Tom objects to having generic claims, rather than specific claims

                           Tim said that the VP should be in response to a request with a specific set of requirements

                           Tim supports having generic claims

                           Mike reported on RFC 7800 "cnf" claim naming and the possibility of multiple claim names here too

                                         Just like use cases can define other claims with the "cnf" syntax,

                                         the same could be done here, when needed to distinguish between multiple kinds of W3C VC objects

              George asked whether we want to have all claims be returned in VCs and VPs

                           Mike said, no, that's not what we're doing

                           Tim said that Presentation Exchange has paths to say where claims should to go

                                         https://identity.foundation/presentation-exchange/

                           Tim said that that some use cases will use one or the other

                           Kristina said she views these objects as claims at the same level of things like e-mail

                           George said that he wants to ask for a Mobile Driver's License claim in a format that he can process it

                                         He needs to know the format that the claim will be returned in

                                         Tom reports that Mobile Driver's Licenses will be in ISO 18013-5 format - not JWTs or VCs

                           John said that there are already four JWT claims formats - JSON, Normal JWT, Aggregated, and Distributed

                           George wants there to be metadata about claims

                           Mike said that Edmund's Claims Aggregation draft does enable claims to be requested in different structures

                           https://bitbucket.org/openid/connect/src/master/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md

                           Oliver said that registering a small set of claims seems like a next step

                           George wants to be able to request claims in particular formats, and with particular groupings

                                         That means that would have to work on richer claims requests syntax

              Mike said that he's trying to first solve the simple cases

                           George said that this doesn't preclude more complicated cases

                           Mike said he plans to write the tiny spec and explicitly say what it's not doing

                           Tom said that you can't ask all Claims Providers to support VC formats

                           Tom said that he might also write up a parallel spec for generic JOSE claims

                                         John said that we already have that: aggregated and distributed claims

                           Tom wants to try to remove things from front-end processing

                           John asks whether we want an external dictionary for VCs like we have for aggregated and distributed claims

 

Browser Special Call Report

              We ran out of time for this

              Tim did send notes from the call to the list

 

Open Issues

              https://bitbucket.org/openid/connect/issues?status=new <https://bitbucket.org/openid/connect/issues?status=new&status=open> &status=open

              We ran out of time for this

 

Next Call

              The next regular Connect call is on Monday, April 12th, 2021 at 4pm Pacific Time

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net> 
http://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/20210408/36feb104/attachment-0001.html>


More information about the Openid-specs-ab mailing list