bifurcation / userinfo-vc Goto Github PK

View Code? Open in Web Editor NEW

0.0 4.0 1.0 219 KB

A core interop profile for Verifiable Credentials in OpenID

userinfo-vc's Introduction

openid-connect-userinfo-vc

Specification of a standard verifiable credential type to convey OpenID Connect UserInfo claims.

Current WG Draft

The current WG-Draft version is built automatically from the main branch and can be accessed at:

https://bifurcation.github.io/userinfo-vc/openid-connect-userinfo-vc-1_0.html

Build the HTML

docker run -v `pwd`:/data danielfett/markdown2rfc openid-connect-userinfo-vc-1_0.md

userinfo-vc's People

Contributors

Watchers

Forkers

bc-pi

userinfo-vc's Issues

remove "https://openid.org/connect/vc/v1" from `@context`

Is anyone planning to host openid.org and define a valid JSON-LD vocabulary to be hosted there?
If not, "https://www.w3.org/2018/credentials/v1" is sufficient as an @context value.
This way it also does not break JSON-LD parsers while being w3c vc-data-model specification compliant.

Introduce user identifier section

It would be helpful to explicitly point out what is used as an identifier for the issuer and the holder as it impacts key management and does not use DIDs (I think?)

remove examples from the overview section?

What is the intended purpose of the sub-sections in the overview section? (Authentication and Authorization, Issuance, etc.)
They seem to provide examples, which I believe are better to be later in the text - in a test vectors section or separately in each of the section defining each aspect of the protocol.

Reusing standard OIDC claims?

I thought the whole purpose was to specify the reuse of Standard OIDC claims?
https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

this document intentionally reuses the claims defined by OpenID Connect

But I do not think there is an explicit section

Priming Request Example

The response to the priming request is described as an error response, but the return is an HTTP/1.1 200 OK. Should there be some other response that indicates an error, or is this not really an error response?

Reconsider "Decentralized OpenID-based Login" as a use-case

I am pretty against advocating to use VCs to authenticate, it leads to claim based authentication which is a well-known security vulnerability. there are much more secure passwordless options available. and using sub in a Self-Issued ID Token or a self-signed VC to re-authenticate the user identifier using a VC is a different use-case.
We cannot stop people to use claims in the VCs to authenticate, but we should not explicitly advocate for it.

Rename UserInfoCredential to UserInfoVerifiableCredential

There may be other credentialtypes (even in the decentralised world, there is quite a proliferation of formats), so being more specific in the label may be useful. It also makes for easier reading - I kept reading about UserInfoCredential, and then about verifiable credential and had to stop and remind myself that these are the same (this last point may be just a quirk of my mental processes).

add out of scope section

suggest moving "The RP may then use the VC in a VC presentation protocol (outside the scope of this document) to demonstrate the End-User's identity to a Verifier." to an out of scope section

rename "OpenID Connect Verifiable Credential Format"

What is being called a format is not a format. A format used is what has already been defined in w3c vc-data-model spec - JSON encoded JWS signed W3C VC - an identifier defined in VCI spec

What this section does, is defining specific values for the properties for a format. https://github.com/bifurcation/openid-vc-core/blob/main/openid-vc-core.md#openid-connect-verifiable-credential-format

suggest adding a cryptographic alg section

There seem to be certain requirements around crypto algorithms which should be separated into its own section

The alg value MUST represent a digital signature algorithm supported by the Verifier. The alg value MUST NOT represent a MAC based algorithm such as HS256, HS384, or HS512.

Rewrite terminology section

If terminology is the same as defined in another specification, please cite that specification, instead of redefining.

Why is there a need to return an ID Token?

Is it a requirement to return an ID Token?
OpenID4VP is based on OAuth and ID Token is optional. I have not found a reason to mandate ID Token in this document but I migh tbe missing something.
I suggest removing ID Token from the overview.

"Priming Request" not defined

What is a "Priming Request"?
I would strongly advice against adding a new endpoint to a profile of an existing specification.
If it is needed, let's discuss in VCI core spec.

Besides I think what is meant by a primer request is defined in the specification already:
https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#section-8.3.2

Add in-scope section and rewrite the introduction

Introduction is misleading because it states that the following three things are defined:

a Verifiable Credential format that carries OpenID Connect claims,
profiles the general OpenID for Verifiable Credential Issuance specification to provide a similar level of interoperability to OpenID Connect
a standard mechanism for an OpenID Provider to express credential revocation information.

In my mind there is only one thing - an interop profile - being defined and a revocation mechanism and values for specific JWT claims are just parts of the interop profile that are in-scope for it. please see this section: https://identity.foundation/jwt-vc-presentation-profile/#scope

Using "sub" to convey the jwk

I wonder if we need a different claim than "sub" to represent the key that was bound to the user to avoid potential confusion and even implementation errors.

Rename the document

related to issue #2, calling this document OpenID Connect Verifiable Credentials is too broad of a scope and is too conflicting with OpenID4VC spec family that it builds upon. Suggest to pick something more specific to a particular use-case it tries to address.

align with the structure of a VCI spec

I think the document will be more readable if it aligns with VCI spec.
so that the it is clear what is being defined in this profile and what are the requirements for the optionalities in the VCI and other specs used.
Right now, the reader needs to read step by step to pick out what are the requirements on top of VCI.

Rewrite the document so that it is clear that it is a profile

Please rephrase all of the sentences that imply that this document defines a new mechanism/standard. It is a profile of specification to ensure interoperability using existing drafts/published specifications. These are two very different things.

For example, "This document extends OpenID Connect with an interface by which a Client may request a Verifiable Credential attesting to the user's identity attributes." this is what OpenID4VC spec does already, and this profile builds on top of it.

Consider splitting issuance protocol profile from the VC profile

There are two things being profiled in the doc and it may be easier to keep the profiles of the credential format (VCs) seperate from the issuance protocol.