[Openid-specs-digital-credentials-protocols] Minutes from Hybrid DCP / SIOP meeting at Cisco

[Joseph Heenan]

DCP / SIOP WG Minutes - Hybrid @ Cisco 9th Oct 2023

Attendees:

Gail Hodges
Mark Haine
Kristina Yasuda
Don Thibeau
Mike Leszcz
Paul Bastian
George Fletcher
Nancy Cam-Winget
Vikas
Andrew Lim    
David Waite
Andreas Freitag
Bjorn Hjelm
Brian Campbell (remote)
Giada Sciarretta
Mark Dobrinic
Pedro Felix
Michael Palage
Giada Sciarretta
Shigeya Suzuki
Rajvardhan Deshmukh
John Bradley
Jacob Ideskog
Joseph Heenan
Mark Dobrinic
Dima Postinov
Mike Jones
Allan Foster
Chrisitan Bormann
Sunil Kishor Pathak


Letter of intent for NIST

Gail:

Letter of intent for NIST reference applications for digital identity. Not binding statement of interest from OIDF. Want to try and align their testing work and ours. They suggested we register as a ‘service provider’ to align with their process.

Draft: https://docs.google.com/document/d/1zKRZytBuilnasFuPT-gJuSuiG9uK0UC-2MoFSVH_12U/edit

We need to select a day-to-day technical contact to represent the WG etc to NIST.

Want to send letter in next few days.

George: OIDF hasn’t traditionally done code/libraries. Not sure what we would produce in this context. “Explore” or “support work around” wording is fine.

Gail: Does anyone see any risks to foundation?

Mark: How much effort is needed from WG?

Gail: Unknown at this stage. Usual work for tests.

Joseph: We probably need WG to educate them on the specs etc.

Kristina: Should emphasis more on tests. 

Joseph: I can be technical point of contact for now and we can see how it evolves and maybe switch out.


Issues

https://github.com/openid/OpenID4VCI/issues/82

https://github.com/openid/OpenID4VCI/issues/77

Pedro: Deciding this should help us figure out how to solve other issues. No strong use case. Does offer always relate to entry in metadata?

Paul: Don’t like adding too many options. If we’re not sure don’t offer inline as it’s just another option to be implemented.

Kristina: Torsten/I don’t think it’s necessary.

Paul: If we only need it in the metadata we should just include only the metadata id in the request. Means the request format is independent of credential type.

Kristina: Does anyone have a use case for it being inline?

Jacob: We don’t typically require people to publish all their supported scopes, providers have good reason to have private values for their own use sometime.

John: Could allow a private value that is a reference, doesn’t need to be published and hence would only be useful to internal parties.


Kristina: If we agree it’s a reference to something it won’t be a scope. Just an identifier.

Pedro: This makes it easier to understand. Makes the job of the authorization server harder as it needs to go into the type / credential subject to know what it can authorise.

Kristina: Need to distinguish different types of identifier. This is a different value from the reference to a particular credential. If using scopes look up the scope, it’s simple but no credential instance identifier. Can do with RAR though.

Pedro: Offer is now an object again then?

Kristina: Don’t know, we can discuss if we agree on the use of identifier first. To sum up: we do not want to enable passing the entire set of credentials inline in the offer. Will use an identifier that points at metadata or is a pre-agreed private value. Different from credential instance identifier which can be passed in authorization_details. Passing credential instance identifier will not be available with scopes. People shouldn’t use scopes if they want more advanced features.

Paul: What is the idea behind the credential instance identifier?

Kristina: You need to tell the wallet how many times to call the credential endpoint. Returning an identifier for each credential communicates this.

Paul: Sounds similar to batch credential endpoint.

Kristina: Example is university credential for different courses - same credential type so can only distinguish by using an instance identifier.

Paul: Could solve this in the UI of the issuer with different buttons for different credentials.

Pedro: Issuer doesn’t have UI.

Kristina: Can be interaction before you have the offer

Pedro: In that case the result of that interaction gets included in the offer.

Kristina: Is there value in passing credential instance identifier in the offer?

Pedro: A complete example to discuss would be good. E.g. if I have two children and want to obtain birth certificates for both of them.  I go to the issuer and select the children and pay for 2 birth certifies. What is in the credential offer? Do I get two offers? Or two entries but they point to the same metadata entry?

