[Openid-specs-ab] Spec Call Notes 22-Aug-24

[Joseph Heenan]

Attendees

Nat Sakimura
Marcus Almgren
Joseph Heenan
Stefan Liström
John Bradley
George Fletcher
Roland Hedberg
Jan Vereecken
Davide Vaghetti
Brian Campbell
Michael Fraser
Stefan Santesson
Filip Skokan
Michael Jones
Giuseppe
Giada Sciarretta
Bjorn Hjelm
Tom Jones
Pamela Dingle
Kristina Yasuda



NIST Releases Second Public Draft of Digital Identity Guidelines for Final Review

Document here:

https://www.nist.gov/news-events/news/2024/08/nist-releases-second-public-draft-digital-identity-guidelines-final-review

Webinar 28th August: https://nist.zoomgov.com/meeting/register/vJItcu6oqj0jH4xWLbz350jf6VeKM9bMjWc#/registration

Another webinar on September 13th is likely apparently. Deadline for comments is 7th October.

Nat noted that since the first draft passkeys have been added in part B and wallet related things in part C.

Introductions from new attendees

Stefan Santesson: consultant mostly for the Swedish government around wallets and other things, has worked with the federation spec in the past

Stefan Liström: from Swedish Research Council / Sunet. Working with Leif Johansson and involved in work around the wallet particularly the EU LSP DC4EU.

Jan Vereecken: works for meeco, building API based wallets for organisations and users, exploring cross border use cases

Davide Vaghetti: Works for Gar Italian National Research Education Network, is the service owner for eduGAIN, a worldwide federation, letting all the entities belonging to national research and education network worldwide to connect each other, currently working on implementing OID Federation for eduGAIN.

Giada Scriarretta: FBK (organising of last OWS in Italy) - working in Potential LSP, supports activities mainly related to trust, model revocation and threat model.


Open Issues

George spoke about the issues Valdimir has raised for native SSO spec ( https://bitbucket.org/openid/connect/issues/2167/native-sso-codify-login_required & https://bitbucket.org/openid/connect/issues/2166/native-sso-is-the-openid-scope-required-in ). One is a normative change, one is mostly a clarification.

Text has already suggested text/refined and George plans to open a PR to cover over the next few days.



Wallet/Federation Draft

Nat spoke about his personal suggestions for taking this draft forward:

1. Create a "Scope" section in the document towards the beginning, clearly stating what this document is going to include. 
    This should make it clear that the portion that is discussed in the thread to be moved to DCP WG drafts are not in scope. 
2. Move those "out-of-scope" content to a non-normative annex so that it is clear that they are just FYI. 
3. Organise a presentation at DCP WG of the draft. 
4. Incorporate the feedback. 
5. Do another call for adoption. 

Mike: Introduced the spec and the recent changes made to cover 1 & 2, and emphasised that the authors want to work to get items applicable to the OpenID4VC specs defined in those specs and that this spec isn’t trying to normatively define new parameters. Non-normative appendix currently represents what Italy and some other nationalities have built. An entity named was changed based on feedback too (open id wallet relying party has been aligned with the ‘verifier’ terminology)

Giuseppe: The draft was born after more than a year of material implementation in this field with Italian team. Hopes to bring new required items into DCP WG.

Mike: Agree with the issues Joseph has raised about presentation_definitions_supported which would require comparison of json objects to work with browser API, in my mind that's tantamount to doing canonicalization of JSON in order to even be able to do the comparison.

Joseph: Noted that issues for most of the new items have not yet been raised in the DCP WG, which explains why not much progress has been made on adding them to the specifications. Given OID4VC specs already have normative text about Federation we need to agree between the two working groups how that is handled going forward as we shouldn’t spread normative text specific to OID4VC + Federation across multiple specs / working groups. There’s not currently a registry for some of these items (e.g. credential issuer metadata) so in the short term we should try and keep all those items in the main specs so developers don’t have to hunt for their definitions. I can’t currently see how to make presentation_definitions_supported work with the browser API, response_uris_supported suggests using url fragments in a way that doesn’t work and you could consider it to be violating the text in the OAuth Security BCP about exact matching for redirect urls. I’m concerned that adopting this spec with its non-normative text about these items on openid.net/specs/ might lead people to believe these are good patterns to adopt and get us into a bigger mess.

Giuseppe: The metadata parameters are a priority for us. I’d like to get them into OID4VC. Explained the requirement behind presentation_definitions_support (allowing metadata in subordinate statements to limit the queries a relying party can make). For response_uris_supported believe that the most important things is the functional requirement to allow a safe configuration of endpoints attested by a trusted 3rd party  with the possibility to add a sort of randomization to the endpoints.

Joseph:  I completely get the requirements for these things. My point is entirely that the presentations definition supported can't be made to work with the browser Api at all. So I think it's a dead end from that point of view, and we shouldn't encourage other ecosystems to go down that dead end.

Joseph: the problem with the response Uris and the fragments is we've got ourselves into a big mess with a lot of security issues before when we do non exact matching of Urls. So that needs a much bigger discussion based on the requirements. I think, to make sure we don't again send people down weird routes where they just introduce new security problems instead of solving the security problem.

Giuseppe: I hope to open a conversation with the browser API developers on this and a few other issues.

Kristina: I don't know if we should be discussing individual parameters like presentation definitions supported in this call right now. Those parameters should be defined (if at all) in the OID4VC specs and DCP WG and should be discussed there. I'm in full support of defining in better detail of how OpenID Federation can be used with better with wallets. We should coordinate better between the working groups how this is done so we end up with cohesive documents. Any parameters like presentation definition supported, response uri supported, aal values supported, these should not be in that document even in the non-normative section. People glance at these documents, find the parameters and use them. It will be published on openid.net after adopted, mainly people don’t understand the versioning.

Nat: It will be clearly marked as draft.

Kristina: Even if it’s clearly marked as draft, parameters that should go in OID4VP spec should not be created in this document even non-normatively. Document also introduces term ‘wallet provider’ which is not the term used in OID4VC specs. Maybe we should, I don’t know, but we should align on that. Concerned that this is being pushed in Connect WG without much alignment with DCP WG. If these two points are addressed I don’t see any big issues remaining, but without resolving those I’m not comfortable adopting.

Stefan Santesson: Federation documents (both this one and the base federation document) should be careful to focus on distributing and trust of data - metadata and trustmark. It’s a dangerous line to start using the documents for other purposes for convenience, like defining metadata parameters. Also it interferes with how requests are sent and how they are signed, I don’t like that either. We sooner or later get into a place where those rules don't make sense. Metadata parameters unless they target something specifically related to openid federation should be defined in a different place so that the context of federation is very clear - to tell you how to trust and how to extent that trust to the data.

Tom Jones: Wallets will primarily not be used over the internet, the idea that we’re going to force the DCP to look at all the things they’re wanting to look at  irrespective of whether they apply to the specs DCP is working on is mistaken. I’ve tried to talk about query languages there and Joseph has stopped me. DCP should not take ownership of specs like this, they are out of scope for them.

Nat: Next steps - I propose a similar introduction is given to DCP WG so we can get better coordinated and aligned. Both working groups should discuss more to coordinate where things are going to be dealt with, that sounds like a good next step.

Giuseppe: We’re aligned about the requiements, we want the same things, let’s discuss the how.

Mike: As per chat, have volunteered to discuss this on the DCP WG on the immediately following call. [Addition from note taker: in the following call it was agreed that this presentation would happen on 29th August DCP WG call so that any WG members that want to attend have adequate notice.]





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240823/cbcab03f/attachment-0001.html>