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

Tom Jones thomasclinganjones at gmail.com
Fri Apr 9 00:35:10 UTC 2021


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> 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> *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-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
> _______________________________________________
> Openid-specs-ab mailing list
> 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/763ee813/attachment-0001.html>


More information about the Openid-specs-ab mailing list