Kristina: Just one reference to the metadata then two instance identifiers is one way.

Pedro: Can we do this without needing to add identifiers?

Kristina: Depends what wallet needs this information that it’s getting two credentials. If wallet is going to display consent screen that includes details of two credentials.

Pedro: Wallet needs to know there are two credentials.

Kristina: Currently wallet doesn’t know this till the token endpoint response.

Paul: should be in token endpoint response then.

Kristina: PR 65 defines this. Communicates which instances an access token is valid for.

Pedro: When wallet starts authorization request is doesn’t currently know how many credentials etc. Does it need to show this to the user before starting?

Kristina: No current way for wallet to display to user that 2 birth certificates will be issued. Could include same reference to metadata twice.

Paul: Batch endpoint can be used for privacy reasons, issuing the same credential multiple times for unlinkability (e.g. 10 copies of your national id card). Need to distinguish between multiple copies of one credential vs different credentials that have same metadata identifier.

Pedro: It’s sensitive to scan a qr code and open something that starts asking for username/password. Providing context to user is important.

Kristina: So it is beneficial to have credential instance identifiers in offer?

Pedro: Not sure

Michael: There are some edge cases, like governments might issue you two identical passports.

Pedro: If you don’t provide an identifier the job of the authorization server is harder. If user has multiple credentials of same type it doesn’t know which one to issue.

Kristina: If you’re doing authorization code flow you can use issuer state or pre-auth code flow can include it. But wallet can’t understand those, they’re opaque to wallet.

Kristina: We’re okay with offers containing references to credential metadata ids?

No objections raised by today’s participants.

Credential Instance identifiers

Kristina: Main user consent in wallet happens after wallet has received response from issuer. “You’ve received these credentials, is that okay?”. Offer is not trusted by definition, so what wallet can display based on it is pretty limited. Maybe wallet doesn’t need to show more info at this point in which case we don’t need instance identifiers in the wallet?

George: Do we have mockups of expected user experiences? The UX will drive whether this works or not, it really matters. 

Paul shows their demo for issuance of verified email credentials.

George: There’s a valid attack where I end up with someone else’s credential in my wallet and then accidentally use it.

Paul: Is it useful to tell the user that they’ll get multiple credentials of the same type if the user can’t see what the values in the credentials actually are?

Jacob: You don’t need to be more explicit with the question to the user than “do I trust this issuer?”

George: So the accept screen on the wallet is more about showing who the issuer is and does the user trust the issuer?

Joseph: Not just about trust, also about whether the user is expecting to receive a credential from this issuer at this point in time.

Kristina: Difficult to show too much info on the wallet “do you want to accept credential offer” screen.

Pedro: There are two decision points for the user. What bad things can happen after this first decision point?

Kristina: in pre-auth code flow there’s no user question at this point in our product. In Auth code flow we do, to nudge the user to go to authz endpoint and login. Agree it’s about trusting the issuer.

Paul: So we can’t see a use for instance identifiers in the offer?

Kristina: Seems like it. Can we review the PR about adding instance identifiers to token endpoint response? https://github.com/openid/OpenID4VCI/pull/65/files

George: If wallet & issuer are same (first party context)  you don’t need the “trust the issuer” screen.

Jacob: There are 3 times the user needs to agree:

Authorization consent in code flow at issuer
Do I trust the issuer at wallet?
Do you accept these credentials at wallet?



George will open issue about wallet consent screen

Kristina: Are we agreed we don’t need instance identifiers in the credential offer?

Paul: Information in the credential offer can’t be trusted anyway.

Kristina: In auth code flow, Issuer will only know how many credentials it will issue after the user logs in.

Jacob: If we sent identifiers in offer it would/could replace issuer_state.

Kristina: We pass far more than the identifiers in the issuer state. It would still be an opaque string. Issuer_state (in auth code flow) is meant to be equivalent of pre-authorized-code (in the preauth flow). Issuer state could also include info about which user is expected to login.

Pedro: passing issuer state in rar would be preferable to having a new top level parameter in the authorization request

Kristina: If we can minimise breaking changes to existing implementations that will make it easier for the protocol to scale.

