Authentication, authorization and signing standards?

144 views
Skip to first unread message

Jørn Wildt

unread,
Jul 8, 2016, 9:24:15 AM7/8/16
to api-...@googlegroups.com
Hi Folks

We have been using OAuth2 for authorization in our APIs for some time. That works fine. We also enable OpenID Connect for authentication. Now our customers need some sort of signing of documents - does anyone here know of some standards for sending a document to a service, letting users supply their credentials and returning back a signed document?

OAuth2: allow users to enable third party services access to their data in our system.

OpenID Connect: allow users to authenticate at third party services using their account in our system.

???: allow third party services to transfer documents to our system and make users sign them using their credentials at our system and then get the signed documents back to the third party service.

Thanks, Jørn

Dale McCrory

unread,
Jul 8, 2016, 9:41:09 AM7/8/16
to api-...@googlegroups.com
Jørn,
You may want to take a look at HTTP Web Signatures. We've implemented this for our server to server API requests and it has enough flexibility that it you could create the signature from your credentials. It does not handle a signature on the response, so that would be need to implemented.

See:
https://tools.ietf.org/html/draft-cavage-http-signatures-03

Here is a Node.js client implementation that accounts for date, URL path, and HTTP method in the message.
http://developers.lingk.io/code_samples/code_samples_nodejs.html

Dale

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

Andrew B

unread,
Jul 10, 2016, 5:01:46 AM7/10/16
to API Craft
If the idea is that the third party can be confident that end user A has indeed signed the document, then the end result could be something that:

- identifies that end user (e.g. email address) and the date they signed
- identifies the document they signed (e.g via its checksum)

e.g.: a JWT like this, signed (overloaded terminology) with your private key:

{
  "signingBy": "fr...@baggins.net",
  "signedOn": "1994-11-05T08:15:30-05:00",
  "documentChecksum": "53e5dac0551205ea"
}

You could then safely (say) email the JWT to the third party, who can verify it against your public key. They can then be confident the user has signed the document.

Notes
0: you might also encrypt the JWT if you want to protect from someone eavesdropping on the third party's email
1: checksum is not idea for this purpose, perhaps the entire document content should be used instead
2: perhaps you also actually need the user's digital signature, e.g. a png of their chicken scratchings, that could be added to the JWT as well

Manu Whig

unread,
Jul 13, 2016, 12:54:31 AM7/13/16
to API Craft
Have you looked at DocuSign? https://www.docusign.com/developer-center

Jørn Wildt

unread,
Aug 1, 2016, 7:48:35 AM8/1/16
to api-...@googlegroups.com
Hi folks

Back again from vacation - thanks for the input, I'll take a look at the proposed systems.

/Jørn

On Wed, Jul 13, 2016 at 6:54 AM, Manu Whig <whi...@gmail.com> wrote:
Have you looked at DocuSign? https://www.docusign.com/developer-center
Reply all
Reply to author
Forward
0 new messages