coolaj86
/
issuer.rest.walnut.js
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

changed manual wrap of README to 80 characters

This commit is contained in:
tigerbot 2017-06-30 14:26:12 -06:00
parent c62cd15644
commit 9518c3c190
1 changed files with 22 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
README.md
View File

@ -3,15 +3,18 @@ issuer@oauth3.org (js)
Implementation of server-side RESTful OAuth3 issuer APIs. Implementation of server-side RESTful OAuth3 issuer APIs.
These are the OAuth3 APIs that allow for creation and retrieval of public keys used for signing identity tokens. These are the OAuth3 APIs that allow for creation and retrieval of public keys
used for signing identity tokens.
"issuer" is somewhat of a misnomer from the OIDC breakdown of authentication / authorization parties. "issuer" is somewhat of a misnomer from the OIDC breakdown of authentication /
What we mean by "issuer" here is actually more like "notary" or "authorized verifier". authorization parties. What we mean by "issuer" here is actually more like
However, since the "iss" field is already standardized, we keep that name for consistency. "notary" or "authorized verifier". However, since the "iss" field is already
standardized, we keep that name for consistency.
What's to be implemented: What's to be implemented:
Looking at <https://oauth3.org/.well-known/oauth3/directives.json>, the core issuer components are these: Looking at <https://oauth3.org/.well-known/oauth3/directives.json>, the core
issuer components are these:
``` ```
api: api.:hostname api: api.:hostname
@ -25,13 +28,17 @@ authorization_dialog :scheme//:hostname/api/issuer@oauth3.org/authorization_d
logout :scheme//:hostname/api/issuer@oauth3.org/#/logout logout :scheme//:hostname/api/issuer@oauth3.org/#/logout
``` ```
No `access_token` endpoint is strictly necessary. Since clients can create and manage their identity, the can sign create their own tokens. If the identity is stored on the issuer, then the issuer can also sign tokens. Doing so gives full control of all resources owned by the subject "sub" to the issuer "iss". No `access_token` endpoint is strictly necessary. Since clients can create and
manage their identity, the can sign create their own tokens. If the identity is
stored on the issuer, then the issuer can also sign tokens. Doing so gives full
control of all resources owned by the subject "sub" to the issuer "iss".
``` ```
create_sub: :scheme//:hostname/api/issuer@oauth3.org/subs/:secret/:sub create_sub: :scheme//:hostname/api/issuer@oauth3.org/subs/:secret/:sub
``` ```
And here are some others that are useful, but could be implemented differently without breaking the protocol. And here are some others that are useful, but could be implemented differently
without breaking the protocol.
``` ```
credential_create: :scheme//:hostname/api/issuer@oauth3.org/logins credential_create: :scheme//:hostname/api/issuer@oauth3.org/logins
@ -46,7 +53,7 @@ The `sub` field must be `sha256(secret + ':' + azp)`.
Example: Example:
``` ```js
var secret = '8f7acd369764df342d1581872ff5f70fcc261aa116b3c41dee7ca3474ee2020f' // cryto.randomBytes(32).toString('hex') var secret = '8f7acd369764df342d1581872ff5f70fcc261aa116b3c41dee7ca3474ee2020f' // cryto.randomBytes(32).toString('hex')
var sha256 = cryto.createHash('sha256'); var sha256 = cryto.createHash('sha256');
sha256.update(new Buffer(secret, 'hex')); sha256.update(new Buffer(secret, 'hex'));
@ -55,16 +62,15 @@ sha256.update(':' + 'example.com');
var sub = sha256.digest('hex'); var sub = sha256.digest('hex');
``` ```
This way any issuer can transfer ownership of identity to any other issuer and deterministically reproduce the ppid This way any issuer can transfer ownership of identity to any other issuer and
by virtue of the secret identity of the subject and the public identity of the authorized party and the key is known deterministically reproduce the ppid by virtue of the secret identity of the
to be good if the issuer "iss" can supply the public key that verifies the token, identified by its thumbprint "kid" subject and the public identity of the authorized party and the key is known to
(which the issuer knows without revealing its ppid of the subject and without the authorized party needing to reveal be good if the issuer "iss" can supply the public key that verifies the token,
its ppid of the subject. identified by its thumbprint "kid" (which the issuer knows without revealing
its ppid of the subject and without the authorized party needing to reveal its
ppid of the subject.
jwks jwks
---- ----
The jwk endpoint needs to reveal the jwk by thumbprint as well as some The jwk endpoint needs to reveal the jwk by thumbprint as well as some
```
```