Joseph: We can’t assume everyone is supporting RAR

Kristina: Is there a use case for passing issuer state independent of the grant type being used?

Jacob: Is limiting us to the two grant types okay?

Pedro: If we support other grant types we’d need to expect the offer to tell the wallet what to do.


Consensus that instance identifiers in the token endpoint response are valuable as we need a mechanism to signal that there are multiple credentials to wallet and there’s no other mechanism on the table.

Please review https://github.com/openid/OpenID4VCI/pull/65/files


Kristina: identifiers are important for refreshing a credential.

Paul: Would I use credential endpoint for 2 passports vs batch credential endpoint for multiple instances of the same credential? Should we merge the credential endpoint into the batch credential endpoint?



Use HTTP Accept-Language Header to request Issuer Metadata


https://github.com/openid/OpenID4VCI/issues/84


Jacob: Is there any reason not to go with the accept-language header?

Joseph: accept language seems better than defining our own mechanisms

George: It’s difficult sometimes to make this kind of change to servers.

Kristina: We need to support 50 different languages and many credentials. The metadata is pretty heavy. Do we need the metadata to be queriable for only one credential identifier so the wallet doesn’t have to retrieve metadata for all credentials if it has?


David Waite: Language selection algorithms get complicated. Letting the server figure out what is has that most closely matches what language the wallet asked for. Static files would mean a lot of files and be quite complex.


Kristina: So there’s support for Accept-language header?

John: Trying to reinvent accept-language would be a significant effort.

Kristina: Are we just filtering credentials_supported?

Paul: No, we have language specific data in other places too.

Kristina: We need another example under 10.2.3. Are only the two display elements being filtered per language?

Pedro: The for the issuer itself. There’s another one inside each entry in supported credentials. And a format specific one for each claim in the specific credential format. 

Kristina: That’s a lot of places to customise.

Paul: Can we return only one language?

Joseph: Some cases we will return only one language for each item, but the language may be different if one credential’s display data is only available in one language. E.g. user may want English, but one credential only has Japanese description



User PIN description and length

https://github.com/openid/OpenID4VCI/issues/10

Paul: Wallet needs a hint of tell the user what they are inputting into the pin field, e.g. “pin has been sent to you via email”. And wallet ui is better if wallet knows the length. How do we communicate this to the wallet?

Pedro: Variant of option a but put multiple locales inside.

Paul: But QR code gets very big

Jacob: We may have enough info to guess the user language

Paul: Kind of feels like it belongs in the metadata as we have all other language specific things there. But user pins may be coming from different sources depending on if user has app / email is known / whatever.

Paul: Option b is no good as text needs to be dynamic. More about option a or d.

Pedro: ‘d’ makes metadata even more complex, it’s already complex.

Kristina: “a” requires localisation support.

Jacob: if you need the language part do ‘c’

George: then you have to use uri option if you need language support

Consensus towards options ‘a’ and ‘c’.

Discussion around whether you can restrict character set. You can’t because we need to render kanji etc.

George: This just needs to be a security consideration, wallet may need to scrub strings.


Kristina: Can I declare this ready for PR with options a / c?

Consensus yes.

Should we have a size limit? Not sure. Paul to make a suggestion.

Kristina asked if people could consider and comment on some of the issues she raised recently:


- Credential Issuer using multiple authorization servers · Issue #72 · openid/OpenID4VCI (github.com) <https://github.com/openid/OpenID4VCI/issues/72>
- Credential Offer pointing to a specific `credentials_supported` metadata entry. · Issue #83 · openid/OpenID4VCI (github.com) <https://github.com/openid/OpenID4VCI/issues/83>
- related Obtaining parts of the Credential Issuer Metadata · Issue #42 · openid/OpenID4VCI (github.com) <https://github.com/openid/OpenID4VCI/issues/42>
- Credential Endpoint lacking the information about the user session · Issue #79 · openid/OpenID4VCI (github.com) <https://github.com/openid/OpenID4VCI/issues/79>
- Issuer using managed service to hose Issuer Metadata · Issue #80 · openid/OpenID4VCI (github.com) <https://github.com/openid/OpenID4VCI/issues/80>
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20231011/0c96d9cd/attachment-0001.html>