From 9518c3c190b9afb00e8002c0b12bdb7ba9ae3aba Mon Sep 17 00:00:00 2001 From: tigerbot Date: Fri, 30 Jun 2017 14:26:12 -0600 Subject: [PATCH] changed manual wrap of README to 80 characters --- README.md | 38 ++++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index 269365a..724199b 100644 --- a/README.md +++ b/README.md @@ -3,15 +3,18 @@ issuer@oauth3.org (js) 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. -What we mean by "issuer" here is actually more like "notary" or "authorized verifier". -However, since the "iss" field is already standardized, we keep that name for consistency. +"issuer" is somewhat of a misnomer from the OIDC breakdown of authentication / +authorization parties. What we mean by "issuer" here is actually more like +"notary" or "authorized verifier". However, since the "iss" field is already +standardized, we keep that name for consistency. What's to be implemented: -Looking at , the core issuer components are these: +Looking at , the core +issuer components are these: ``` 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 ``` -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 ``` -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 @@ -46,7 +53,7 @@ The `sub` field must be `sha256(secret + ':' + azp)`. Example: -``` +```js var secret = '8f7acd369764df342d1581872ff5f70fcc261aa116b3c41dee7ca3474ee2020f' // cryto.randomBytes(32).toString('hex') var sha256 = cryto.createHash('sha256'); sha256.update(new Buffer(secret, 'hex')); @@ -55,16 +62,15 @@ sha256.update(':' + 'example.com'); var sub = sha256.digest('hex'); ``` -This way any issuer can transfer ownership of identity to any other issuer and deterministically reproduce the ppid -by virtue of the secret identity of the subject and the public identity of the authorized party and the key is known -to be good if the issuer "iss" can supply the public key that verifies the token, 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. +This way any issuer can transfer ownership of identity to any other issuer and +deterministically reproduce the ppid by virtue of the secret identity of the +subject and the public identity of the authorized party and the key is known to +be good if the issuer "iss" can supply the public key that verifies the token, +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 ---- The jwk endpoint needs to reveal the jwk by thumbprint as well as some - -``` -```