[Openid-specs-ab] Spec Call Notes 22-Jun-20

[Mike Jones]

Spec Call Notes 22-Jun-20

Mike Jones
Nat Sakimura
Tim Cappalli
Tom Jones
Tobias Looker
Orie Steele (hasn't yet signed IPR agreement)
Edmund Jay

Introductions
              Tobias and Orie are new to the call, so we did introductions
              Tobias Looker works for Mattr in New Zealand doing identity standards, including DIDs and VCs
              Orie Steele - CTO of Transmute in Austin, decentralized identifiers, DIDs, W3C CCG, uses OpenID Connect
                           An author of https://identity.foundation/did-siop/

OAuth JAR
              Mike reviewed Nat's PRs
                           He asked to use the name "require_signed_request_object" that we'd agreed to on the Connect calls
                           And to prohibit "alg":"none" when this is true

Self-Issued OP Discussion
              Edmund's working claims aggregation draft
                            https://bitbucket.org/edmund_jay/oidc-claims-aggregation/src/master/OpenID%20Connect%20Claims%20Aggregation.md
              Tobias' client bound assertions draft
                           https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
              Tobias wants to receive a bound assertion from an OpenID Connect flow
              Tom described a similar need in the healthcare space
                           Tom wants to have a "bound token" that is bound to the issuer and the recipient
              Tobias said that a standard OpenID Connect audience can't authenticate
                           Whereas a bound token is more like a DPoP token
                           He believes that the best binding mechanism is public key crypto
              Nat asked what the use case is for re-presenting an ID Token is
                           Tobias: How do we know that the SIOP provider is entitled to present the aggregated claims?
              Tobias: They don't want to have to use the "highly-available issuer" model, where the issuer is always online
              Tom: In our case, the identity proofing statement and the authentication capability statement come from different sources
                           The third thing would be a proof of presence statement
                           Tom made some of the claim values be JWSs
              Nat: Tony is working on Zero Knowledge Proof (ZKP) JWT assertions
              Tom: We need interoperable key rollover
              Tom's rough draft
              https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
              Nat presented about SIOP at Identiverse last year
                           https://www.youtube.com/watch?v=GR29JQ-eB1k
              Tom wants claims to be verifiable in the sense that you can check the signature but they don't need to be online
              Tom: Sometimes the user and the subject are not the same entity
                           For instance, parents making claims for children
                           Nat said that this is an authorized party use case
              Tobias: How do you request claims from other claims providers in the authentication request?
                           Nat: Right now there's not a way to specify the authoritative source for a set of claims
                           Nat: This could be for SIOP or a normal OpenID Provider
              Tobias: You may want claims from particular sources and/or at particular assurance levels
                           Tom: Sometimes Federations arrange assurance
                           Nat: We intentionally punted these policies to the trust frameworks used
                            Tom: You need a federation authority
                           Nat: "acr" can be used to specify a trust framework
              Mike: How does this related to OpenID Connect for Identity Assurance
                           https://openid.net/specs/openid-connect-4-identity-assurance-1_0-10.html
                           Tobias: All claims have some form of assurance associated with them
                                         Organizing them into two buckets is problematic
              Tom: Different communities are using different terminology in the verified claims space
              Tom: The entity statements from OpenID Federation can also be useful

Self-Issued OP Meeting
              Mike asked how we're going to run a meeting of 50+ people on this very interesting topic
              Nat: We'll have to mute everyone
              Nat: Only the speakers will be unmuted
                           Speakers will get 10-15 minutes
              Mike: How will we take questions?
                           Nat: Use chat window to raise hand, then Nat will ask the questioner to speak
              It will be a lot like a panel discussion with ~6 speakers

Tobias' Claims Request Document
              Mike asked about some details of Tobias' claims/credentials request and response
                           Why have a separate credentials response field?
                           You could add that to the Token Endpoint but how would it work for SIOP?
                           Tobias: We tried to avoid an assertion in an assertion, but we could do that
              Mike: Wouldn't you want to be able to return multiple verifiable credentials?
                           Tobias: This was about a single request from a single authority

Federation Interop
              Status for last week's Federation interop was sent to the mailing list.  See the e-mail:
                           OpenID Connect Federation June 2020 interop report

Next Calls
              Nat is going to ask the list whether to make the 4pm Pacific Time call weekly rather than bi-weekly
                           This would work for people in New Zealand
              The next working group call is Thursday, July 2 at 7am Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200623/2bdc23e2/attachment.html>