Any thoughts on securely implementing OAuth2 as a distributed / federated service? Obviously for use by distributed / federated services as well, but if the identity service itself could be decentralized, that would be a big win.
Of course, just using Google and Apple OAuth2 service is already pretty good, and practical from an ease of onboarding perspective.
Out-of-band identity verification is not something I’ve heard discussed as a goal for Spritely, though there’s no reason it couldn’t be integrated with systems otherwise using Spritely software. However, the identity of a given OCapN peer is inherently verified by the nature of ocaps – someone can only have a capability on one of your resources if you give it to them or someone you gave it to gives it to them. The “Revocation and Accountability” section of Heart of Spritely gives a more thorough example of the principles involved.
My core concept of identity is the public key of a private-public key pair, from that permissions for anything that the identity can authorize are “granted” by signature of the private key on the object’s identity, plus any other parameters like time, bandwidth, size constraints. The “holders” of the object pass it to any authorized user. It gets interesting with shared authorities when you are keeping data encrypted at rest in third party locations…
Out-of-band identity verification is quite powerful and secure as compared to local authentication based systems, and it is actually “out there” with several major providers that have hundreds of millions of users already semi-trained in how to use it. It would be nice to have a separate-distributed identity authority to avoid dependence on “the big guys,” but it would be a big uphill climb to get it used outside of your own ecosystem, IMO.
Just a note: https://www.keycloak.org/ - free, open source, free to use commercially, OIDC/OAuth2 implementations…
Envisioning an ecosystem with 100+ auth servers, automated trust auditing / performance monitoring / rating of the servers, and users and application providers establishing IDs and access granting with a small collection of the auth servers that serve them the best.
First: a GUID is a (quantum secure, these days) public key which the identity holder can then prove they are who they say they are through use of the corresponding private key. If anyone else ever “Birthday Problems” their way into a collision with another GUID (which, the theories say should happen sometime well after the heat death of the Universe, but… it’s still possible and even likely when opsec is lax), then both parties to the collision should always: A) abandon use of the collided GUIDs, such as with a gpg revocation certificate: (Getting Started), and if the collided identity is of any value: B) endeavor to re-establish trust under a new key-pair, preferably through other key-pairs still securely associated with the collided key-pair (basic Certificate management stuff…)
Then: various database servers (themselves securely identified through an identical method of asymmetric keys) form the Petnames layer, translating the big binary string GUIDs into human readable names in various contexts for the various end-users of the GUIDs.
Easy Peasy. Remember lessons learned from the past: commit to no particular algorithms, always communicate with extensible protocols which can handle new and unanticipated needs for the same functions, securely identify ALL THE THINGS!!! including the oracles which specify communication protocol standards.
