[Openid-specs-ab] SIOP Special Topic Call Notes 29-Sep-22
Mike Jones
Michael.Jones at microsoft.com
Thu Oct 13 16:03:23 UTC 2022
SIOP Special Topic Call Notes 29-Sep-22
Mike Jones
Mark Haine
Petteri Stenius
Jeremie Miller
David Chadwick
Kristina Yasuda
Brian Campbell
Gail Hodges
George Fletcher
Jo Vercammen
Joseph Heenan
Andrew Hughes
Oliver Terbu
JWP Virtual Interim BoF
There was consensus to re-create the JOSE working group to do the work
The charter was updated per discussions at the BoF - primarily simplifying the introduction
https://github.com/json-web-proofs/json-web-proofs/blob/main/charter-ietf-jose-03.md
The chairs will send the meeting minutes and the charter to the JOSE list for review
Timing-wise, we can't get the JOSE WG recreated before IETF 115 in London
We do plan to have side meetings on the work in London
Jobs for the Future (JFF) Interop Plugfest
David Chadwick reports that JFF https://www.jff.org/ will be holding a second OpenID4VC plugfest the day before IIW
https://w3c-ccg.github.io/vc-ed/plugfest-2-2022/
(This conflicts with the OpenID workshop on the same day)
Next Generation Internet is participating
https://ngiatlantic.info/
Also see https://www.techuk.org/resource/crossword-security-cyber2022.html
FIDO Authenticate in Seattle
Is next week
There's a session of OpenID content
Kristina will be presenting OpenID4VC to the plenary on Wednesday
The talk is free for people to attend remotely
OpenID Workshop
The OIDF workshop will be Monday, November 14th - the day before IIW, 12:30-4:30pm in the Bay Area
Pull Requests
https://bitbucket.org/openid/connect/pull-requests/
PR #327: clarified the definition of response mode post - Issue #1626
Brian asked for an example to be added
Brian said that it's not yet defined what the response content is
It's the authorization response
Brian thinks that the POST name is wrong
The actual OpenID Connect response is carried in an HTTP request message
He thinks that post_response might be more a more indicative response model name for what actually happens
Note that there's already a Form Post response mode that this could be confused with
Joseph agreed with Brian's comments
Joseph proposed direct_post
We discussed preventing the reflection attack
Brian said that there are a lot of security considerations in these cross-device flows that we need to discuss
PR #325: Adds clarifying language around client identification and authentication requirements for token request
Client authentication clarifications
Mike suggested that Brian look at this one
PR #240: Add "type" to OP Metadata (Issues #1566, #1592, #1628)
Torsten made a number of updates
Kristina said that there's an agreement that the type should be format specific
A type can now be an object and not just as a string
Kristina said that JWT-VCs could be two things
A JWT without an @context in the claims
A JWT where the body is valid JSON-LD
Kristina and David reported that lot of productive discussions have happened on this topic
PR #285: Adding batch credential endpoint: fixes #1544
Oliver reported that he and Torsten have had productive discussions on the topic
He plans to update the PR next week
Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1679: [OID4VCI] Missing client id
David Chadwick talked about telling the wallet what client to use
Kristina said that this isn't specific to the pre-authorized flow
Reviews requested
#1607: New well known for issuing?
David wants a .well-known identifier for credential issuers
Joseph questions whether the issuer, in the normal OpenID sense, must be the same as the credential issuer
Kristina said that we use the identifier credential_issuer for that
That's different than the OAuth issuer
He asked if they should share the same "iss" value in tokens they issue
George said that there's two issues
How do I find the metadata
It's probably not a good idea to require that the "iss" value be the same in both cases
Kristina asked can we please rename initiate issuance request to credential offer request?
This is related to issue #1632: Issuer metadata clarification needed
Joseph said that if we're using the same IANA registry for the values, we shouldn't separate the endpoints
David said that if there's only one file, each of the metadata values need to be well-defined and distinct
George observed that if the credential issuer is not an OpenID Provider, then it's weird to use .well-known/openid-configuration for its metadata
If we think of credential issuance as being a new API for an OpenID Provider, then it makes sense
But if it's its own top-level thing, then it should have its own metadata
Kristina said that it's its own top-level thing
Mike said then it should have its own metadata
George said that the issuer could use the OAuth metadata name .well-known/oauth-authorization-server
Torsten proposed openid-credential-issuer
Mike agreed with that
Kristina said that there's rough consensus to have a separate .well-known file
We need to be clear which values should be where
We should follow the OpenID convention of having the .well-known be appended to the issuer path
Mike said that that OAuth convention is acknowledged to be broken
#1648: passing issuance initiation request by reference
Reviews requested
Next Call
The next call is scheduled for Monday, October 17, 2022 at 4pm Pacific Time
However this conflicts with Authenticate
Watch the list to see whether the call will occur or be cancelled
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20221013/644cfcb9/attachment-0001.html>
More information about the Openid-specs-ab
mailing list