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

feat: add jwt-vc support #8

Merged
merged 4 commits into from
Jun 6, 2023
Merged

feat: add jwt-vc support #8

merged 4 commits into from
Jun 6, 2023

Conversation

TimoGlastra
Copy link
Member

@TimoGlastra TimoGlastra commented Jun 5, 2023

Adds support for latest AFJ with JWT VC support. As the JWT creds don't have the credential display, I changed the display logic a bit and separated it into a getCredentialForDisplay. Now we don't have to change the logic in the wallet, if we want to get the properties from somewhere else.

Draft as I haven't tested it yet.

@TimoGlastra TimoGlastra marked this pull request as ready for review June 6, 2023 10:20
@TimoGlastra
Copy link
Member Author

Now fully works with JWT credentials (have removed support for JSON-LD as it doesn't work without patches).

The credential rendering now infers a name for the credential from the type if the credential doesn't include it and satizies that, but the issuer is not really inferable.

@janrxyz this is how it looks now. Maybe you can take a look and make sure it account properly for the case where we don't have any metadata at all (in same cases we maybe don't even have a name)

You can check several credentials on https://jff.walt.id/

IMG_1022

IMG_1021

@TimoGlastra
Copy link
Member Author

IMG_1020

@TimoGlastra TimoGlastra requested a review from janrtvld June 6, 2023 10:23
Signed-off-by: Timo Glastra <[email protected]>
packages/ui/src/utils/utils.ts Show resolved Hide resolved
key={credentialRecord.id}
// FIXME: what do we do if there's no name of the credential or the issuer?
// We can extract the name from the credential type maybe, but that's quite hacky.
name={display.name ?? ''}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we check the values here? Or should we always return a name in getCredentialForDisplay?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should set a default in the getCredentialForDisplay, so we always have a unified representation of a credential. What do you think?

What should the default name be in that case though?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, makes components look cleaner. We can try and extract it from the type? Or name it Credential from <ISSUER_NAME> if that is less hacky. I think everything is better than nothing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already try to extract it from the type, but only when there's more than one and it isn't an url.

Otherwise it will be VerifiableCredential, which is a bit useless.

In some cases we also don't have an issuer, so we really don't have any variable sometiems. Should it just be 'Credential' in that case?

Fun idea: I think AI would be quite good to come up with a name based on the fields (if there's a simple on-device tool for it)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess 'Credential' should suffice for now.

Great AI use case. We can use AI to select a fitting icon for the credential as well, or even a fitting background image.

@janrtvld
Copy link
Contributor

janrtvld commented Jun 6, 2023

I'll take a look after this is merged.

@TimoGlastra TimoGlastra merged commit c36d19b into main Jun 6, 2023
@TimoGlastra TimoGlastra deleted the feat/jwt-vc-support branch June 6, 2023 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants