clarify wallet invocation when credential offer is sent #246

Sakurann · 2024-01-31T06:19:46Z

resolves issue #201.

openid-4-verifiable-credential-issuance-1_0.md

jogu

I think if we're going to make changes to this section then it needs a bigger rework.

The credential offer endpoint is a specific thing - we are defining the properties of the credential_offer_endpoint entry in the client meta data. In my opinion, the metadata for a client probably shouldn't ever be openid-credential-offer:// as this value is only expected to be used when there isn't client meta data available for the wallet.

Section 4 should probably be renamed from 'Credential Offer Endpoint' to just 'Credential Offer', and a new 4.1 added called something like 'Credential Offer Endpoint' that explicitly defines credential_offer_endpoint metadata. Or the text that has been added to section 4 should instead be in section 11.1 where the credential_offer_endpoint is defined (and the IANA section should be updated to reference 11.1 instead of 4 as it does currently).

Finally, the 'no specific value' case should be better defined if we want interoperability. I think it is implying that the endpoint URL is treated as the empty string and hence the qr code would contain start with '?' but this isn't actually stated, i.e.

?credential_offer=%7B%22credential_issuer%22:%22https://credential-issuer.example.com%22,%22credentials%22:%5B%22org.iso.18013.5.1.mDL%22%5D,%22grants%22:%7B%22urn:ietf:params:oauth:grant-type:pre-authorized_code%22:%7B%22pre-authorized_code%22:%22oaKazRN8I0IbtZ0C7JuMn5%22,%22tx_code%22:%7B%22input_mode%22:%22text%22,%22description%22:%22Please%20enter%20the%20serial%20number%20of%20your%20physical%20drivers%20license%22%7D%7D%7D%7D

Sakurann · 2024-01-31T20:19:15Z

@jogu I am simply trying to resolve issue #201, because the issue rightly pointed out that HTTP GET and redirect is not what most implementers use - QR code is much more used, so it felt that the spec better reflect the reality.

you are making valid points, if you could open the issues, we can address them accordingly, but I am not convinced this PR cannot go in without larger changes you suggest.

Sakurann · 2024-01-31T20:29:21Z

I think it is implying that the endpoint URL is treated as the empty string and hence the qr code would contain start with '?' but this isn't actually stated, i.e.

sure, this can be clarified, but why use ? if there is no URL...

jogu · 2024-02-01T06:28:11Z

@jogu I am simply trying to resolve issue #201, because the issue rightly pointed out that HTTP GET and redirect is not what most implementers use - QR code is much more used, so it felt that the spec better reflect the reality.

you are making valid points, if you could open the issues, we can address them accordingly, but I am not convinced this PR cannot go in without larger changes you suggest.

The minimum would be to move the newly added text that is defining properties of credential_offer_endpoint to section 11.1 and to reference that section from section 4 but really all the points I make apart from the existing issue with the IANA considerations pointing to the wrong place are issues newly created by adding in the non specific url qr codes option.

jogu · 2024-02-01T06:33:39Z

I think it is implying that the endpoint URL is treated as the empty string and hence the qr code would contain start with '?' but this isn't actually stated, i.e.

sure, this can be clarified, but why use ? if there is no URL...

That was my attempt to interpet what the currently proposed text means.

I think the reason to use a '?' would be because we're still expecting everything in the offer parameters to be URL encoded as if it was present in the URL query, and included a leading '?' means that it is a valid relative URL.

It could work either way, and it would probably be good to know what implementers using this option actually do - but if we're adding it to the spec I believe we should be very clear about how it works otherwise implementations won't be interoperable.

jogu · 2024-02-01T06:40:55Z

openid-4-verifiable-credential-issuance-1_0.md

 ## Credential Offer {#credential-offer}

-The Credential Issuer sends Credential Offer using an HTTP GET request or an HTTP redirect to the Wallet's Credential Offer Endpoint defined in (#client-metadata).
+The Credential Issuer sends the Credential Offer using one of the following mechanisms:


