[HN Gopher] Auth0 Verifiable Credentials
       ___________________________________________________________________
        
       Auth0 Verifiable Credentials
        
       Author : marcosnils
       Score  : 62 points
       Date   : 2022-11-01 21:09 UTC (1 hours ago)
        
 (HTM) web link (verifiablecredentials.dev)
 (TXT) w3m dump (verifiablecredentials.dev)
        
       | woodruffw wrote:
       | I wonder what the benefits of this versus e.g. OpenID Connect[1]
       | are: OIDC is already semi-widely adopted, reuses a popular
       | underlying envelope scheme (JWTs), and performs a similar type of
       | proof (that some identity provider claims something about an
       | identity).
       | 
       | [1]: https://openid.net/connect/
        
         | Alupis wrote:
         | The biggest problem with OIDC is how non-standard every
         | implementation is.
         | 
         | I mean, there is a standard, but then there's what everyone
         | actually does. Even within the standard, there is a very
         | surprising amount of it that is... _optional_.
         | 
         | Even discovery endpoints are non-standard... basics like
         | `/.well-known/openid-configuration` is recommended but not
         | required... and don't even try to guess where /userinfo lives!
         | 
         | Claims are willy-nilly, and even some IDP's provide duplicate-
         | in-intent but different-in-name claims, like `phone_verified`
         | vs. `phone_number_verified`. It's just a complete wild west out
         | there!
         | 
         | Anyone bringing some level of standards to the delegated
         | authentication arena would be very welcome in my opinion.
        
           | woodruffw wrote:
           | I agree completely about OIDC's discovery limitations! If
           | this standard can improve along that axis, then that alone
           | will make it a valuable contribution to the identity space.
           | 
           | I also agree about standardized claim names, although I'll
           | point out that standardizing something like `phone_verified`
           | just pushed the identity/claim value question one level
           | deeper: what does it mean for IdP A to have `phone_verified`
           | versus IdP B? Do they have the same ontological value? That's
           | part of why (IMO) "generalized" identity management has never
           | succeeded: you can make everybody generate the same claims,
           | but you can't assert that they've done a _uniform or
           | sufficient degree of diligence_ for those claims. The only
           | way you can do the latter is to select  "high quality" IdPs,
           | at which point the consistency of the claim names no longer
           | matters.
        
       | adontz wrote:
       | I did not understand if this is somehow related to
       | https://en.wikipedia.org/wiki/Self-sovereign_identity or not.
        
       | Aeolun wrote:
       | Isn't this just Json Web Tokens with a different name? (and an
       | extra step to create a VP, presumably so the expiry on the VC can
       | be longer).
        
         | [deleted]
        
         | Alupis wrote:
         | It is a JWT, but a JWT is just a data format, not a schema.
         | 
         | This VC thing seems to take ID Tokens from OIDC providers a
         | little further and also standardizes what claims you can
         | expect.
        
           | woodruffw wrote:
           | Hmm, I don't know if it's consider JWT to be "just a data
           | format". It's an envelope format (dotted base64'd JSON),
           | combined with a schema for each component in the envelope.
           | That scheme isn't particularly _strict_ when it comes to the
           | payload component, but that doesn 't mean it isn't a schema.
           | 
           | OIDC's well-known discovery[1] also does this kind of claim
           | standardization/expectation setting already. But maybe it
           | goes beyond that, and actually normalizes between different
           | IdPs? I'm not sure what that would entail.
           | 
           | [1]: https://swagger.io/docs/specification/authentication/ope
           | nid-...
        
         | encryptluks2 wrote:
         | It appears to be similar to regular public/private key
         | encryption but with a fancy name to make it seem unique.
        
       | CleverLikeAnOx wrote:
       | This places all the trust in the institution that mints
       | verifiable credentials. (or the institution + Auth0 if they use
       | Auth0).
       | 
       | This is good for use cases where you want to assert that an
       | organization says something about you (e.g., you have a degree).
       | 
       | It is not good for use cases where you want to assert that you
       | say something (e.g., I voted for Blah, or I authorized this
       | transfer).
        
         | wyc wrote:
         | Anyone with a keypair can issue verifiable credentials, and we
         | work on making this simple[0], starting with developers.
         | However, the ultimate challenge will be to be able to associate
         | that keypair to the entity (or abstracted entity) who is making
         | those statements, which is what Web of Trust tried to do, and
         | there are some adjacent efforts to revitalize SPKI-style[1]
         | trust models that are being discussed at RWoT[2].
         | 
         | [0] https://www.spruceid.dev/quickstart
         | 
         | [1] https://en.wikipedia.org/wiki/Simple_public-
         | key_infrastructu...
         | 
         | [2] https://github.com/WebOfTrustInfo/rwot11-the-hague
        
         | chetanbhasin wrote:
         | But I think it's a good use case for organization issued IDs,
         | tickets, or even things like driver's license.
        
           | CleverLikeAnOx wrote:
           | Agreed! I think this is the start of something that will be
           | big in a decade as adoption goes up.
        
             | tomjen3 wrote:
             | Anonymous verification of age is a nice one: Site a
             | generates a bit of bytes, you then take that to a
             | government portal, login and get it signed, then you return
             | with the signature and now the site knows nothing
             | whatsoever about you, other than that you could get a
             | government site to assert that you are old enough to order
             | beer online.
             | 
             | The government site doesn't have to know anything about you
             | either, other than you requested a beer token.
        
         | paxys wrote:
         | It works for both use cases. The only difference between the
         | two is the source of trust (in case 1 it is some issuing
         | authority, in case 2 it is you). There's no reason why you
         | can't issue a certificate for yourself. The receiving party can
         | choose to trust your public key if they wish.
        
       | NovemberWhiskey wrote:
       | Pretty sure this is the same technology as used for e.g. IBM
       | Digital Health Pass, which underlies things like NY's Excelsior
       | Covid pass.
        
       | thesimon wrote:
       | Wanted to take a look at the schemas linked, but identity0.io
       | isn't even registered? oO
        
         | red_Seashell_32 wrote:
         | They don't have SSL enabled (or properly configured). But even
         | with that in mind - it doesn't work.
         | 
         | http://identity0.io/contexts/v1
        
           | remram wrote:
           | Judging by the whois it might have been created by someone
           | who saw this post.
        
       | paxys wrote:
       | The only thing the web identity ecosystem needs is another
       | independent standard - said no one ever.
       | 
       | JWT is already a thing, as is X.509, OAuth/OpenID, WebAuthn...
       | Just use a combination of these that best fits your use case.
       | 
       | "But this new standard will be the true unifying one". Nope, it
       | will not. The most it will do is get some share of usage and add
       | to the chaos.
        
         | bdcravens wrote:
         | https://xkcd.com/927/
        
         | Traubenfuchs wrote:
         | Offerings in the SSI/VD space are currently exploding -some
         | even government backed. Microsoft, MasterCard, Auth0, the
         | European Union are the biggest players that come to my mind.
         | 
         | This will turn the whole billion dollar kyc/identity
         | verification space upside down.
         | 
         | I work in that space.
        
       ___________________________________________________________________
       (page generated 2022-11-01 23:00 UTC)