[Openid-specs-ab] OpenID Connect Call Minutes - 12/8/22

[Tobias Looker]

Hi all, apologies in the delay in sending these out.

OpenID Connect A/B Group - Atlantic Call

Attendees

- Mike
- Kristina
- Vittorio
- Madhu
- Edmund
- Karthik
- Giuseppe
- Naveen
- Adam

Agenda Bashing

Mike: I thought we could provide a status update on all the active specs we have open

*Relayed by tobias on mikes behalf*: What are the status of these specifications?
prompt=create
Native Applications SSO
Unmet authentication requirements error code

Are we ready to have Implementer's Draft or Final votes on any of them?

Vittorio: I would reach out to George directly to confirm this

Vittorio: George made a proposal on the list about idp_hint that I think we should briefly discuss

External Organizations

Mike: SD-JWT call for adoption is in progress at the OAuth2 WG there are few days left for people to provide feedback, conversation is also on going on the JOSE WG about the JWP BoF session that was held at the IETF 114

Federation Specification

Mike: PR raised by Giuseppe on federation spec requiring review https://bitbucket.org/openid/connect/pull-requests/264, a minor correction.

Mike: I've recommended that the editors of the federation spec have a regular call considering there are implementations

SIOP

Kristina: Can we quickly discuss PR https://bitbucket.org/openid/connect/pull-requests/256

Tobias: *context for the PR* Usecases are valuable but not at the start of the spec, lighter context should be provided here to support implementers.

Vittorio: Im not very familiar with the structure of the document but I agree that it should not feature industry usecases at the start, instead be focused on providing enough context to support implementers.

Tobias: I'll try and update the PR to provide context to replace what is lost by shifting the appendix's to the back.

Tobias: *introduced issue https://bitbucket.org/openid/connect/issues/1585/anatomy-of-a-credential-request*

Kristina: I'll leave a comment with some further questions but in general I'm supportive of the proposal

idp_hint proposal

Vittorio: Just a summary of my position, its clearly a concept many vendors have so at first it looks useful. The thing that gives me pause is that the value is often AS specific so the question becomes how much interoperability would be obtained by standardizing a parameter without standardizing an enumeration of possible values it could have.

Tobias: I agree with this perspective, if the way in which client - AS's use this parameter is inconsistent, then standardizing am enumeration of possible values would seem impossible OR likely exclude many usecases and without standardizing possible values for the parameter its usefulness is likely less.


Thanks,

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>



Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
tobias.looker at mattr.global<mailto:tobias.looker at mattr.global>

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>

[Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>

[Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>

[Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220812/5d6e2675/attachment.html>