what is the relationship between previews and extensions

[bslassey]

(Req-Preview) Solution SHOULD allow for extensibility and discoverable extensions (preview of share invitation).

What do extensions have to do with a preview?

[dimmyvi]

It's the ability to preview the credential sent via a URL-link (e.g. Opengraph format or similar) and ability to "forward" the link to a wallet app (e.g. deep-links mechanism)

[bslassey]

I'm still missing what this has to do with extensions

[dimmyvi]

ok, agree, will rephrase this

[bslassey]

Separately, in terms of enabling an app to show a preview, is there a way the protocol could prohibit this? In the very least if none of the information is readable, an application can show an icon. Are there requirements or nice-to-haves around this preview?

[dimmyvi]

I think the idea is to use a single URL link in order to 1) read preview information (in some recognizable format) and 2) read secure Provisioning information to redeem it for a credential in a wallet. If solution/protocol does plan for it/ facilitate it, then it shall be in the requirements list. That is our vision. Do you think this a valid argument?

[bslassey]

I think the key thing is to separate the requirements from the solution. What I am hearing is that you want the solution to make available in the initial message format some sort of data such that the receiver can show a preview. Is that correct? If so, what sort of data should be made available?

[dimmyvi]

In a few words - preview should contain data that can describe a pass that being received by a device - before provisioning it - Title, short description, some visuals (i.g image). The format shall be recognizable by most messaging applications - hence, we propose OpenGraph in our implementation. At the same time, for simplicity and best user experience, separating the transfer of credential info from the message that 1 device sends to another (in a form of URL) we want the same URL to return 1) a Preview in the format that can be recognized by most messaging apps - and automatically generate a preview of the pass, 2) some web-page to be shown in a web-browser (in case when the application does not recognize the format in 1)) , and 3) encrypted provisioning information - recognized by a specialized mobile application that can handle provisioning flow (e.g. wallet) and have implemented existing provisioning protocols integration protocols (e.g. CCC) or integrated with existing Credential Authorities (e.g. Multi-Family homes - Unified Credentials)

[dimmyvi]

We simply don't want to re-invent the provisioning wheel and offer a new provisioning protocol, but maximally reuse existing protocols, applications and device features to solve a particular problem. That's why we so insist on just transfer of credentials, without the actual provisioning part.

[bslassey]

This is the requirements doc, so we need to list the requirements. I don't see how describing the requirements of a preview implies re-inventing the provisioning wheel.

[alexpell00]

This is kind of a UX requirement. We want to say the protocol must enable provisioning info preview functionality. What do you think about something like:

(Req-Preview) Provisioning Information MUST be preview-able in messaging channels before redemption. This preview SHOULD include a title, subtitle, and image.

[bslassey]

That's certainly an improvement, can you make a PR for it?

[alexpell00]

Sure thing!

[dimmyvi]

Should we close the issue - as it is resolved with the PR above?