Hi
yesterday on the Substrate builders program call, Joshua suggested i post this here.
I am looking for the comments on the library i built, which i believe will benefit all in web3 space.
The library is called web3-api-auth-token (WAAT), it is designed to be modular and to support multiple of different Strategies ( or networks ).
Here is the link, oss/README.md at 22f85a75887ddcf65fe411e008f9bc7ba2d3203f · kelp-hq/oss · GitHub
Thank you so much for sharing @woss ! Would you be able to add to your comments on the context, especially how it can use Substrate included in this particular strategy below?
@joshua.cheong I made a disclaimer already 
The tutorial will come soon, and the lack of it should not be a stopper for understanding the concept. 
On the other hand here is how we are using it in the Macula web app right now and here how it is used in the microservice with the express auth middleware
Why strategy is base64 encoded? If it is just a string, use as a string. That also helps with readability.
Why base64 encode different parts and concatenate them with a separator? Wouldn’t it be better if you concatenate the raw data first then base64 encode?
It will also be good if there are more examples and use cases to show why this is not just a fancy JWT and that will help inspire others to come up more use cases as well.
@xlc thanks for the response I’ll try to explain your points:
Why strategy is base64 encoded? If it is just a string, use as a string. That also helps with readability.
readability for that field and servers do not care. if that’s the case then number 1 makes sense.Why base64 encode different parts and concatenate them with a separator? Wouldn’t it be better if you concatenate the raw data first then base64 encode?
No. If you encode it all, then you MUST decode all of it every time, which might not be the case for ALL possible strategies. If you do this it is a design flaw and you are forcing ALL the potential strategies to conform to this.
It will also be good if there are more examples and use cases to show why this is not just a fancy JWT and that will help inspire others to come up more use cases as well.
fancy JWT. JWT requires a centralized server, whereas this does not. If you are referring to a similar structure, well, there is a reason why JWT went for 3 parts instead of one. I suggest you read the intro and the RFC + the code implementation for the JWT, and you will realize that it is all about flexibility rather than imposing the structure.Note on this, the initial version of the WAAT was built to be a single base64 encoded string. then when we started building the app and the middleware it became obvious that that design is too restrictive.
Thanks for the explanation. That makes lot more sense now. Looking forward for the upcoming changes.
Hello woss! Have you ever heard of OpenID Connect? It is build on top of OAuth2 and relies on JWTs. OpenID Connect and OAuth 2 protocol are decentralised in their design, since they do not enforce the Identity Provider to be a centralised entity. Plus, I would argue that JWT is simply a data container with a standardised semantic and serialisation. JWT on its own does not care about the context it is used in.
Furthermore, a lot of effort has gone into defining standards for decentralised technologies such as DIDs (Decentralised Identifiers) and Verifiable Credentials, both of which have also compact representation for use cases where network bandwidth is a constraint.
The OpenID Foundation has also started working on integrating DIDs and Verifiable Credentials into OpenID flows, as is the case for SIOPv2 (Self-Issued OpenId Provider) and OpenID4VP.
TL;DR: my main point is that we should strive towards building on and contributing to standards that have already been defined, to increase the likelihood of cross-system interoperability, rather than coming up with new standards that are most likely only ever used in a small subset of use cases within a given ecosystem.
This said, we at KILT are doing exactly that: trying to work towards bridging the Dotsama ecosystem with decentralised identity technologies and standards that have been or are being defined in a much larger crowd than the Dotsama space on its own. Hence, it would be very nice to have chat and figure out if we can work together towards that goal 
Hey @woss. I’ve been also thinking about this problem and have been drafting some ideas, mostly to tackle the problem from the client/wallet side.
spec Draft: Web3 Authentication (Design Draft): - HackMD
jw3t: jw3t
example debugger
I had a few community calls to collect feedback and see if we can come up with a standard for this type of scenarios as a community. Great to know about this work. Form the client side, having a standard for self-sovereign id-tokens is very useful for hybrid scenarios where the user needs to log in to dapps using their wallet to maintain/access their off chain data, though the same can be also extended to service to service authentication.
@ntx_x2 re current solutions like OpenId/Oauth, my view is that most of the web2 solutions are designed with a 3rd party issuers/providers in mind and might not be well suited for web3 scenarios, The claims are not very readable if the message is going to be signed by end users, and flows might have some unnecessary complexities for web3 scenarios though those complexities were necessary for web2 were token issuer is a 3rd party, but when an entity signs and issues tokens with their own keys many of openId, Oauth flows are not necessary. So I think coming up with more nimble standards and solutions for Web3 is a good idea though it would be wise to stay consistent as much as makes sense.
DID is an abstraction with decentralization in mind and does not need Oauth/openId compatibility as far as I know, so any token container that works for web3 solutions can be integrated into DID.
Hey @hamid.
I went through the specs ( not super thoroughly ) and yes, you are right, we are tackling the same problem with the slightly differnet approach.
@ntn_x2 I have been using OAuth when it was v1 and JWT when they came out; also i’ve build complex system on both, modules, plugins etc … So i’d say i have heard of them and they do not solve the problem we are tackling here. DID are the only decentralized approach that can work together with libs ( jw3t and waat ). I don’t see why we need to intro the SSI into this, but that’s out of the scope for this thread (happy to continue on some other channels, you can send DM if you want )
The JWT is not a solution to all and i do not agree that we should build a library that follows exactly the way of another library that was created with different approach in mind. meaning that JWT requires the isuer server, where the WAAT does not. Also the JWT header is built with generic way in mind and i have almost NEVER used anything different than the defaults. The WAAT is trying to declutter the header and use the Strategy approach where the header is a flag what to use. Think of it as a multibase encoding where the first character is the encoding and then the rest is the encoding value.
Sorry I am a little late to the party here. I came because I’m a big fan of Gavin’s philosophy - mainly what he’s blogged since 2014. But the very birth of OpenID meeting OAuth is sort of covered in Gavin’s (no wiped from the live web and erased from the Internet Archive!) Blogspot post where he coined the term “Web 3.0”… I interpreted Gavin’s stance on using the existing advantages of (oauth) type networks that Facebook and Twitter have and adding a way to secure by using back ends that are Web 3-like (BitCoin and NameCoin as he points out) and a front end with a true Web 3 UI browser to “Secure” auth ones ID across the entire “Web 3”… I am a skilled archivist so I found the index.html to Gavin’s original blog and posted it here for all to read on the Keybase Files System (KBFS) satoshi0x dot keybase dot pub
As for those back ends. OpenID met blockchain and the idea to sign a message in a “metamask” like Web3 tool/wallet/browser to securely sign in to a website without giving up the local control of your private keys! It occured in the first idea for blockchain gaming in post #14 and #16 (which quoted #14). 14 brought up what would become how to sign a message in a metamask to login in to a marketplace like OpenSea … or a Metaverse game…
#16 described he was working on that and it was not for gaming at the time but would work with OpenID - which became known as NameID (nameid dot org still up) by Dr. Daniel Kraft (domob). The funny part is, now all three continue the same work on a chain agnostic and Polkadot substrate inclusive “Metaverse”…
This is my first post here. I have to join bc of Gavin stepping down to show my respect. I can’t wait to see what comes next with Gavin back developing… <3 Btw I have no idea where I found these, but they were on one of Gavin’s old blogs - Gavcoins
Polkadot and Polygon are really the only projects I follow on the “EVM” or front end type side. But I do remember Gavin and Ethereum (the original) was written in C++ … So Ive always loved following Gavs work! He’s like Szabo to me. I read their blogs, its too bad Szabo disappeared but we still got Gavin. 2 visionaries.