Limitation of current implementation and the furture development plan.

[hanwencheng]

background info about OIDC and OAuth: https://www.youtube.com/watch?v=t18YB3xDfXI

Grant Implementation

In the original proposal, I think we are propose an OAuth + OIDC (OpenID Connect) solution based on Polkadot address. OAuth part act as the handler of authorization, dApp require the authorization from a Polkadot account. OIDC part act as the handler of authentication, dApp require the authentication information with the address with centain Identity.

The current implementation have mainly covered the OAuth part, but we also need to have the OIDC part included (as 6.Lookup Identity part in the grant proposal). As the address sent back could be used as an ID token, we couls send it together with access token to polkadot RPC end point to get the related registered identity data from the identity pallet, which optional includes "email", "name", "display name", "matrix", etc, and encoded them into a JWT.

And of course we want to make the implementation open, so that any one who want to integrate a new identity data resource server could implement by themselves and probably also send a PR to this repo.

Further development plan

Prevent man-in-the-middle attack (high priority)

Currently the signChallenge could sign any data from the server side, imagine a malicious server send a packed transaction for an account and waiting for the user to sign it. We should record different servers public key in list in a decentralized storage (in Litmus for example), so that we could enable domain binding message exchange, and to make sure the chanllenges could always be proved safe.

A decentralized cache data storage. (high middle priority)

In a user-centric network, applications are supposed to store the minim user information, the application-specific configurations need a place to store, for exmaple, dark or light mode of an app, the order of the NFTs to display, etc. A decentralized space or local place could be used to store this information and as a supplement of the identity data. MCP team might be interested in this, as well as Web storage API.

support different chains (high middle priority)

Currently only Substrate-based accounts is supported, we could extend it to other layer-1 blockchains.

List Standard for open contribution (middle priority)

As we mentioned before the public key from different applications iis required, together with the identity data the application requireed, we could format a OIDC Standard list, to let application to have common-standard for federated authentication and authorization service. For example, some application might need email verifitication, then a identity profile with email is required to complete the authorization process.

wallet support with beacon (middle priority)

Currently the integration works only with extension, to have the wide compatibility with mobile wallet, we could integrate Wallet Beacon and Wallet Connect.

Privacy improvement (middle priority)

consent is still missing, if user wants to reject any scope or permission then the user is still not able to use the dApp, this is considered a bad user experience.

different programming language support (low priority)

Especially for the server-side.

Integration with Web2 application (low priority)

With the verified information in user identity, more sophisticated actions on login data could be implemented, for example, on a once user login into a code repository, there could be features like a reward be implemented if a user has crypto wallet information in the profile.

About webAuthn, it is a more device-oriented authentication method, it could be built on top of the OAuth, but I don't have any plans now.

[bdmason]

Regarding identity data in general we could add a helper to do a lookup using Polkadot API to the substrate chain the address is formatted with. That could be used to add identity data straight from the chain.

Just focusing in the high priority items for now:

Man in the middle attack

I'm struggling with this one a bit as signChallenge is client side and relies completely on the browser extension (and the beacon wallet in future). The extension/wallet is responsible for displaying what is being sighed. A phishing attack would be enough to change what is being signed. I think we could make the message being signed human readable to avoid any doubt.

A decentralised cache data storage

This feels like application level data rather than data related to authorisation.

More networks

It currently supports all of substrate as the only lock in is with the browser extension. If you want to use a Kusama account for example, you just select the Kusama account from your addresses. For Ethereum, we either need to change our package name or put it in another package.

[hanwencheng]

This feels like application-level data rather than data related to authorization.

In web2 applications, it is mostly handled by the application's backend, but most dApps interact directly with Crypto accounts does not have the place to store it, so to support this feature is critical for web3 identity management tools like MCP, but not of high priority if we speak of only PolkaSignIn. Priority should be middle.

Other parts look good to me.

[bdmason]

this feature is critical for web3 identity management

I understand now. This needs discussion but I see a couple options:

1. basic identity pallet info (easy)
2. create our own pallet and do a more advanced version that interacts with IPFS

[hanwencheng]

Basic identity pallet info would make things public, and the data structure for Substrate origin identity pallet is quite limited. I would suggest a more privacy preserving way.