[Openid-specs-ab] SIOP Special Call Notes 17-Feb-22
Torsten Lodderstedt
torsten at lodderstedt.net
Fri Feb 18 08:34:33 UTC 2022
Hi,
On issue 1400.
> Kristina said that DW indicated on the last Connect call that Ping Identity plans to use "iss" for a trust framework reference
> Torsten said that a trust framework reference could be included elsewhere in the ID Token
I also mentioned that OpenID Connect 4 Identity Assurance (https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID3.html) defines syntax for conveying information about trust frameworks and so on. I suggest to use this as basis for solving Ping’s requirements.
We also had a good discussion about trust frameworks and schemes in the context of OIDC4VPs. David has created a PR: https://bitbucket.org/openid/connect/pull-requests/107 <https://bitbucket.org/openid/connect/pull-requests/107>
@DW: May I ask you to fill an issue with your requirements?
best regards,
Torsten.
> Am 17.02.2022 um 20:11 schrieb Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
>
> SIOP Special Call Notes 17-Feb-22
>
> Mike Jones
> David Chadwick
> Kristina Yasuda
> Kenichi Nakamura
> Daniel Fett
> Jo Vercammen
> Petteri Stenius
> Torsten Lodderstedt
>
> Open Pull Requests
> https://bitbucket.org/openid/connect/pull-requests/ <https://bitbucket.org/openid/connect/pull-requests/>
> PR #124: [oidc4vci] clarify sub value in the ID Token Issue #1426
> We agreed to merge this
> PR #107: Support for federations using the termsOfUse property
> Torsten tried to validate the JSON and it failed
> David Chadwick said that he believes the JSON is correct
> He discussed this on the DIF PE call in the past week
> Torsten said that the PE JSON Schema doesn't work
> And that some ideas that have been discussed are not actually in the spec
> Torsten checks all the examples he adds to specs to make sure they are valid
> Mike stated that we should fix the known syntax problems in the examples before merging
> This is related to:
> https://github.com/decentralized-identity/presentation-exchange/issues/303 <https://github.com/decentralized-identity/presentation-exchange/issues/303>
> https://github.com/decentralized-identity/presentation-exchange/issues/280 <https://github.com/decentralized-identity/presentation-exchange/issues/280>
> Torsten said that he would work with the PE folks on these issues
> PR #120: Issuer Handling SIOP
> The corresponding issue is #1400, where there's been good discussion lately
> Kristina said that DW indicated on the last Connect call that Ping Identity plans to use "iss" for a trust framework reference
> Torsten said that a trust framework reference could be included elsewhere in the ID Token
> Torsten said that the PR is in good shape and includes the rationale for this change
> Kristina referenced Stephane Durand's comments
> Mike said that merging this will enable us to put trust in the issuer - unlike self-issued.me <http://self-issued.me/>
> Kristina said that the PR has been updated to reflect actionable comments
> Unless more actionable comments have been filed, we proposed to merge it in a week
> Torsten said that this change surfaces differences in people's mental models of SIOP
> Torsten said that DW's comments mostly mean that we need additional data in the ID Token
> Torsten said that these should be captured in separate issues and not block merging this PR
> PR #101: Fetching presentation definitions from a remote repository
> David said that he copied the metadata text from OpenID Connect Discovery
> Torsten said that there's three ways to pass parameters in connect - in the URI, using "request", and using "request_uri"
> He said that the default is that a request conveys all the parameters in the URI
> Kristina expressed support for having a default
> Mike did too
> David said that presentation requests can be too big to include in URIs
> Torsten said to use PAR then
> Kristina said that using request_uri is another way to handle the large size
> David said that request_uris can be referenced by multiple parties, which he sees as being a feature
> Torsten said that doing anything by reference increases complexity for all parties
> Including hosting and maintaining the externally referenced data
> Mike asked if Torsten could propose specific changes to establish the default
> Kristina suggested that we file an issue asking people's opinion on whether there should be a default and what it should be
> David agreed to file that issue
> Jo asked for another week to consider this PR
>
> Open Issues
> https://bitbucket.org/openid/connect/issues?status=new&status=open <https://bitbucket.org/openid/connect/issues?status=new&status=open>
> #1436: Mental Models
> David observed that sometimes people are talking past one another because they have different mental models of SIOP
> He listed a number of them in the issue
> Kristina made a detailed comment in the issue
> Kristina said that in a recent Connect call, the biggest confusion observed was between authentication and conveying claims about the user
> Torsten thanked David for filing the issue
> He wants to think about the points made and respond
> Mike also requested time to review the details of the issue
> We agreed to discuss this on the next SIOP call in a week
> #1399: SIOP with any OIDC flow
> We agreed to park this until PR #120 is merged
> #1379: Resolving Client_ID
> Kristina expressed that we don't need to mandate registration
> Mike said in Connect Core, we enable registration but don't mandate it
> In some cases, registration happens out of band
> He thought we should do the same here
> Torsten agreed with Mike's comments
> Kristina said that there's a difference between mandating something and there being a default
> Torsten pointed out that there's a description of Mandatory to Implement features in OpenID Connect Core
> See https://openid.net/specs/openid-connect-core-1_0.html#ImplementationConsiderations <https://openid.net/specs/openid-connect-core-1_0.html#ImplementationConsiderations>
> Mike credited Torsten for that and said that it has been very useful
> Torsten said that we should do the same thing for SIOP
> Kristina is resolving this issue until we gain more deployment experience
>
> OpenID Foundation SIOP Strategy
> Kristina reported that there is $12,000 approved for writing a SIOP whitepaper
>
> Next Call
> We are cancelling the Monday, February 21, 2022 call due to the Presidents Day holiday in the United States
> The next Connect call will be on Thursday, February 24, 2022 at 7am Pacific Time
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> https://lists.openid.net/mailman/listinfo/openid-specs-ab <https://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/20220218/2c78f3fc/attachment.html>
More information about the Openid-specs-ab
mailing list