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

Mike Jones Michael.Jones at microsoft.com
Thu Apr 8 18:17:38 UTC 2021


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&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/95dec051/attachment-0001.html>


More information about the Openid-specs-ab mailing list