[Openid-specs-fapi] Next step(s) for FAPI?
Michael.Jones at microsoft.com
Wed Oct 9 18:32:14 UTC 2019
If people want to do HTTP signing, the other alternatives are https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 (which is used in production, despite being expired), the AWS request signing specification<https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html> (which was described in this presentation<https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-http-request-signing-in-amazon-web-services-00> at IETF 105, and is extensively used), and the OAuth DPoP spec<https://tools.ietf.org/html/draft-fett-oauth-dpop-02>, which appears to be on track for adoption by the OAuth working group during IETF 106 in November.
For those of you who aren’t aware of the warning in the Cavage signatures draft<https://tools.ietf.org/html/draft-cavage-http-signatures-11>, it says:
WARNING: DO NOT IMPLEMENT THIS SPECIFICATION AND PUSH THE CODE INTO
PRODUCTION. THIS VERSION OF THE SPECIFICATION IS ONLY FOR
It’s my understanding that Mark Cavage has abandoned the specification and believes it should not become a standard. (At least, that’s how Phil Hunt, also of Oracle, described its status to me.) So it’s surprising to me that there’s even discussion about resurrecting it, given the other good choices already available.
I’ll be glad to be on the special FAPI call on this topic.
From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> On Behalf Of Manu Sporny via Openid-specs-fapi
Sent: Monday, October 7, 2019 6:55 AM
To: openid-specs-fapi at lists.openid.net
Cc: Manu Sporny <msporny at digitalbazaar.com>
Subject: Re: [Openid-specs-fapi] Next step(s) for FAPI?
> Given that Cavage 11 includes the following.
Hi, my name is Manu Sporny, I'm the primary specification editor for HTTP Signatures (draft-cavage-http-signatures).
> The Berlin group and others have had to explicitly reference version
> 10 to avoid using a a spec that says “don’t use this”. This doesn’t
> leave them a way forward with this draft.
There is a version 12 that will be published shortly that won't have that text. We placed the text in there to gather feedback from the community before committing to the specification text as the way forward. As you can imagine, there are currently 25 implementations of the specification and we need to be careful about changes to the specification. We were unsure of some of the backwards-compatible changes we made to this version (we're pretty sure we didn't break anything, but wanted to make doubly sure with implementers before we marked the specification as safe to implement in a non-experimental fashion).
We have published an HTTP Signatures Test Suite to ensure that implementations are actually following the specification:
It sounds like there is a time sensitivity here... what is it? If there is a time sensitivity, we can accelerate the removal of that text.
> I expect that ETSI will look at the desirable properties of the
> Cavages draft and try and come up with something that has the same
This sounds like "we are going to fork the specification"... if you are intending to do that, please don't. There has been tremendous effort placed into getting the spec to where it is, gathering implementations, putting a test suite together, etc. Things that you may feel are unnecessary may result in severe vulnerabilities if removed.
This is the first I'm hearing about this groups desire to use some variation of the specification. How can we, the people building the HTTP Signatures spec, help?
Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
Openid-specs-fapi mailing list
Openid-specs-fapi at lists.openid.net<mailto:Openid-specs-fapi at lists.openid.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi