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

nadalin at prodigy.net nadalin at prodigy.net
Thu Apr 8 23:35:50 UTC 2021

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> 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
Cc: Mike Jones <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

              Issues from Torsten and Brian were also discussed and

              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

                           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

                           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

                           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

              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


                           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


                           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

                           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


              We ran out of time for this


Next Call

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210408/72a31d2b/attachment-0001.html>

More information about the Openid-specs-ab mailing list