The reference to (#client-metadata) (where credential_offer_endpoint is defined) has been removed here but needs to be kept somewhere in this section.

jogu · 2024-02-01T06:41:25Z

openid-4-verifiable-credential-issuance-1_0.md

+- A case sensitive URL using the `https` scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components.
+- Custom URL scheme. For example, `openid-credential-offer://` as defined in (#client-metadata-retrieval).
+- Domain-bound Universal Links/App link.
+- No specific value. The issuer displays a QR code containing the Credential Offer, which the user can scan with a manually opened Wallet, or an arbitrary camera application on the user-device.


If there's no specific value, it only works in a wallet (or at least some app that is aware of the VCI spec), it wouldn't work in an arbitrary camera app.

I know that our Android wallet app has a "Scan QR code" option inside it, so this definitely works. I "think" that our IoS phone allowed the camera to scan the QR code and then it automatically launched the wallet app, but I am no longer able to test this.

@David-Chadwick Interesting. Can you give an example of QR code contents that didn't use a https url nor a custom url scheme and resulted in the system camera app launching the wallet?

I think my conclusion (after asking on the WG calls) was that this 'No specific value' option isn't used by anyone so I think we should omit it (both here and in VP).

I think the only thing people might be doing is potentially ignoring the custom scheme when scanning a QR code in a wallet. Seems reasonable to mention that wallets might choose to do that.

jogu · 2024-02-01T06:44:56Z

openid-4-verifiable-credential-issuance-1_0.md

+
+- A case sensitive URL using the `https` scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components.
+- Custom URL scheme. For example, `openid-credential-offer://` as defined in (#client-metadata-retrieval).
+- Domain-bound Universal Links/App link.


I think this is still a https url as per the first bullet, I would incorporate this into the first bullet but add "This may be a Claimed "https" Scheme URI as described in https://datatracker.ietf.org/doc/html/rfc8252#section-7.2" (and that RFC explains about Universal Links, App links, etc).

jogu · 2024-02-01T06:46:29Z

openid-4-verifiable-credential-issuance-1_0.md

+
+Credential Offer Endpoint can take one of the following values:
+
+- A case sensitive URL using the `https` scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components.


I don't think 'case sensitive' is needed or helps here (the case sensitivity & insensitivity of the various different parts of a URL are already well defined). (Disallowing a URL query is also technically a normative change unrelated to the issue we're trying to solve - the current spec doesn't really say that anywhere.)

jogu · 2024-02-01T07:03:25Z

openid-4-verifiable-credential-issuance-1_0.md

-The Credential Issuer sends Credential Offer using an HTTP GET request or an HTTP redirect to the Wallet's Credential Offer Endpoint defined in (#client-metadata).
+The Credential Issuer sends the Credential Offer using one of the following mechanisms:
+
+- Render a link that the End-User can click resulting in an HTTP GET request to the Credential Offer Endpoint.


I don't think there is any reason to restrict this to a link. (A button would be fine.)

I think something like "Sends the user agent to the Credential Offer Endpoint" (i.e. similar language to how OAuth 2 talks about the redirect url) is sufficient, which covers all possible cases include a HTTP redirect. (It'd be fine to include "For example, a link ... or a HTTP redirect...".)

I agree that this has to changed. But opening a native app is technically not sending the user agent to the credential offer endpoint. It is also not following a redirect nor a HTTP GET request.

What about:

Suggested change

- Render a link that the End-User can click resulting in an HTTP GET request to the Credential Offer Endpoint.

- Render a link that the End-User can click resulting in following the link to the Credential Offer Endpoint.

yaromin · 2024-02-08T11:19:20Z

openid-4-verifiable-credential-issuance-1_0.md

-This endpoint is used by a Credential Issuer that is already interacting with an End-User who wishes to initiate a Credential issuance. It is used to pass available information relevant for the Credential issuance to ensure a convenient and secure process.
+Credential Offer Endpoint is used by a Credential Issuer that is already interacting with an End-User who wishes to initiate a Credential issuance. It is used to pass available information relevant for the Credential issuance to ensure a convenient and secure process as defined in (#credential-offer).
+
+Credential Offer Endpoint can take one of the following values:


In this context the Credential Offer Endpoint is not a parameter thus it can't have a value. This is ideal as a description of a metadata parameter.

What we need in this section is an explanation that the Wallet has such endpoint and that it is used to pass the Credential Offer to the wallet. This section doesn't say that now.

yaromin · 2024-02-08T12:02:27Z

openid-4-verifiable-credential-issuance-1_0.md

 # Credential Offer Endpoint {#credential-offer-endpoint}

-This endpoint is used by a Credential Issuer that is already interacting with an End-User who wishes to initiate a Credential issuance. It is used to pass available information relevant for the Credential issuance to ensure a convenient and secure process.
+Credential Offer Endpoint is used by a Credential Issuer that is already interacting with an End-User who wishes to initiate a Credential issuance. It is used to pass available information relevant for the Credential issuance to ensure a convenient and secure process as defined in (#credential-offer).


Suggested change

Credential Offer Endpoint is used by a Credential Issuer that is already interacting with an End-User who wishes to initiate a Credential issuance. It is used to pass available information relevant for the Credential issuance to ensure a convenient and secure process as defined in (#credential-offer).

Wallet exposes the Credential Offer Endpoint, enabling the Credential Issuer to pass the Credential Offer to the Wallet, thereby initiating the Credential Issuance process. In this way, the Credential Issuer, which an End-User interacts with, uses Credential Offer to pass to the Wallet information necessary for convenient and secure Credential Issuance process defined in (#credential-offer) .

I would apply this change and in the line below indicated that there are several strategies Credential Offer Endpoint strategies like link, custom scheme, qr code and so on.

Sakurann · 2024-03-07T04:58:27Z

i need to update this PR - will do next week, sorry.

jogu · 2024-09-27T09:12:53Z

I believe this has been superseded by #380 - closing on that basis to keep the PR list to items we're actively working on, please feel free to reopen if I'm mistaken.

try add wallet invocation kind of section

d6c6a6c

Sakurann requested review from awoie, bc-pi, c2bo, danielfett, decentralgabe, jogu, paulbastian, peppelinux, tlodderstedt and tplooker January 31, 2024 06:19

Sakurann mentioned this pull request Jan 31, 2024

Add a section of Wallet invocation #201

Closed

David-Chadwick requested changes Jan 31, 2024

View reviewed changes

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved

openid-4-verifiable-credential-issuance-1_0.md Outdated Show resolved Hide resolved

jogu requested changes Jan 31, 2024

View reviewed changes

Apply suggestions from David's code review

76f10a2

Sakurann requested a review from David-Chadwick January 31, 2024 20:29

jogu reviewed Feb 1, 2024

View reviewed changes

Sakurann mentioned this pull request Feb 8, 2024

Issue #255 proposal of the updated language of the credential offer s… #257

Closed

yaromin reviewed Feb 8, 2024

View reviewed changes

jogu closed this Sep 27, 2024


		Credential Offer Endpoint can take one of the following values:

		- A case sensitive URL using the `https` scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components.

	- Render a link that the End-User can click resulting in an HTTP GET request to the Credential Offer Endpoint.
	- Render a link that the End-User can click resulting in following the link to the Credential Offer Endpoint.

	Credential Offer Endpoint is used by a Credential Issuer that is already interacting with an End-User who wishes to initiate a Credential issuance. It is used to pass available information relevant for the Credential issuance to ensure a convenient and secure process as defined in (#credential-offer).
	Wallet exposes the Credential Offer Endpoint, enabling the Credential Issuer to pass the Credential Offer to the Wallet, thereby initiating the Credential Issuance process. In this way, the Credential Issuer, which an End-User interacts with, uses Credential Offer to pass to the Wallet information necessary for convenient and secure Credential Issuance process defined in (#credential-offer) .

clarify wallet invocation when credential offer is sent #246

clarify wallet invocation when credential offer is sent #246

Uh oh!

Conversation

Sakurann commented Jan 31, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jogu left a comment

Choose a reason for hiding this comment

Uh oh!

Sakurann commented Jan 31, 2024

Uh oh!

Sakurann commented Jan 31, 2024

Uh oh!

jogu commented Feb 1, 2024

Uh oh!

jogu commented Feb 1, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jogu Feb 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sakurann commented Mar 7, 2024

Uh oh!

jogu commented Sep 27, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

jogu Feb 1, 2024 •

edited

Loading