Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt a strategy and set of libraries for handling the QR Code #13

Open
OR13 opened this issue Aug 8, 2019 · 6 comments

Comments

@OR13
Copy link
Collaborator

commented Aug 8, 2019

Let use consider the case of using OIDC SIOP QR Codes, separate from potential DIDComm QR Codes.

OIDC SIOP does not have a concrete implementation yet: #14

In order to complete one, we need to commit to the QR Codes and share enough information about the implementation to support Identity Wallet providers.

The specific handling of the QR Codes is according to the spec

@OR13

This comment has been minimized.

@OR13

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 13, 2019

We may consider this ticket resolved once we have some comments of the feasibility of QR Code support for OIDC SIOP from some wallet implementers.

@OR13 OR13 assigned csuwildcat and awoie and unassigned pelle Aug 14, 2019

@OR13

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 20, 2019

https://github.com/hellobloom/share-kit-react

^ Bloom library for handling QR Codes.

@ipatka

This comment has been minimized.

Copy link

commented Sep 20, 2019

We're also looking for ways to make the QR less dense so it works on lower res displays. See PR here: hellobloom/share-kit#60

basically the request data would be at a payload URL within the QR. this will allow us to get super granular about when claims were issue and by whom (whitelist, blacklist)

@kdenhartog

This comment has been minimized.

Copy link

commented Sep 21, 2019

@ipatka I think there's merits to this approach. There's also been some attempts to handle this via a rotating QR code to make the QR like a stream of data. Here's an example: https://github.com/digitalbazaar/qram

One of the considerations of using a link in a QR code is that it has potential analytics concerns. For example, when using bit.ly links bit.ly provides analytics data around the usage of the link to the creator. Do we want to try to prevent the url used from being able to analyze usage in order to account for privacy considerations or should we address these aspects at a later time?

@ipatka

This comment has been minimized.

Copy link

commented Sep 21, 2019

Streaming QRs are a cool solution. Regarding analytics I had imagined that the recipient requesting the data would also host the endpoint with the payload. But I suppose if they were using a standard request they might use a link someone else created. Definitely worth considering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.