[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.html>
More information about the Openid-specs-ab
mailing list