[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
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-aggreg
ation/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210408/72a31d2b/attachment.html>
More information about the Openid-specs-ab
mailing list