From nobody Sat Sep 1 01:47:36 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D73124D68 for ; Sat, 1 Sep 2018 01:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EWVCOlm8ANJ for ; Sat, 1 Sep 2018 01:47:32 -0700 (PDT)
Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7AE12426A for ; Sat, 1 Sep 2018 01:47:32 -0700 (PDT)
Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id w1Z4f5ilCNcYNw1Z5fA2yg; Sat, 01 Sep 2018 01:47:32 -0700
To: Brian Campbell
Cc: oauth
References: <153335394820.18507.18435740800535187975@ietfa.amsl.com> <573d1767-18d4-d02a-dd64-ea4fd684b513@connect2id.com>
From: Vladimir Dzhuvinov
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID:
Date: Sat, 1 Sep 2018 11:47:30 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010905080406030206040409"
X-CMAE-Envelope: MS4wfDFCBKmCDjsC08so0bXU0dmxD4+SI8UdrCObsY1ZOSDhj2fopOtCigmloJTVY3Up+smehH/05mTnkPZaZUB0DpbqwQRMl3q44YX5RgBsY2GsQuhcD3Ac Zafx1Yymx8n2KAkbGzAzsbgaAp5fcto3ZkwM1VVrb6oTiAUv2sCN6QASosD+2Pb9p0Bujkb0IyCafWjGqKqnK8NwUFMgsTiH9zM=
Archived-At:
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt: Error code on failure to parse resource URI
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 01 Sep 2018 08:47:35 -0000
This is a cryptographically signed message in MIME format.
--------------ms010905080406030206040409
Content-Type: multipart/alternative;
boundary="------------8EA247C2C8B95FB8239DD007"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------8EA247C2C8B95FB8239DD007
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thanks Brian.
I assume for a request which contains multiple "resource" parameters, if
one or more of those are invalid, this should also cause an
"invalid_resource" error?
How about the situation when the request includes a "scope" parameter,
with one or more values which don't match the "resource(s)" (or vice
versa) - how should the AS respond in that case?
Have there been thoughts about specifying AS metadata parameters for
publishing the supported resources and potentially their scope mappings?
Mappings could be especially useful for clients to figure out which
scopes belong to which resource, and prevent "invalid_resource" errors.
Similarly, allowed "resources" in OAuth client metadata?
About the statement
> Scope, from Section 3.3
> of OAuth 2.0 [RFC6749 ], =
sometimes is
> overloaded to convey the location or identity of the resource server=
,
> however, doing so isn't always feasible or desirable.
The rationale for the resource indicators spec (for new adopters)
appears to rest on that statement. But what is the actual argument
against overloading scopes, i.e. including the resource URL in the scope
value ;)
Readers of the spec will likely be pondering whether it's better to
encode the resource URL / identifier in the scope, or use the separate
"resource" parameter approach. I think we can greatly help them with a
honest discussion of the pros & cons of the two approaches. And perhaps
suggest how to migrate between the two.
> Bearer tokens, currently the only defined type of OAuth
> access token, allow any party in possession of a token to get access=
> to the associated resources.
Worth mentioning token binding and mTLS here?
Vladimir
On 28/08/18 00:27, Brian Campbell wrote:
> Sorry for the slow response Vladimir,
>
> It seemed worthwhile to have an error code that was more specific than
> "invalid_request" to convey back to the client that there was an issue =
with
> the value(s) it provided for the resource parameter - it's similar to
> "invalid_scope" from RFC 6749 in that regard. Token exchange has someth=
ing
> similar for the resource parameter and I actually need to reconcile the=
> wording and naming in the resource indicators draft to better align wit=
h
> that. I just haven't had a chance to get back into doing the spec edits=
on
> this one yet.
>
>
> On Wed, Aug 22, 2018 at 1:24 PM Vladimir Dzhuvinov
> wrote:
>
>> Hi Brian,
>>
>> If the
>> authorization server fails to parse the provided value or does n=
ot
>> consider the resource server acceptable, it MUST reject the
>> request and provide an error response with the error code
>> "invalid_resource".
>>
>> If the resource parameter is not an absolute URI, i.e. parsing of the
>> value fails, wouldn't the existing general "invalid_request" error cod=
e be
>> more appropriate?
>>
>> https://tools.ietf.org/html/rfc6749#section-4.1.2.1
>>
>> invalid_request
>> The request is missing a required parameter, includes a=
n
>> invalid parameter value, includes a parameter more than=
>> once, or is otherwise malformed.
>>
>> Vladimir
>>
>> On 04/08/18 06:39, internet-drafts@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
>> This draft is a work item of the Web Authorization Protocol WG of the =
IETF.
>>
>> Title : Resource Indicators for OAuth 2.0
>> Authors : Brian Campbell
>> John Bradley
>> Hannes Tschofenig
>> Filename : draft-ietf-oauth-resource-indicators-00.txt
>> Pages : 8
>> Date : 2018-08-03
>>
>> Abstract:
>> This straw-man specification defines an extension to The OAuth 2.0
>> Authorization Framework that enables the client and authorization
>> server to more explicitly to communicate about the protected
>> resource(s) to be accessed.
>>
>>
>> The IETF datatracker status page for this draft is:https://datatracker=
=2Eietf.org/doc/draft-ietf-oauth-resource-indicators/
>>
>> There are also htmlized versions available at:https://tools.ietf.org/h=
tml/draft-ietf-oauth-resource-indicators-00https://datatracker.ietf.org/d=
oc/html/draft-ietf-oauth-resource-indicators-00
>>
>>
>> Please note that it may take a couple of minutes from the time of subm=
ission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.=
org/internet-drafts/
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/=
oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
--------------8EA247C2C8B95FB8239DD007
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thanks Brian.
I assume for a request which contains multiple "resource"
parameters, if one or more of those are invalid, this should also
cause an "invalid_resource" error?
How about the situation when the request includes a "scope"
parameter, with one or more values which don't match the
"resource(s)" (or vice versa) - how should the AS respond in that
case?
Have there been thoughts about specifying AS metadata parameters
for publishing the supported resources and potentially their scope
mappings? Mappings could be especially useful for clients to
figure out which scopes belong to which resource, and prevent
"invalid_resource" errors.
Similarly, allowed "resources" in OAuth client metadata?
About the statement
Scope, from Section =
3.3 of OAuth 2.0 [RFC6749], so=
metimes is
overloaded to convey the location or identity of the resource server,
however, doing so isn't always feasible or desirable.
The rationale for the resource indicators spec (for new adopters)
appears to rest on that statement. But what is the actual argument
against overloading scopes, i.e. including the resource URL in the
scope value ;)
Readers of the spec will likely be pondering whether it's better
to encode the resource URL / identifier in the scope, or use the
separate "resource" parameter approach. I think we can greatly
help them with a honest discussion of the pros & cons of the
two approaches. And perhaps suggest how to migrate between the
two.
Bearer tokens, currently the only defin=
ed type of OAuth
access token, allow any party in possession of a token to get access
to the associated resources.
Worth mentioning token binding and mTLS here?
Vladimir
On 28/08/18 00:27, Brian Campbell
wrote:
Sorry for the slow response Vladimir,
It seemed worthwhile to have an error code that was more specific than
"invalid_request" to convey back to the client that there was an issue wi=
th
the value(s) it provided for the resource parameter - it's similar to
"invalid_scope" from RFC 6749 in that regard. Token exchange has somethin=
g
similar for the resource parameter and I actually need to reconcile the
wording and naming in the resource indicators draft to better align with
that. I just haven't had a chance to get back into doing the spec edits o=
n
this one yet.
On Wed, Aug 22, 2018 at 1:24 PM Vladimir Dzhuvinov <vladimir@connect=
2id.com>
wrote:
Hi Brian,
If the
authorization server fails to parse the provided value or does not
consider the resource server acceptable, it MUST reject the
request and provide an error response with the error code
"invalid_resource".
If the resource parameter is not an absolute URI, i.e. parsing of the
value fails, wouldn't the existing general "invalid_request" error code b=
e
more appropriate?
https://tools.ietf.org/html/rfc6749#section-4.1.2.=
1
invalid_request
The request is missing a required parameter, includes an
invalid parameter value, includes a parameter more than
once, or is otherwise malformed.
Vladimir
On 04/08/18 06:39, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
This draft is a work item of the Web Authorization Protocol WG of the IET=
F.
Title : Resource Indicators for OAuth 2.0
Authors : Brian Campbell
John Bradley
Hannes Tschofenig
Filename : draft-ietf-oauth-resource-indicators-00.txt
Pages : 8
Date : 2018-08-03
Abstract:
This straw-man specification defines an extension to The OAuth 2.0
Authorization Framework that enables the client and authorization
server to more explicitly to communicate about the protected
resource(s) to be accessed.
The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-res=
ource-indicators/
There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-resource-ind=
icators-00https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource=
-indicators-00
Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:ftp://ftp.i=
etf.org/internet-drafts/
_______________________________________________
OAuth mailing listOAuth@ietf.o=
rghttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------8EA247C2C8B95FB8239DD007--
--------------ms010905080406030206040409
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CygwggU6MIIEIqADAgECAhEA9DW+rlLUzYs+I90AKROPBDANBgkqhkiG9w0BAQsFADCBlzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDIyMDAw
MDAwWhcNMTkwNDIyMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd2bGFkaW1pckBjb25uZWN0
MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRKqCbZFgc5UOwarPfT
8akjZDXcXbV32yOcBnd5Rw1Befh5shhtGy2IWb2DjNHfxNtTe+pRAxd3pMM0b9jV4Bj8St19
sU55RCc3IcE2ZX25sUssusaNFOt9Z9njLjL0mXG5mdZPNomCjYLcx2PGoBlTmkww/MRyOIUg
ioYdwghyuCySnZ83natEBgwPosPbUBtgo2FPzzVTFwbAt7I/YBBLoJWcJ0c5TZxJJXjlCK5X
HJN5HyTkLE9r1WC6csWg+ImS9Qu1BJrwQmjOADKtVrRnioSWPYXsVeycHHXP00N4qfGps/G4
PoBMebQiJa74m0TF0VoDbcMHXzkbAaFU59ECAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaAFIKv
bIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQ/eBsPoW26G+gUAJoWNRvNGOghWzAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy
MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw
T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp
Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcw
AoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv
Y2EuY29tMCIGA1UdEQQbMBmBF3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tMA0GCSqGSIb3DQEB
CwUAA4IBAQBc2qNY13iSWIXWU+x+FroixRnfU+aald2oOQ0PCnezrlqkT2Ty/83/S7o6a+uF
1tKlYOu/eSu8lW1vpMIpgsUWE9dTMlsuQ1pDtdss6Di+y5lFl/gZNTJN0itXjI/f5G6LRnUQ
6CLhUgB4GqnhpU5dKORQNvEmBmgyiTD4ZOENcPwalWdRziAYsAkmaINMRPSN+jCjSKS29EFx
mremUQ2le6rjruidlSjGxToAj+vbayxXKTo1wifncGDrneuOjQd91HLsrjeUzjwysPXHaELk
/sUWs587QWdaDgiuV6hhMNZkuDs5chFl76wdI/faW8o6aznG4gE7ZZWbt9OdonrTMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ4
MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQD0Nb6uUtTNiz4j3QApE48EMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODA5MDEwODQ3MzBaMC8GCSqGSIb3DQEJ
BDEiBCAsEkvUl0TcCcwdOaeUd828LEaj6UPnWkvFHoRXoAKzFzBsBgkqhkiG9w0BCQ8xXzBd
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx
gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD
T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq
hkiG9w0BAQEFAASCAQBf3NPhKu6OxqG+QNsuUxBFylaKM8WqiLGiCua8SrOJzmG3K9JYR9Jw
JEqBE2Ffh2deipHvqxlq07adovnWbXUtvCtXeQrr+DzQrjAEJK+lskLnszq5bAEg5V3g94+c
RWt0WAWyP9dnGVFWhUB2Mie5r8ceTv0FU9KuyI21xVyAK6dYwZjZ0xaa/vb1KsqUxT3sx073
1mOi9jlTM/FqLXPAJtq5tIQZq7R2ogLHgl0b55hUhD8HTnIz7gLuYliByr67fk7Xc8Pc7CPf
y+kkEEpj4cl1CeDhD1VvPw9GSd5PHkoh05TArlw4DVZeRZdubssaukGLYeIideU/mGYXDmov
AAAAAAAA
--------------ms010905080406030206040409--
From nobody Sat Sep 1 23:24:25 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4EC130E00 for ; Sat, 1 Sep 2018 23:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by-F8HvwcYFq for ; Sat, 1 Sep 2018 23:24:21 -0700 (PDT)
Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D198D12DD85 for ; Sat, 1 Sep 2018 23:24:21 -0700 (PDT)
Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id wLo4f4rccJnLAwLo4fA85Y; Sat, 01 Sep 2018 23:24:21 -0700
To: oauth@ietf.org
References: <153021689405.18540.5214482725778765448@ietfa.amsl.com>
From: Vladimir Dzhuvinov
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <311901af-a5d8-586e-ae2e-f47f92c3afae@connect2id.com>
Date: Sun, 2 Sep 2018 09:24:19 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <153021689405.18540.5214482725778765448@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080201000003040001010007"
X-CMAE-Envelope: MS4wfIYZR/3Sz5k6ybROxdXJBWnAi/hgw1f64l/8WR62nbV64uiy0DyflGN0uiroFUtamQ0CHvCvSEMO8W/NeSuGczm1I0KP+uBu3vbtTUyPFd8Xm8foEs7C 139lQSYHBgmdXxpcXUluH3lOGyOK8mlRGG9olrPDoCQsZlN2jfdGtyx5
Archived-At:
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt: AS response for invalid existing_grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 02 Sep 2018 06:24:24 -0000
This is a cryptographically signed message in MIME format.
--------------ms080201000003040001010007
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Hi William,
How should the AS respond if the refresh token (existing_grant) is found
to be invalid (for any of the listed reasons)? Ignore the client intent
for incremental authZ or return an error code?
Thanks,
Vladimir
On 28/06/18 23:14, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> This draft is a work item of the Web Authorization Protocol WG of the I=
ETF.
>
> Title : OAuth 2.0 Incremental Authorization
> Author : William Denniss
> Filename : draft-ietf-oauth-incremental-authz-00.txt
> Pages : 8
> Date : 2018-06-28
>
> Abstract:
> OAuth 2.0 authorization requests that include every scope the client=
> might ever need can result in over-scoped authorization and a sub-
> optimal end-user consent experience. This specification enhances th=
e
> OAuth 2.0 authorization protocol by adding incremental authorization=
,
> the ability to request specific authorization scopes as needed, when=
> they're needed, removing the requirement to request every possible
> scope that might be needed upfront.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-auth=
z-00
>
>
> Please note that it may take a couple of minutes from the time of submi=
ssion
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--------------ms080201000003040001010007
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CygwggU6MIIEIqADAgECAhEA9DW+rlLUzYs+I90AKROPBDANBgkqhkiG9w0BAQsFADCBlzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDIyMDAw
MDAwWhcNMTkwNDIyMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd2bGFkaW1pckBjb25uZWN0
MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKRKqCbZFgc5UOwarPfT
8akjZDXcXbV32yOcBnd5Rw1Befh5shhtGy2IWb2DjNHfxNtTe+pRAxd3pMM0b9jV4Bj8St19
sU55RCc3IcE2ZX25sUssusaNFOt9Z9njLjL0mXG5mdZPNomCjYLcx2PGoBlTmkww/MRyOIUg
ioYdwghyuCySnZ83natEBgwPosPbUBtgo2FPzzVTFwbAt7I/YBBLoJWcJ0c5TZxJJXjlCK5X
HJN5HyTkLE9r1WC6csWg+ImS9Qu1BJrwQmjOADKtVrRnioSWPYXsVeycHHXP00N4qfGps/G4
PoBMebQiJa74m0TF0VoDbcMHXzkbAaFU59ECAwEAAaOCAe0wggHpMB8GA1UdIwQYMBaAFIKv
bIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQ/eBsPoW26G+gUAJoWNRvNGOghWzAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy
MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw
KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw
T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp
Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcw
AoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv
Y2EuY29tMCIGA1UdEQQbMBmBF3ZsYWRpbWlyQGNvbm5lY3QyaWQuY29tMA0GCSqGSIb3DQEB
CwUAA4IBAQBc2qNY13iSWIXWU+x+FroixRnfU+aald2oOQ0PCnezrlqkT2Ty/83/S7o6a+uF
1tKlYOu/eSu8lW1vpMIpgsUWE9dTMlsuQ1pDtdss6Di+y5lFl/gZNTJN0itXjI/f5G6LRnUQ
6CLhUgB4GqnhpU5dKORQNvEmBmgyiTD4ZOENcPwalWdRziAYsAkmaINMRPSN+jCjSKS29EFx
mremUQ2le6rjruidlSjGxToAj+vbayxXKTo1wifncGDrneuOjQd91HLsrjeUzjwysPXHaELk
/sUWs587QWdaDgiuV6hhMNZkuDs5chFl76wdI/faW8o6aznG4gE7ZZWbt9OdonrTMIIF5jCC
A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n
9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz
KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF
lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t
GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK
+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV
HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI
MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j
cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG
CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N
T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81
zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa
l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp
WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM
UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW
CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X
72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60
ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv
dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN
XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ4
MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNV
BAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQD0Nb6uUtTNiz4j3QApE48EMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG9w0BCQMx
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODA5MDIwNjI0MTlaMC8GCSqGSIb3DQEJ
BDEiBCBDz3ECliv/XhrsDXgcylL/VHkJ1MZhT4HN3WQ9f6UcKTBsBgkqhkiG9w0BCQ8xXzBd
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx
gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD
T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq
hkiG9w0BAQEFAASCAQAL7Zh7GgJ5MaIR/sB8HfTkIX3Jlh4Evn/0AV2VqxOt/PtfYdnkfn4z
etNWPx2UPAHdXlo+/8k6Ed1L5D5JUdvIh1srU3IycqfR2pNM1Z4Q6fecvS2FV9iJ84ZzeMjj
hl7VSrEc2xu5b47BFVccg4Gk5i+w+N3CX7/H8Li3SQXiY8rZVAbjh+SZveTN1gSvpb3zpFpO
CNplnvH2KyptIqFNtrT6YHAG+d53B+W0aQ4fN6w+ic9CBepryqKZzrgNnRiNelqseRfTIeN+
Bt0+PLy63IycMw89ERXP1Ac4oAJNz+O2my9IBHeBoInIgaOOxN8njIgf3N9aHkFhtTUJz5iT
AAAAAAAA
--------------ms080201000003040001010007--
From nobody Mon Sep 3 03:23:43 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA88130E2E for ; Mon, 3 Sep 2018 03:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeIhL85CatNC for ; Mon, 3 Sep 2018 03:23:38 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF24130E25 for ; Mon, 3 Sep 2018 03:23:37 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id p6-v6so48263ljc.5 for ; Mon, 03 Sep 2018 03:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ghRiQq8qJ24us8y/+BWKARGhUcKvmjnSFK4qO4okkNw=; b=KXBKkYYf/G4rvMLNDAW6XT3sDFkZYx0gqW07tTtWktHiWZbmbOpO9ENY2gXfNKe/aF JVMgbjzXKb3mQF7+25U2SlioQCO+PGrM3pHvA8OkE5lDlI53Yow7nkkBcrM3/wt87rXB EZdei2UIz7ZPnMcG8RXkN78fADWsI1CWXdrA4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ghRiQq8qJ24us8y/+BWKARGhUcKvmjnSFK4qO4okkNw=; b=jmo+FvPaEWxB+94khmpnDq374tM3/Abm+GiB7bytUX9gzJdHR4xlgJdAd0meoHzXWL ropsVcJSvXg9qHg0kwASaNq+Pt2l19X9yn/Xig84q7uQxTmBFbDuCk7uFN/QOzlRXXzY aglHSE4ThVJhAXpjphr0wWDzvhqbX6vGkyhl0gIlAXzCqoG/Zjfb97PHGQVDilK8qB+j byTRYCkAH3bTUGmre8/2cj5Pn2frng7gwCzxwO9LhFaE7dUxAdAmWFL77oz571tXOaPQ tMWd/l589tKIBNjob+KZXTq5oH57llg6iUMyhpygiGc4FSksMyxas2O5D3beVjSLTpnT vUhA==
X-Gm-Message-State: APzg51Dn+3nEg91kvYEdhBpZj5wZYxkFhh29QYmuyvF9o4YhEFRQzFin u05jn7+Tz/KiZLj7aivgTkIT4KTWumTfq9GKY0clzJFgsRHCNQ==
X-Google-Smtp-Source: ANB0Vdb/tq9P51g5jE+DCALGax638G+8MpwUp4eW3VBER2O3q8Ua62/5I8KSYowfrYr1VQ670n0d20t7fMwqis5T04E=
X-Received: by 2002:a2e:5419:: with SMTP id i25-v6mr16494684ljb.51.1535970215690; Mon, 03 Sep 2018 03:23:35 -0700 (PDT)
MIME-Version: 1.0
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com>
In-Reply-To:
From: Dave Tonge
Date: Mon, 3 Sep 2018 12:23:24 +0200
Message-ID:
To: "Phil Hunt (IDM)"
Cc: George Fletcher , kaduk@mit.edu, oauth
Content-Type: multipart/alternative; boundary="000000000000179a860574f4efb5"
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 03 Sep 2018 10:23:42 -0000
--000000000000179a860574f4efb5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Phil
Thanks again for the helpful reply.
I 100% agree with you about the problem of false negatives with RFC3230.
I am not in favour of the its use and will do my best to highlight these
issues with those who are proposing its use with the draft cavage spec.
I also share your worry about the potential for things to move back to a
SOAP style of API.
Having a look at the
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 spec it
is quite general purpose, whereas I'm in favour of something that is
explicitly designed for JSON requests and responses. If there was
confidence in the JSON canonicalisation described in
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then this
seems to enable APIs to stay REStful but with the support for
self-contained signatures. For many applications I agree that there will
need to be some repetition of values in the JSON payload that are already
in the header, e.g. audience, issuer and time. But if general purpose HTTP
signing is a lost cause, then "Cleartext JSON Web Signatures" seem the next
best thing.
Dave
On Sat, 1 Sep 2018 at 01:06, Phil Hunt wrote:
> Dave,
>
> I=E2=80=99m not sure this is as useful as one might think - from RFC3230=
=E2=80=A6
>
> 7 Security Considerations
>
> This document specifies a data integrity mechanism that protects HTTP
> instance data, but not HTTP entity headers, from certain kinds of
> accidental corruption. It is also useful in detecting at least one
> spoofing attack [9 ]. Howe=
ver, it is not intended as general
> protection against malicious tampering with HTTP messages.
>
> The HTTP Digest Access Authentication mechanism [5 ] provides some
> protection against malicious tampering.
>
>
> For example, if you have a corporate web proxy or ISP that decides to hel=
p
> out by doing content compression as an example, all your requests will
> start failing (so-called accidental corruption). We learned from XML tha=
t
> consistent canonicalization of the request data is important.
>
> IOW=E2=80=A6RFC3230 is valid when it works, but what about all the times =
it fails
> for no apparent reason? (false negatives)
>
> In my humble experience with REST, the HTTP body is only a small part of
> the transaction. The headers, method, and URL parameters contain all of t=
he
> semantics to an application transaction. Sure there are some requests tha=
t
> are just built on HTTP POST. But you have to be sure, there are no
> parameters that matter in the headers or URL.
>
> The OAuth WG took a big ambitious stab at this (thanks Justin), but we
> weren=E2=80=99t convinced implementations would be stable.
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
>
> I can=E2=80=99t help but worry we are headed back to RPC style SOAP like
> containers based on JSON tokens that can be signed and that contain all t=
he
> semantics and data of a transaction to be signed. Now that I said that,
> I=E2=80=99m going to go wash my mouth out. Ugh.
>
> Phil
>
>
>
> On Aug 31, 2018, at 3:05 PM, Dave Tonge
> wrote:
>
> Thanks for the replies.
> You're absolutely right Phil and George - apologies I omitted the digest
> step from the first email.
> Both the STET and Berlin Group specs require the use of SHA-256 or SHA-51=
2
> digest header as per RFC3230 (https://tools.ietf.org/html/rfc3230
>
> )
> They then use the draft cavage spec to sign a defined set of headers whic=
h
> includes the date and digest headers.
>
> > If you want attestation, better to use SET or plain JWT.
>
> The pushback on this has been that to use JWTs for all API request bodies
> and responses would make the APIs harder to develop against and debug.
> However I do think it is a better option than having signatures in
> headers. I like the idea of using content negotiation to allow clients to
> request either application/json or application/jwt from an API endpoint.
>
> I'd be interested if there is any interest in the working group for this
> draft though:
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
> .
> As Ben mentioned, does the issue of JSON canonicalization make this a
> non-starter?
>
> Thanks
>
> Dave
>
>
>
--=20
Dave Tonge
CTO
[image: Moneyhub Enterprise]
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120
Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 =C2=A9
DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.
--000000000000179a860574f4efb5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Phil
Thanks again for the helpful reply.
I 100% agree=
with you about the problem of false negatives with=C2=A0RFC3230.I a=
m not in favour of the its use and will do my best to highlight these issue=
s with those who are proposing its use with the draft cavage spec.=
div>
I also share your worry about the potential for things to move bac=
k to a SOAP style of API.=C2=A0
Having a look at the =
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 spe=
c it is quite general purpose, whereas I'm in favour of something that =
is explicitly designed for JSON requests and responses. If there was confid=
ence=C2=A0in the JSON=C2=A0canonicalisation described in=C2=A0https://tool=
s.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then this seems to =
enable APIs to stay REStful but with the support for self-contained signatu=
res. For many applications I agree that there will need to be some repetiti=
on of values in the JSON payload that are already in the header, e.g. audie=
nce, issuer and time. But if general purpose HTTP signing is a lost cause, =
then "Cleartext JSON Web Signatures"=C2=A0seem the next best thing.=
=C2=A0
Dav=
e
=C2=
=A0
<=
/div>
Dave,
I=E2=80=99m not sure this is as useful as one might think - from RF=
C3230=E2=80=A6
7 Security Considerations
This document specifies a data integrity mechanism that protects HTTP
instance data, but not HTTP entity headers, from certain kinds of
accidental corruption. It is also useful in detecting at least one
spoofing attack [9]. Howe=
ver, it is not intended as general
protection against malicious tampering with HTTP messages.
The HTTP Digest Access Authentication mechanism [5] provides som=
e
protection against malicious tampering.
For example, if you have a corporate web proxy or ISP that decides to=
help out by doing content compression as an example, all your requests wil=
l start failing (so-called accidental corruption).=C2=A0 We learned from XM=
L that consistent canonicalization of the request data is important.
<=
div>
IOW=E2=80=A6RFC3230 is valid when it works, but what abo=
ut all the times it fails for no apparent reason? (false negatives)
In my humble experience with REST, the HTTP body is =
only a small part of the transaction. The headers, method, and URL paramete=
rs contain all of the semantics to an application transaction. Sure there a=
re some requests that are just built on HTTP POST.=C2=A0 But you have to be=
sure, there are no parameters that matter in the headers or URL.=C2=A0
I can=E2=80=99t =
help but worry we are headed back to RPC style SOAP like containers based o=
n JSON tokens that can be signed and that contain all the semantics and dat=
a of a transaction to be signed.=C2=A0 Now that I said that, I=E2=80=99m go=
ing to go wash my mouth out. Ugh.
Thanks for the replies.
You're absolutely right Phil and George - apologies I omitted=
the digest step from the first email.They then use the draft cavage spec =
to sign a defined set of headers which includes the date and digest headers=
.
> If you want attestation, bette=
r to use SET or plain JWT.
The pushback on this has been that to use JWTs for all API request =
bodies and responses would make the APIs harder to develop against and debu=
g.
However I do think it is a better option than havin=
g signatures in headers. I like the idea of using content negotiation to al=
low clients to request either application/json or application/jwt from an A=
PI endpoint.
I'd be interested =
if there is any interest in the working group for this draft though:=C2=A0<=
a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf=
.org_html_draft-2Derdtman-2Djose-2Dcleartext-2Djws-2D00&d=3DDwMFaQ&=
c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dp=
ctyXPpuYqPkAI1aLcLN4KZNA&m=3D_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97C=
U&s=3D0G1ikcDnNzvZqp7w6xlLnfhtq6GZGc0HlswqLcp4OK4&e=3D" target=3D"_=
blank">https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00.=
As Ben mentioned, does the issue of JSON canonicalization make this a non-=
starter?
Thanks
Dave
--
<=
div style=3D"font-size:14px;font-weight:normal;color:rgb(51,51,51);font-fam=
ily:lato,"open sans",arial,sans-serif;line-height:normal">
Dave Tonge
CTO=
div>
Moneyhub Financial Technology, 5th Floor,=
10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 5120
=
<=
div style=3D"line-height:1.4">
Moneyhub En=
terprise is a trading style of Moneyhub Financial Technology Limited which =
is authorised and regulated by the Financial Conduct Authority ("FCA&q=
uot;).=C2=A0Moneyhub Financial Technology is entered on the Financial Servi=
ces Register=C2=A0(FRN=C2=A0809360) at fca.or=
g.uk/register. Moneyhub=C2=A0Financial Technology is registered in England & =
Wales, company registration number=C2=A0=C2=A006909772=C2=A0.Moneyhub=C2=A0Financial Technology Lim=
ited 2018=C2=A0=C2=A9
DISCLAIMER: This email (including any attachments) is subject to copy=
right, and the information in it is confidential. Use of this email or of a=
ny information in it other than by the addressee is unauthorised and unlawf=
ul. Whilst reasonable efforts are made to ensure that any attachments are v=
irus-free, it is the recipient's sole responsibility to scan all attach=
ments for viruses. All calls and emails to and from this company may be mon=
itored and recorded for legitimate purposes relating to this company's =
business. Any opinions expressed in this email (or in any attachments) are =
those of the author and do not necessarily represent the opinions of Moneyh=
ub Financial Technology Limited or of any other group company.
=
--000000000000179a860574f4efb5--
From nobody Mon Sep 3 05:27:15 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE52130E12 for ; Mon, 3 Sep 2018 05:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.825
X-Spam-Level:
X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQVwJ5jcV3-7 for ; Mon, 3 Sep 2018 05:27:12 -0700 (PDT)
Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EC4126CC7 for ; Mon, 3 Sep 2018 05:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1535977631; bh=2WGFie2jIze8/DZF5k1UrJK6lXEOXKQ9qCf8cw7LFZI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=V4w8eSah4i3DOPwDYD+jFH99k/cpUXNxDF0vjP47NBCiZqe6NK3bsXcfsJ+fp1TyFNLoZZWLUMpFjFdca+hTiIEvjUQmrbbaUxowshv+4IFiPNAt65Z5oDuL55P016TYUadtbWTOrzfBZl0P5u93ZUBfehorg4WUYYQnaGrVNnXlnANrGzKdT9CVB7bwBFN80b8p+z7VzWrigXwQs6Cxq/HNnmI/UENjciNQM8UAcS35fbK/3iWQ3yeRkw5mmd6cH0DEFUiBL0DkVPxf/b9JPNweHzmGn2DVX91R6BE1B/ceifUzfjy/Q1hwpzAz2xz1bmNDLZqWf7FAq4ww7baMWw==
X-YMail-OSG: OocWqXgVM1kgkqP3iSjQ5soMXtGsztWfCG3weWN_rkg2Ak_cbTqjEiELz138nwv 2qbYhO.OJ3dVFGhF_4l2gWjVtEPmjWBjqDlxG1__YCD2bEoJzJ.qOzxnfCPQSK7b613o8wsShYxZ y7bhi4NaS4mDGY4c24M0mzgZW7e1ldWLsNKRy0a1Iw9ebQ6tlA4ciqhe8BeFqixjS0p.TWxuyJNv w2eSHexEW6xBdiXPebpJqD.WEjsa7NllNqeAHeU5k2etOrbCBbedmkvg5cmIuaN6dv.5Lq8pcfgB sAESMdf6LhyjHSxiwbqmZSF.OeqhyZdJ4NaP5TW2.WoYv2fWPYpzBn4atvmbEWIxjwlPA8RQTyH8 .lwUgBp8rf6FJXm3_mRtBjWzudrk5m9h2phzEm7GOsacYuV8CMZseXZJxpYaRev91oV53ExgI8oV HoC8t__gWnnW6sItIbtfajxmB6BgwowNom._uCZLkrXpiMLhIW4ZWLmx9BvBSfal6wkjZzEaAzYv i.qxgIyKHQzn0Io38l1Fxspz6OAbq0Z_94bPpxICKJDPB2AlQkOQ35r0ILOsprRtlH7Ty9C_RWgi ucKRtnaaSxWDK3yAz93TVJ1mdjYpv6RpTRMtA3l5_SUIN7fgUUzZa8luJ6fJUtGdwXWNuIBD1NHK Co7.PdjaDMFcEj7BBUfxlXTvOO1_COrMz28K0HwHkYMeUpCLu.9poDSQTf_t2ljlBDiQAjjxHy8Q H9U7zXLEyxWx_jwXmoRoJQs3bpiMy7nRvUmJZMRz_u6FAxFtbUI9dnL4x_QpI0g1T2KwWCw22bXE Q2.ohr0wvUUuV6ymPJdh6UYHa9uhOchRsdivXLmVFcq8NUb7nbGD9b3jOgnr9msToSgoclB7ydHL X4mOvwSmY0tg48en3dzg8_NrL2faIo3SVCvJHwCwaoZWSw6a_GErF25BlHF_bZzxYN61X4.qkB8. lCxmnWjmvAONgURSD_d41qZ1geaz4Kb1pzDv4YIr3mNt0sKL1QfSdEj6ofor0838j781Ab.wYhnA 4QyaOIBFVEvJKsFSST2O.5g--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Mon, 3 Sep 2018 12:27:11 +0000
Received: from 208.72.78.175 (EHLO [192.168.50.169]) ([208.72.78.175]) by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9384b0e865d3ebd0c2cb3ece38c40762; Mon, 03 Sep 2018 12:27:08 +0000 (UTC)
To: Dave Tonge , "Phil Hunt (IDM)"
Cc: kaduk@mit.edu, oauth
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com>
From: George Fletcher
Organization: AOL LLC
Message-ID: <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
Date: Mon, 3 Sep 2018 08:27:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------3F71FA8CF4B130F74BC302B8"
Content-Language: en-US
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 03 Sep 2018 12:27:14 -0000
This is a multi-part message in MIME format.
--------------3F71FA8CF4B130F74BC302B8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
I'm not a big fan of canonicalization for signatures. In the past it has
been brittle, the libraries subject to bugs, and hard for developers to
adopt. That said, if no canonicalization is not a requirement, have you
checked out JSON-LD? It has embedded signature support.
https://json-ld.org/spec/latest/
On 9/3/18 6:23 AM, Dave Tonge wrote:
> Hi Phil
>
> Thanks again for the helpful reply.
> I 100% agree with you about the problem of false negatives with RFC3230.
> I am not in favour of the its use and will do my best to highlight
> these issues with those who are proposing its use with the draft
> cavage spec.
>
> I also share your worry about the potential for things to move back to
> a SOAP style of API.
>
> Having a look at the
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
> spec it is quite general purpose, whereas I'm in favour of something
> that is explicitly designed for JSON requests and responses. If there
> was confidence in the JSON canonicalisation described in
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then
> this seems to enable APIs to stay REStful but with the support for
> self-contained signatures. For many applications I agree that there
> will need to be some repetition of values in the JSON payload that are
> already in the header, e.g. audience, issuer and time. But if general
> purpose HTTP signing is a lost cause, then "Cleartext JSON Web
> Signatures" seem the next best thing.
>
> Dave
>
>
>
>
>
>
> On Sat, 1 Sep 2018 at 01:06, Phil Hunt > wrote:
>
> Dave,
>
> I’m not sure this is as useful as one might think - from RFC3230…
>>
>>
>> 7 Security
>> Considerations
>>
>>
>>
>> This document specifies a data integrity mechanism that protects HTTP
>> instance data, but not HTTP entity headers, from certain kinds of
>> accidental corruption. It is also useful in detecting at least one
>> spoofing attack [9 ]. However, it is not intended as general
>> protection against malicious tampering with HTTP messages.
>>
>> The HTTP Digest Access Authentication mechanism [5 ] provides some
>> protection against malicious tampering.
>
> For example, if you have a corporate web proxy or ISP that decides
> to help out by doing content compression as an example, all your
> requests will start failing (so-called accidental corruption). We
> learned from XML that consistent canonicalization of the request
> data is important.
>
> IOW…RFC3230 is valid when it works, but what about all the times
> it fails for no apparent reason? (false negatives)
>
> In my humble experience with REST, the HTTP body is only a small
> part of the transaction. The headers, method, and URL parameters
> contain all of the semantics to an application transaction. Sure
> there are some requests that are just built on HTTP POST. But you
> have to be sure, there are no parameters that matter in the
> headers or URL.
>
> The OAuth WG took a big ambitious stab at this (thanks Justin),
> but we weren’t convinced implementations would be stable..
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
>
> I can’t help but worry we are headed back to RPC style SOAP like
> containers based on JSON tokens that can be signed and that
> contain all the semantics and data of a transaction to be signed.
> Now that I said that, I’m going to go wash my mouth out. Ugh.
>
> Phil
>
>
>
>> On Aug 31, 2018, at 3:05 PM, Dave Tonge
>> > > wrote:
>>
>> Thanks for the replies.
>> You're absolutely right Phil and George - apologies I omitted the
>> digest step from the first email.
>> Both the STET and Berlin Group specs require the use of SHA-256
>> or SHA-512 digest header as per RFC3230
>> (https://tools.ietf.org/html/rfc3230
>> )
>> They then use the draft cavage spec to sign a defined set of
>> headers which includes the date and digest headers..
>>
>> > If you want attestation, better to use SET or plain JWT.
>>
>> The pushback on this has been that to use JWTs for all API
>> request bodies and responses would make the APIs harder to
>> develop against and debug.
>> However I do think it is a better option than having signatures
>> in headers. I like the idea of using content negotiation to allow
>> clients to request either application/json or application/jwt
>> from an API endpoint.
>>
>> I'd be interested if there is any interest in the working group
>> for this draft though:
>> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
>> .
>> As Ben mentioned, does the issue of JSON canonicalization make
>> this a non-starter?
>>
>> Thanks
>>
>> Dave
>
>
>
> --
> Dave Tonge
> CTO
> Moneyhub Enterprise
>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> t: +44 (0)117 280 5120
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial
> Technology Limited which is authorised and regulated by the Financial
> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on
> the Financial Services Register (FRN 809360) at fca.org.uk/register
> . Moneyhub Financial Technology is
> registered in England & Wales, company registration number 06909772 .
> Moneyhub Financial Technology Limited 2018 ©
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this
> email or of any information in it other than by the addressee is
> unauthorised and unlawful. Whilst reasonable efforts are made to
> ensure that any attachments are virus-free, it is the recipient's sole
> responsibility to scan all attachments for viruses. All calls and
> emails to and from this company may be monitored and recorded for
> legitimate purposes relating to this company's business. Any opinions
> expressed in this email (or in any attachments) are those of the
> author and do not necessarily represent the opinions of Moneyhub
> Financial Technology Limited or of any other group company.
--------------3F71FA8CF4B130F74BC302B8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
I'm not a big fan of
canonicalization for signatures. In the past it has been brittle,
the libraries subject to bugs, and hard for developers to adopt. That
said, if no canonicalization is not a requirement, have you
checked out JSON-LD? It has embedded signature support.
https://json-ld.org/spec/latest/
On 9/3/18 6:23 AM, Dave Tonge wrote:
Hi Phil
Thanks again for the helpful
reply.
I 100% agree with you about the
problem of false negatives with RFC3230.
I am not in favour of the its use
and will do my best to highlight these issues
with those who are proposing its use with the
draft cavage spec.
I also share your worry about the
potential for things to move back to a SOAP
style of API.
Having a look at the https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
spec it is quite general purpose, whereas I'm in
favour of something that is explicitly designed
for JSON requests and responses. If there was
confidence in the JSON canonicalisation
described in https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
then this seems to enable APIs to stay REStful
but with the support for self-contained
signatures. For many applications I agree that
there will need to be some repetition of values
in the JSON payload that are already in the
header, e.g. audience, issuer and time. But if
general purpose HTTP signing is a lost cause,
then "Cleartext JSON Web Signatures" seem the next best thing.
Dave
Dave,
I’m not sure this is as useful as one might think - from
RFC3230…
7 Security Considerations
This document specifies a data integrity mechanism that protects HTTP
instance data, but not HTTP entity headers, from certain kinds of
accidental corruption. It is also useful in detecting at least one
spoofing attack [9]. However, it is not intended as general
protection against malicious tampering with HTTP messages.
The HTTP Digest Access Authentication mechanism [5] provides some
protection against malicious tampering.
For example, if you have a corporate web proxy or ISP
that decides to help out by doing content compression as
an example, all your requests will start failing
(so-called accidental corruption). We learned from XML
that consistent canonicalization of the request data is
important.
IOW…RFC3230 is valid when it works, but what about
all the times it fails for no apparent reason? (false
negatives)
In my humble experience with REST, the HTTP body is
only a small part of the transaction. The headers,
method, and URL parameters contain all of the
semantics to an application transaction. Sure there
are some requests that are just built on HTTP POST.
But you have to be sure, there are no parameters that
matter in the headers or URL.
I can’t help but worry we are headed back to RPC
style SOAP like containers based on JSON tokens that
can be signed and that contain all the semantics and
data of a transaction to be signed. Now that I said
that, I’m going to go wash my mouth out. Ugh.
Thanks for the
replies.
You're absolutely
right Phil and George - apologies I
omitted the digest step from the first
email.
They then use the
draft cavage spec to sign a defined set
of headers which includes the date and
digest headers..
>
If you want attestation, better to use
SET or plain JWT.
The pushback on
this has been that to use JWTs for all
API request bodies and responses would
make the APIs harder to develop against
and debug.
However I do think
it is a better option than having
signatures in headers. I like the idea
of using content negotiation to allow
clients to request either
application/json or application/jwt from
an API endpoint.
Thanks
Dave
--
Dave
Tonge
CTO
Moneyhub Financial
Technology, 5th Floor, 10
Temple Back, Bristol, BS1
6FL
t: +44 (0)117 280 5120
Moneyhub
Enterprise is a trading
style of Moneyhub Financial
Technology Limited which is
authorised and regulated by
the Financial Conduct
Authority ("FCA"). Moneyhub
Financial Technology is
entered on the Financial
Services Register (FRN 809360)
at fca.org.uk/register.
Moneyhub Financial
Technology is registered in
England & Wales, company
registration number 06909772 .
Moneyhub Financial
Technology Limited 2018 ©
DISCLAIMER:
This email (including any
attachments) is subject to
copyright, and the
information in it is
confidential. Use of this
email or of any information
in it other than by the
addressee is unauthorised
and unlawful. Whilst
reasonable efforts are made
to ensure that any
attachments are virus-free,
it is the recipient's sole
responsibility to scan all
attachments for viruses. All
calls and emails to and from
this company may be
monitored and recorded for
legitimate purposes relating
to this company's business.
Any opinions expressed in
this email (or in any
attachments) are those of
the author and do not
necessarily represent the
opinions of Moneyhub
Financial Technology Limited
or of any other group
company.
--------------3F71FA8CF4B130F74BC302B8--
From nobody Mon Sep 3 05:38:17 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DFC130E87 for ; Mon, 3 Sep 2018 05:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLiuzwB9LEc4 for ; Mon, 3 Sep 2018 05:38:07 -0700 (PDT)
Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32620130E71 for ; Mon, 3 Sep 2018 05:38:07 -0700 (PDT)
Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id wo7Jfa2BPmDrSwo7Jf0skl; Mon, 03 Sep 2018 05:38:06 -0700
To: oauth@ietf.org
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com>
From: Vladimir Dzhuvinov
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID: <8415af5a-3b79-c90a-f81d-b25f32bc22a7@connect2id.com>
Date: Mon, 3 Sep 2018 15:38:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------3BAA02F5FFB8E788BBA3C896"
Content-Language: en-US
X-CMAE-Envelope: MS4wfAUgsXkmu5fSyv4CiYEyHkCCeWg0JhftV0iRvOBrIU9C1saJPgMyLAAf+BNnP2XogNDRdfEVM+86O327qxFILPth5oa7ulzbVLOpH41SThqvbaI5V1eT xqUCl2nqC1LPYx1LaaaThYapxWDKPH/rpaIHypzuEYJrvL41TfeEXEtU
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 03 Sep 2018 12:38:16 -0000
This is a multi-part message in MIME format.
--------------3BAA02F5FFB8E788BBA3C896
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Dave,
On 03/09/18 13:23, Dave Tonge wrote:
> Hi Phil
>
> Thanks again for the helpful reply.
> I 100% agree with you about the problem of false negatives with RFC3230=
=2E
> I am not in favour of the its use and will do my best to highlight thes=
e
> issues with those who are proposing its use with the draft cavage spec.=
>
> I also share your worry about the potential for things to move back to =
a
> SOAP style of API.
>
> Having a look at the
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 spe=
c it
> is quite general purpose, whereas I'm in favour of something that is
> explicitly designed for JSON requests and responses. If there was
> confidence in the JSON canonicalisation described in
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then th=
is
> seems to enable APIs to stay REStful but with the support for
> self-contained signatures. For many applications I agree that there wil=
l
> need to be some repetition of values in the JSON payload that are alrea=
dy
> in the header, e.g. audience, issuer and time. But if general purpose H=
TTP
> signing is a lost cause, then "Cleartext JSON Web Signatures" seem the =
next
> best thing.
That's probably the wisest approach here.
For reliable signing the data and its structure must remain immutable
from end to end, including how the messages are seen / processed by
programming / library interfaces. That's not the case with HTTP, which
allows bits of the message and its structure to get modified along the
way. If general purpose HTTP signatures were easy to achieve, and
there's obviously all sorts of demand for that, we would have had a
working standard a long time ago.
I wonder what it would take to resurrect
draft-erdtman-jose-cleartext-jws. I see it's formally going to expire in
2 days.
Are we aware of any working implementations?
Vladimir
> Dave
>
>
>
>
>
>
>
> On Sat, 1 Sep 2018 at 01:06, Phil Hunt wrote:
>
>> Dave,
>>
>> I=E2=80=99m not sure this is as useful as one might think - from RFC32=
30=E2=80=A6
>>
>> 7 Security Considerati=
ons
>>
>> This document specifies a data integrity mechanism that protects HT=
TP
>> instance data, but not HTTP entity headers, from certain kinds of
>> accidental corruption. It is also useful in detecting at least one=
>> spoofing attack [9 ]. H=
owever, it is not intended as general
>> protection against malicious tampering with HTTP messages.
>>
>> The HTTP Digest Access Authentication mechanism [5 ] provides some
>> protection against malicious tampering.
>>
>>
>> For example, if you have a corporate web proxy or ISP that decides to =
help
>> out by doing content compression as an example, all your requests will=
>> start failing (so-called accidental corruption). We learned from XML =
that
>> consistent canonicalization of the request data is important.
>>
>> IOW=E2=80=A6RFC3230 is valid when it works, but what about all the tim=
es it fails
>> for no apparent reason? (false negatives)
>>
>> In my humble experience with REST, the HTTP body is only a small part =
of
>> the transaction. The headers, method, and URL parameters contain all o=
f the
>> semantics to an application transaction. Sure there are some requests =
that
>> are just built on HTTP POST. But you have to be sure, there are no
>> parameters that matter in the headers or URL.
>>
>> The OAuth WG took a big ambitious stab at this (thanks Justin), but we=
>> weren=E2=80=99t convinced implementations would be stable.
>> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
>>
>> I can=E2=80=99t help but worry we are headed back to RPC style SOAP li=
ke
>> containers based on JSON tokens that can be signed and that contain al=
l the
>> semantics and data of a transaction to be signed. Now that I said tha=
t,
>> I=E2=80=99m going to go wash my mouth out. Ugh.
>>
>> Phil
>>
>>
>>
>> On Aug 31, 2018, at 3:05 PM, Dave Tonge
>> wrote:
>>
>> Thanks for the replies.
>> You're absolutely right Phil and George - apologies I omitted the dige=
st
>> step from the first email.
>> Both the STET and Berlin Group specs require the use of SHA-256 or SHA=
-512
>> digest header as per RFC3230 (https://tools.ietf.org/html/rfc3230
>>
>> )
>> They then use the draft cavage spec to sign a defined set of headers w=
hich
>> includes the date and digest headers.
>>
>>> If you want attestation, better to use SET or plain JWT.
>> The pushback on this has been that to use JWTs for all API request bod=
ies
>> and responses would make the APIs harder to develop against and debug.=
>> However I do think it is a better option than having signatures in
>> headers. I like the idea of using content negotiation to allow clients=
to
>> request either application/json or application/jwt from an API endpoin=
t.
>>
>> I'd be interested if there is any interest in the working group for th=
is
>> draft though:
>> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
>> .
>> As Ben mentioned, does the issue of JSON canonicalization make this a
>> non-starter?
>>
>> Thanks
>>
>> Dave
>>
>>
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------3BAA02F5FFB8E788BBA3C896
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Hi Dave,
On 03/09/18 13:23, Dave Tonge wrote:
Hi Phil
Thanks again for the helpful reply.
I 100% agree with you about the problem of false negatives with RFC3230.
I am not in favour of the its use and will do my best to highlight these
issues with those who are proposing its use with the draft cavage spec.
I also share your worry about the potential for things to move back to a
SOAP style of API.
Having a look at the
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 spec it
is quite general purpose, whereas I'm in favour of something that is
explicitly designed for JSON requests and responses. If there was
confidence in the JSON canonicalisation described in
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then this
seems to enable APIs to stay REStful but with the support for
self-contained signatures. For many applications I agree that there will
need to be some repetition of values in the JSON payload that are already
in the header, e.g. audience, issuer and time. But if general purpose HTTP
signing is a lost cause, then "Cleartext JSON Web Signatures" seem the next
best thing.
That's probably the wisest approach here.
For reliable signing the data and its structure must remain
immutable from end to end, including how the messages are seen /
processed by programming / library interfaces. That's not the case
with HTTP, which allows bits of the message and its structure to get
modified along the way. If general purpose HTTP signatures were easy
to achieve, and there's obviously all sorts of demand for that, we
would have had a working standard a long time ago.
I wonder what it would take to resurrect
draft-erdtman-jose-cleartext-jws. I see it's formally going to
expire in 2 days.
Are we aware of any working implementations?
Vladimir
Dave
On Sat, 1 Sep 2018 at 01:06, Phil Hunt <phil.hunt@oracle.com> wrote:
Dave,
I’m not sure this is as useful as one might think - from RFC3230…
7 <https://tools.ietf.org/html/rfc3230#section-7> Security Considerations
This document specifies a data integrity mechanism that protects HTTP
instance data, but not HTTP entity headers, from certain kinds of
accidental corruption. It is also useful in detecting at least one
spoofing attack [9 <https://tools.ietf.org/html/rfc3230#ref-9>]. However, it is not intended as general
protection against malicious tampering with HTTP messages.
The HTTP Digest Access Authentication mechanism [5 <https://tools.ietf..org/html/rfc3230#ref-5>] provides some
protection against malicious tampering.
For example, if you have a corporate web proxy or ISP that decides to help
out by doing content compression as an example, all your requests will
start failing (so-called accidental corruption). We learned from XML that
consistent canonicalization of the request data is important.
IOW…RFC3230 is valid when it works, but what about all the times it fails
for no apparent reason? (false negatives)
In my humble experience with REST, the HTTP body is only a small part of
the transaction. The headers, method, and URL parameters contain all of the
semantics to an application transaction. Sure there are some requests that
are just built on HTTP POST. But you have to be sure, there are no
parameters that matter in the headers or URL.
The OAuth WG took a big ambitious stab at this (thanks Justin), but we
weren’t convinced implementations would be stable.
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
I can’t help but worry we are headed back to RPC style SOAP like
containers based on JSON tokens that can be signed and that contain all the
semantics and data of a transaction to be signed. Now that I said that,
I’m going to go wash my mouth out. Ugh.
Phil
On Aug 31, 2018, at 3:05 PM, Dave Tonge <dave.tonge@momentumft.co.uk>
wrote:
Thanks for the replies.
You're absolutely right Phil and George - apologies I omitted the digest
step from the first email.
Both the STET and Berlin Group specs require the use of SHA-256 or SHA-512
digest header as per RFC3230 (https://tools.ietf.org/html/rfc3230
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3230&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=>
)
They then use the draft cavage spec to sign a defined set of headers which
includes the date and digest headers.
If you want attestation, better to use SET or plain JWT.
The pushback on this has been that to use JWTs for all API request bodies
and responses would make the APIs harder to develop against and debug.
However I do think it is a better option than having signatures in
headers. I like the idea of using content negotiation to allow clients to
request either application/json or application/jwt from an API endpoint.
I'd be interested if there is any interest in the working group for this
draft though:
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Derdtman-2Djose-2Dcleartext-2Djws-2D00&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=0G1ikcDnNzvZqp7w6xlLnfhtq6GZGc0HlswqLcp4OK4&e=>.
As Ben mentioned, does the issue of JSON canonicalization make this a
non-starter?
Thanks
Dave
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------3BAA02F5FFB8E788BBA3C896--
From nobody Mon Sep 3 05:56:25 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06C8130E4A for ; Mon, 3 Sep 2018 05:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFNkI8FYLjgc for ; Mon, 3 Sep 2018 05:56:22 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F236C130E48 for ; Mon, 3 Sep 2018 05:56:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.53,325,1531749600"; d="scan'208,217";a="142545330"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 03 Sep 2018 22:56:19 +1000
Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcavi.tcif.telstra.com.au with ESMTP; 03 Sep 2018 22:56:19 +1000
Received: from wsapp6782.srv.dir.telstra.com (10.75.131.37) by wsmsg3702.srv.dir.telstra.com (172.49.40.170) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 3 Sep 2018 22:56:19 +1000
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp6782.srv.dir.telstra.com (10.75.131.37) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 3 Sep 2018 22:56:18 +1000
Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.126) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 3 Sep 2018 22:56:18 +1000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VYFd0mUgmI04Hhxp/5dFMZpXx9XKy0T4u4/x3wp+X2E=; b=Ht/NY3QpGNZL460aNFhuM61LBLScaymVKLNZTWv+dZZdcEfJKNFI2Pj0zdDZjM3MP6vTpNFp0zF7rBnms1TZoaDocCFXxjjxzMvGKEFsePxFgy5Xex9FYiZX9Fsf8TJcHwkdk03w6XI+6v1JK96YIsK3MsVcXaQqKc13KAxsrls=
Received: from MEAPR01MB3542.ausprd01.prod.outlook.com (52.134.216.9) by MEAPR01MB3239.ausprd01.prod.outlook.com (52.134.214.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.14; Mon, 3 Sep 2018 12:56:18 +0000
Received: from MEAPR01MB3542.ausprd01.prod.outlook.com ([fe80::f19a:6df1:9f8d:e8f1]) by MEAPR01MB3542.ausprd01.prod.outlook.com ([fe80::f19a:6df1:9f8d:e8f1%3]) with mapi id 15.20.1080.015; Mon, 3 Sep 2018 12:56:17 +0000
From: "Manger, James"
To: oauth
Thread-Topic: [OAUTH-WG] Non-repudiation for API requests and responses
Thread-Index: AQHUQ3BNd7zSmOnMEEaGc6gpczvSw6Tee/qAgAAAgZA=
Date: Mon, 3 Sep 2018 12:56:17 +0000
Message-ID:
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com> <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
In-Reply-To: <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 10.0.500.19
dlp-reaction: no-action
x-originating-ip: [124.188.24.154]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MEAPR01MB3239; 6:lWxrVPHBvpFTaqLZoFIFYMHApYVUfKXYQj5Nz0V6754v5cXKCzuVP4Ny0m2zAtMELk7dRmV0zqRXhfbFzaYgzjbW2lQr8Dg4unWpHj3Cn+wHxx5Ma0A3d8VHQYX+Pi4titLgTRFcihDRs3mQMFwvIVwAk6hYutbJ3EPjZN/ci6zNqWa2BQLxRg3YN1Jk81VkR6rgpb+8wjtVl5a4Qpflm5b5zD7OvtV6M/GoAXe5N0WDr3t8W2tUdjKZzGuph1dzy8ymzWW9DQ43bJiVtqGCaaVp/TbFpUr7wKkzrJVNxez3TDKX/UEb9T8SyDrFQqv87ahuueCPojsMSNrcqg72fGRVoZM83H8Eojy32rOo2o9FaJI1xoc1WfscXmfLLq87KC/82luLq+UEN5meYwm+ftlwrAgwBzdUTPwReAG+qz7ugb69herjek71aiI8Ig7IdLRdbPe+zUQeESBY9pyB/w==; 5:aD8/VKL+2MYXp7R5PC/H3YKxGcVXoVuSBIsYaQoX4jVHan3FbPlTMlaw9tMx7+9nbpKI+xLdyhLZIiBlIdbvmP45AsXy3zhseX9+L2hw1PP87Q1CsmKGUQhQPwhW/3Ow5Kz3/Q7HLBfQTNLp3porHdnwHLXw/WaPIHQgauxGhDM=; 7:5Hfvnd4DenCAkOcGYXXY3zULmlpNOBGkeXbO6GhFUnQcjGhz+9nldN1PIwXQtpdPBoIzR6TRNmAG+7YaSudUONkbmhKshoDazvbQTvJHg5TVpsXLPBZw6ZAOFvDIC+SWCJnegsrV4CQny+1V40n9HxI2BXpawelkXETIw0EgcoNyVtrkqLwg4U1/z3pqJ6Nu41enmfE9lZVkcbvcbk7YXyKKEB9RaphCBrzzuby7Gllb0Jp6WmHR83IpxjsXZfvF
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 8fc1e300-f77a-44ad-bddd-08d6119ca3c0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MEAPR01MB3239;
x-ms-traffictypediagnostic: MEAPR01MB3239:
x-microsoft-antispam-prvs:
x-exchange-antispam-report-test: UriScan:(28532068793085)(788757137089)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201708071742011)(7699016); SRVR:MEAPR01MB3239; BCL:0; PCL:0; RULEID:; SRVR:MEAPR01MB3239;
x-forefront-prvs: 0784C803FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(366004)(376002)(346002)(396003)(136003)(199004)(189003)(68736007)(2900100001)(11346002)(33656002)(236005)(99286004)(256004)(6306002)(8676002)(54896002)(21615005)(2906002)(9686003)(6346003)(97736004)(8936002)(66066001)(229853002)(316002)(102836004)(26005)(6506007)(76176011)(6436002)(5660300001)(446003)(7696005)(186003)(55016002)(486006)(6916009)(606006)(106356001)(6246003)(790700001)(105586002)(86362001)(93886005)(53936002)(6116002)(7736002)(25786009)(5250100002)(3846002)(478600001)(476003)(14454004)(81156014)(81166006)(72206003)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MEAPR01MB3239; H:MEAPR01MB3542.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com;
x-microsoft-antispam-message-info: QXoZvptFtC4dO2+G/PihqFdK+qQS/8O1vNWAOe1VYu+DydiZXKtcF480IcHsRi5LVkCqhpZxeaXjc08A4U6vbscHIbsO7pMG0xaoqpZRrQqliuEKNmv/dd8OtbCvJfed+vbxuomx8Q00/tVTGiXgGoAI1668LGgk0wrTw82jUiMInRk+m2ua6JFcvpC/OcQevZdnHAdBDjT7xgiew8gj4tluRwUTffoi4HPJNDSGBEN5Au1WY9oZVvPuEgjLvqpDMzKLbwnFIggxxuewzKqjQ7LQyqyJIIwrZ6U2OHTUz+GXv9yQbxcgEgbvsd9IVFKjO0torF3N/LBWRatFpUx4xndF4bfy2PwHupPa5TX4XAY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MEAPR01MB35421A39A59D01582D7C74CBE50C0MEAPR01MB3542ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8fc1e300-f77a-44ad-bddd-08d6119ca3c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2018 12:56:17.8601 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB3239
X-OriginatorOrg: team.telstra.com
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 03 Sep 2018 12:56:25 -0000
--_000_MEAPR01MB35421A39A59D01582D7C74CBE50C0MEAPR01MB3542ausp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
QUNNRTxodHRwczovL2lldGYtd2ctYWNtZS5naXRodWIuaW8vYWNtZS9kcmFmdC1pZXRmLWFjbWUt
YWNtZS5odG1sPiAoQXV0b21hdGljIENlcnRpZmljYXRlIE1hbmFnZW1lbnQgRW52aXJvbm1lbnQp
IFtkcmFmdC1pZXRmLWFjbWUtYWNtZV0gKGVnIExldHMgRW5jcnlwdCBDQSkgaXMgYW4gaW50ZXJl
c3RpbmcgY2FzZS4gSXQgUE9TVHMgSldTIG9iamVjdHMgdXNpbmcgdGhlIEZsYXR0ZW5lZCBKU09O
IFNlcmlhbGl6YXRpb24gd2l0aCBhICJ1cmwiIG1lbWJlciBpbiB0aGUgcHJvdGVjdGVkIGhlYWRl
ci4gSXQgaXMgbGlrZWx5IHRvIHVzZSB0aGUgc2FtZSBzY2hlbWUgKFBPU1QgYSBKV1MpIHRvIHJl
cGxhY2UgR0VUIG1ldGhvZHMgYXMgd2VsbC4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo=
--_000_MEAPR01MB35421A39A59D01582D7C74CBE50C0MEAPR01MB3542ausp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN
CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t
c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6
Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5tLTc1NjgwMzUzMjU3OTQxMzUzNTZoMg0K
CXttc28tc3R5bGUtbmFtZTptXy03NTY4MDM1MzI1Nzk0MTM1MzU2aDI7fQ0Kc3Bhbi5IZWFkaW5n
MkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMkU3NEI1O30NCnNwYW4ubS03NTY4MDM1
MzI1Nzk0MTM1MzU2YXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTptXy03NTY4MDM1
MzI1Nzk0MTM1MzU2YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w
cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48YSBocmVmPSJodHRwczovL2lldGYtd2ctYWNtZS5naXRodWIuaW8vYWNtZS9kcmFmdC1pZXRm
LWFjbWUtYWNtZS5odG1sIj5BQ01FPC9hPiAoQXV0b21hdGljIENlcnRpZmljYXRlIE1hbmFnZW1l
bnQgRW52aXJvbm1lbnQpIFtkcmFmdC1pZXRmLWFjbWUtYWNtZV0NCiAoZWcgTGV0cyBFbmNyeXB0
IENBKSBpcyBhbiBpbnRlcmVzdGluZyBjYXNlLiBJdCBQT1NUcyBKV1Mgb2JqZWN0cyB1c2luZyB0
aGUgRmxhdHRlbmVkIEpTT04gU2VyaWFsaXphdGlvbiB3aXRoIGEgJnF1b3Q7dXJsJnF1b3Q7IG1l
bWJlciBpbiB0aGUgcHJvdGVjdGVkIGhlYWRlci4gSXQgaXMgbGlrZWx5IHRvIHVzZSB0aGUgc2Ft
ZSBzY2hlbWUgKFBPU1QgYSBKV1MpIHRvIHJlcGxhY2UgR0VUIG1ldGhvZHMgYXMgd2VsbC48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KYW1lcyBNYW5nZXI8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=
--_000_MEAPR01MB35421A39A59D01582D7C74CBE50C0MEAPR01MB3542ausp_--
From nobody Mon Sep 3 06:09:59 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2566130E2F for ; Mon, 3 Sep 2018 06:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYyj6_R2DzZI for ; Mon, 3 Sep 2018 06:09:53 -0700 (PDT)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ECE12426A for ; Mon, 3 Sep 2018 06:09:53 -0700 (PDT)
Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id woc3fMS9Srv7qwoc4f1lNz; Mon, 03 Sep 2018 06:09:52 -0700
To: oauth@ietf.org
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com> <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
From: Vladimir Dzhuvinov
Openpgp: preference=signencrypt
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= xsBNBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAHNLFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+wsB+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1NdzsBNBFQZaoEB CADbPPN2c9iyif1rIiA3i+OAL2+jWlUwyM1hcfvA9zzYgQCFblNZk3lzkGukkCdSgyE3dibB 7TrP/7cPuSVp4sZ//PdSeYSP0NpURIi9Oqj4r3DlR1waR4g1pVPwXAhYvhsVD19RDdMasYBq enu+FXTvRKVB3erXBoXkBphhW4ekMh+E+21Cp2kaIf3VE4eK9565qFVem57CtTCqbpM8ElLb yQeHEl07bTrU8BCnmBJr9bg+h0Gp6s02PgebwXkiR5iGdANDrYHEmDj3XYdV8VFln4LRJeuj dGsZQpC9aQuFMhD5696iicelqHddNLZ0SOLnb8IxcTnU7HIjxMpgPBhPABEBAAHCwGUEGAEC AA8FAlQZaoECGwwFCQlmAYAACgkQGdL1Mjqq4kKPMwf+P+zfHt1/L+la1OszU8MXlarCHtRw qf0ROwUVB5PmLqGYqXSUN8qXFY38nIGNhxD/HAx8IZrlZ34FT9HH62hB3wmwvzO+JDl63yq0 0OJnywAaRUTSIwc6SnTQTgu0QSHidOG4yEXTNXDME14kO5Fvdlp6d2/vRDZ7oBcv6bX7g31H Ue5nai5/jXqQBikkgII6mst4GL803WLaNVvAUbLge25gvgdBdPgMpckNya0yzo9vHMQDDAhN oL1eAZ9MqG1qt2IVVE4dgHdNGUbREZ28Wur//gNTpama6eRrx7bOuVxf4euKbMxTMvHAP6bJ dIuenZiT6SZJLbpchHh+rgZ2rQ==
Organization: Connect2id Ltd.
Message-ID:
Date: Mon, 3 Sep 2018 16:09:51 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
Content-Type: multipart/alternative; boundary="------------24F7CAB46BBF76D3CB77276E"
Content-Language: en-US
X-CMAE-Envelope: MS4wfEUHG8ojZJi4TR6gSy4q04cfcfg2fykV+LFE3Ml+wVsUATd/3nNh1ohnSSfLWoCyt4cvitPdap7as9jRW4ZExQmSxTgphodiRE4GB72KTlFtdN+VR4rG aUkcnSUND43RUo0VcTsTtal1kb7GPsGLlzp0dNEAulX/x1rwxjLzkE3A
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 03 Sep 2018 13:09:57 -0000
This is a multi-part message in MIME format.
--------------24F7CAB46BBF76D3CB77276E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi George,
JSON-LD still requires c14n. I opened the particular spec and the c14n
job with JSON-LD appears quite complex. The structure of the linked data
must also be brought into some particular form.
https://json-ld.github.io/normalization/spec/
C10n of plain JSON should be a simpler job. There should also be more
and better software support for that. I don't think we can get around
JSON c10n, if we want to keep the message content in clear text.
Vladimir
On 03/09/18 15:27, George Fletcher wrote:
> I'm not a big fan of canonicalization for signatures. In the past it
> has been brittle, the libraries subject to bugs, and hard for
> developers to adopt. That said, if no canonicalization is not a
> requirement, have you checked out JSON-LD? It has embedded signature
> support. https://json-ld.org/spec/latest/
>
> On 9/3/18 6:23 AM, Dave Tonge wrote:
>> Hi Phil
>>
>> Thanks again for the helpful reply.
>> I 100% agree with you about the problem of false negatives with=C2=A0R=
FC3230.
>> I am not in favour of the its use and will do my best to highlight
>> these issues with those who are proposing its use with the draft
>> cavage spec.
>>
>> I also share your worry about the potential for things to move back
>> to a SOAP style of API.
>>
>> Having a look at the
>> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
>> spec it is quite general purpose, whereas I'm in favour of something
>> that is explicitly designed for JSON requests and responses. If there
>> was confidence=C2=A0in the JSON=C2=A0canonicalisation described in
>> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 then
>> this seems to enable APIs to stay REStful but with the support for
>> self-contained signatures. For many applications I agree that there
>> will need to be some repetition of values in the JSON payload that
>> are already in the header, e.g. audience, issuer and time. But if
>> general purpose HTTP signing is a lost cause, then "Cleartext JSON
>> Web Signatures"=C2=A0seem the next best thing.
>>
>> Dave
>>
>>
>>
>>
>>
>>
>> On Sat, 1 Sep 2018 at 01:06, Phil Hunt > > wrote:
>>
>> =C2=A0=C2=A0=C2=A0 Dave,
>>
>> =C2=A0=C2=A0=C2=A0 I=E2=80=99m not sure this is as useful as one might=
think - from RFC3230=E2=80=A6
>>>
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7 Security
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Considerations
>>>
>>>
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document specifies a =
data integrity mechanism that
>>> protects HTTP
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 instance data, but not HTT=
P entity headers, from certain
>>> kinds of
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 accidental corruption.=C2=A0=
It is also useful in detecting at
>>> least one
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 spoofing attack [9
>>> ].=C2=A0 However, it is no=
t
>>> intended as general
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protection against malicio=
us tampering with HTTP messages.
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The HTTP Digest Access Aut=
hentication mechanism [5
>>> ] provides some
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protection against malicio=
us tampering.
>>
>> =C2=A0=C2=A0=C2=A0 For example, if you have a corporate web proxy or I=
SP that decides
>> =C2=A0=C2=A0=C2=A0 to help out by doing content compression as an exam=
ple, all your
>> =C2=A0=C2=A0=C2=A0 requests will start failing (so-called accidental c=
orruption).=C2=A0 We
>> =C2=A0=C2=A0=C2=A0 learned from XML that consistent canonicalization o=
f the request
>> =C2=A0=C2=A0=C2=A0 data is important.
>>
>> =C2=A0=C2=A0=C2=A0 IOW=E2=80=A6RFC3230 is valid when it works, but wha=
t about all the times
>> =C2=A0=C2=A0=C2=A0 it fails for no apparent reason? (false negatives)
>>
>> =C2=A0=C2=A0=C2=A0 In my humble experience with REST, the HTTP body is=
only a small
>> =C2=A0=C2=A0=C2=A0 part of the transaction. The headers, method, and U=
RL parameters
>> =C2=A0=C2=A0=C2=A0 contain all of the semantics to an application tran=
saction. Sure
>> =C2=A0=C2=A0=C2=A0 there are some requests that are just built on HTTP=
POST. But you
>> =C2=A0=C2=A0=C2=A0 have to be sure, there are no parameters that matte=
r in the
>> =C2=A0=C2=A0=C2=A0 headers or URL.
>>
>> =C2=A0=C2=A0=C2=A0 The OAuth WG took a big ambitious stab at this (tha=
nks Justin),
>> =C2=A0=C2=A0=C2=A0 but we weren=E2=80=99t convinced implementations wo=
uld be stable..
>> =C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-ietf-oauth-signed=
-http-request-03
>>
>> =C2=A0=C2=A0=C2=A0 I can=E2=80=99t help but worry we are headed back t=
o RPC style SOAP like
>> =C2=A0=C2=A0=C2=A0 containers based on JSON tokens that can be signed =
and that
>> =C2=A0=C2=A0=C2=A0 contain all the semantics and data of a transaction=
to be signed.=C2=A0
>> =C2=A0=C2=A0=C2=A0 Now that I said that, I=E2=80=99m going to go wash =
my mouth out. Ugh.
>>
>> =C2=A0=C2=A0=C2=A0 Phil
>>
>>
>>
>>> =C2=A0=C2=A0=C2=A0 On Aug 31, 2018, at 3:05 PM, Dave Tonge
>>> =C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0 > wrote:
>>>
>>> =C2=A0=C2=A0=C2=A0 Thanks for the replies.
>>> =C2=A0=C2=A0=C2=A0 You're absolutely right Phil and George - apologie=
s I omitted the
>>> =C2=A0=C2=A0=C2=A0 digest step from the first email.
>>> =C2=A0=C2=A0=C2=A0 Both the STET and Berlin Group specs require the u=
se of SHA-256
>>> =C2=A0=C2=A0=C2=A0 or SHA-512 digest header as per RFC3230
>>> =C2=A0=C2=A0=C2=A0 (https://tools.ietf.org/html/rfc3230
>>> =C2=A0=C2=A0=C2=A0
>>> )
>>> =C2=A0=C2=A0=C2=A0 They then use the draft cavage spec to sign a defi=
ned set of
>>> =C2=A0=C2=A0=C2=A0 headers which includes the date and digest headers=
=2E.
>>>
>>> =C2=A0=C2=A0=C2=A0 > If you want attestation, better to use SET or pl=
ain JWT.
>>>
>>> =C2=A0=C2=A0=C2=A0 The pushback on this has been that to use JWTs for=
all API
>>> =C2=A0=C2=A0=C2=A0 request bodies and responses would make the APIs h=
arder to
>>> =C2=A0=C2=A0=C2=A0 develop against and debug.
>>> =C2=A0=C2=A0=C2=A0 However I do think it is a better option than havi=
ng signatures
>>> =C2=A0=C2=A0=C2=A0 in headers. I like the idea of using content negot=
iation to allow
>>> =C2=A0=C2=A0=C2=A0 clients to request either application/json or appl=
ication/jwt
>>> =C2=A0=C2=A0=C2=A0 from an API endpoint.
>>>
>>> =C2=A0=C2=A0=C2=A0 I'd be interested if there is any interest in the =
working group
>>> =C2=A0=C2=A0=C2=A0 for this draft though:
>>> =C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-erdtman-jose-cle=
artext-jws-00
>>> =C2=A0=C2=A0=C2=A0
>>> .
>>> =C2=A0=C2=A0=C2=A0 As Ben mentioned, does the issue of JSON canonical=
ization make
>>> =C2=A0=C2=A0=C2=A0 this a non-starter?
>>>
>>> =C2=A0=C2=A0=C2=A0 Thanks
>>>
>>> =C2=A0=C2=A0=C2=A0 Dave
>>
>>
>>
>> --=C2=A0
>> Dave Tonge
>> CTO
>> Moneyhub Enterprise
>>
>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol,
>> BS1 6FL
>> t: +44 (0)117 280 5120
>>
>> Moneyhub Enterprise is a trading style of Moneyhub Financial
>> Technology Limited which is authorised and regulated by the Financial
>> Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology is enter=
ed
>> on the Financial Services Register (FRN 809360) at
>> fca.org.uk/register . Moneyhub=C2=A0Financ=
ial
>> Technology is registered in England & Wales, company registration
>> number 06909772=C2=A0.
>> Moneyhub=C2=A0Financial Technology Limited 2018 =C2=A9
>>
>> DISCLAIMER: This email (including any attachments) is subject to
>> copyright, and the information in it is confidential. Use of this
>> email or of any information in it other than by the addressee is
>> unauthorised and unlawful. Whilst reasonable efforts are made to
>> ensure that any attachments are virus-free, it is the recipient's
>> sole responsibility to scan all attachments for viruses. All calls
>> and emails to and from this company may be monitored and recorded for
>> legitimate purposes relating to this company's business. Any opinions
>> expressed in this email (or in any attachments) are those of the
>> author and do not necessarily represent the opinions of Moneyhub
>> Financial Technology Limited or of any other group company.
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--------------24F7CAB46BBF76D3CB77276E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Hi George,
JSON-LD still requires c14n. I opened the particular spec and the
c14n job with JSON-LD appears quite complex. The structure of the
linked data must also be brought into some particular form.
https://json-ld.github.io/normalization/spec/
C10n of plain JSON should be a simpler job. There should also be
more and better software support for that. I don't think we can get
around JSON c10n, if we want to keep the message content in clear
text.
Vladimir
On 03/09/18 15:27, George Fletcher
wrote:
I'm not a
big fan of canonicalization for signatures. In the past it has
been brittle, the libraries subject to bugs, and hard for
developers to adopt. That said, if no canonicalization is not a
requirement, have you checked out JSON-LD? It has embedded
signature support. https://json-ld.org/spec/latest/
On 9/3/18 6:23 AM, Dave Tonge wrote:
Hi Phil
Thanks again for the helpful reply.
I 100% agree with you about the problem of false negatives
with RFC3230.
I am not in favour of the its use and will do my best to
highlight these issues with those who are proposing its use with
the draft cavage spec.
I also share your worry about the potential for things to move
back to a SOAP style of API.
Having a look at the
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
spec it is quite general purpose, whereas I'm in favour of
something that is explicitly designed for JSON requests and
responses. If there was confidence in the JSON canonicalisation
described in
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
then this seems to enable APIs to stay REStful but with the
support for self-contained signatures. For many applications I
agree that there will need to be some repetition of values in
the JSON payload that are already in the header, e.g. audience,
issuer and time. But if general purpose HTTP signing is a lost
cause, then "Cleartext JSON Web Signatures" seem the next best
thing.
Dave
On Sat, 1 Sep 2018 at 01:06, Phil Hunt <phil.hunt@oracle.com
<mailto:phil.hunt@oracle.com>> wrote:
Dave,
I’m not sure this is as useful as one might think - from
RFC3230…
7
<https://tools.ietf.org/html/rfc3230#section-7> Security
Considerations
This document specifies a data integrity mechanism
that protects HTTP
instance data, but not HTTP entity headers, from
certain kinds of
accidental corruption. It is also useful in detecting
at least one
spoofing attack [9
<https://tools.ietf.org/html/rfc3230#ref-9>]. However,
it is not intended as general
protection against malicious tampering with HTTP
messages.
The HTTP Digest Access Authentication mechanism [5
<https://tools.ietf.org/html/rfc3230#ref-5>] provides
some
protection against malicious tampering.
For example, if you have a corporate web proxy or ISP that
decides
to help out by doing content compression as an example, all
your
requests will start failing (so-called accidental
corruption). We
learned from XML that consistent canonicalization of the
request
data is important.
IOW…RFC3230 is valid when it works, but what about all the
times
it fails for no apparent reason? (false negatives)
In my humble experience with REST, the HTTP body is only a
small
part of the transaction. The headers, method, and URL
parameters
contain all of the semantics to an application transaction.
Sure
there are some requests that are just built on HTTP POST.
But you
have to be sure, there are no parameters that matter in the
headers or URL.
The OAuth WG took a big ambitious stab at this (thanks
Justin),
but we weren’t convinced implementations would be stable..
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
I can’t help but worry we are headed back to RPC style SOAP
like
containers based on JSON tokens that can be signed and that
contain all the semantics and data of a transaction to be
signed.
Now that I said that, I’m going to go wash my mouth out.
Ugh.
Phil
On Aug 31, 2018, at 3:05 PM, Dave
Tonge
<dave.tonge@momentumft.co.uk
<mailto:dave.tonge@momentumft.co.uk>> wrote:
Thanks for the replies.
You're absolutely right Phil and George - apologies I
omitted the
digest step from the first email.
Both the STET and Berlin Group specs require the use of
SHA-256
or SHA-512 digest header as per RFC3230
(https://tools.ietf.org/html/rfc3230
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3230&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=>)
They then use the draft cavage spec to sign a defined set
of
headers which includes the date and digest headers..
> If you want attestation, better to use SET or plain
JWT.
The pushback on this has been that to use JWTs for all API
request bodies and responses would make the APIs harder to
develop against and debug.
However I do think it is a better option than having
signatures
in headers. I like the idea of using content negotiation
to allow
clients to request either application/json or
application/jwt
from an API endpoint.
I'd be interested if there is any interest in the working
group
for this draft though:
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_draft-2Derdtman-2Djose-2Dcleartext-2Djws-2D00&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=0G1ikcDnNzvZqp7w6xlLnfhtq6GZGc0HlswqLcp4OK4&e=>.
As Ben mentioned, does the issue of JSON canonicalization
make
this a non-starter?
Thanks
Dave
--
Dave Tonge
CTO
Moneyhub Enterprise
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back,
Bristol, BS1 6FL
t: +44 (0)117 280 5120
Moneyhub Enterprise is a trading style of Moneyhub Financial
Technology Limited which is authorised and regulated by the
Financial Conduct Authority ("FCA"). Moneyhub Financial
Technology is entered on the Financial Services Register (FRN
809360) at fca.org.uk/register
<http://fca.org.uk/register>. Moneyhub Financial
Technology is registered in England & Wales, company
registration number 06909772 .
Moneyhub Financial Technology Limited 2018 ©
DISCLAIMER: This email (including any attachments) is subject to
copyright, and the information in it is confidential. Use of
this email or of any information in it other than by the
addressee is unauthorised and unlawful. Whilst reasonable
efforts are made to ensure that any attachments are virus-free,
it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this
company may be monitored and recorded for legitimate purposes
relating to this company's business. Any opinions expressed in
this email (or in any attachments) are those of the author and
do not necessarily represent the opinions of Moneyhub Financial
Technology Limited or of any other group company.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------24F7CAB46BBF76D3CB77276E--
From nobody Tue Sep 4 14:33:47 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AA4130F90 for ; Tue, 4 Sep 2018 14:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKTbadGcPv0J for ; Tue, 4 Sep 2018 14:33:41 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6BA130DC2 for ; Tue, 4 Sep 2018 14:33:40 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id s7-v6so2310534pgc.0 for ; Tue, 04 Sep 2018 14:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YevIhuEZGiYJPYK3HO4hbRqiNHi1/xyo33+6K5EmqY4=; b=xC+pvf1+MGQMH7keNDZMVNEeITP3xSAcWIc98Xjl+EUC0k4EJLmFc4wNejPM2C85c4 d4nII3Oywr2JpEonUm6RdDuOD4HjVRJHim8PFcGrjx8OhrO+7WYSZjCDW72oVZHlEGfG rumEmBfnnS1s4W5qeFZXzXeINdHZ816+b7cYn8cpWtV1u6SR+NMVclK56QUGtXnzWKsl i0XEV0SfztNblikKTdJP+CVTp6xrSS93YS0BYHbD6ej98hpJqt8co1mnvjfsCeOOGU5V VIvX+dDmvTj7+wwxgux1FitQ+N+Yph9QfX3kzNniwUbvJiCSgOuW31EiGPvJ3lpAxA1C LHXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YevIhuEZGiYJPYK3HO4hbRqiNHi1/xyo33+6K5EmqY4=; b=VqsdOdoT66V3pNig+E7xQV5PZDg/n/psmLNXJaIFbv6bJ9JkWpY+yHBr3zthN4aLcm vUBl04bild4tmkgVcYs+i/MMG6DzMN1NMSlWjN4aBZ7i4zLjdqP4ebegOwfTCA7s+tGO 8E8tD2Iwcktv0102AWOTml6SZfl5nYSxt+Ap/fM2VYeomNwMb8U2uoUNnN/eEiJCDGb1 nYpiZnX6oS35MX0QaJlpvL05TRTz8Bn+DiN+6dMYUpBVw0F2p16B4QS8ZxzHmLWPMMH9 TQ1uwQh12kfreqwjJGSledHxW7UGDfA3C1FfJXyBkvRRro0m3tsv39SjCKxM6QsW1Paj 5tGw==
X-Gm-Message-State: APzg51A1eivzoeyUew1zez3/G37gB5qh3jgXSThOxfbaN3OvoMmEwM7t KE7uv3KwgshD+pOK2Njof83HppCcHNQlHI9GMJfzSHYXfewEyg==
X-Google-Smtp-Source: ANB0VdaHkkQ3MQeaVyQupkqzArpi0qK0BBVPBvrZyl1cYewfDGj5EH3NgYb1v+wp0wBnjRB1Fwt4ZxPDCItcaEVa4UE=
X-Received: by 2002:a63:f414:: with SMTP id g20-v6mr18648212pgi.407.1536096819931; Tue, 04 Sep 2018 14:33:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:a109:0:0:0:0 with HTTP; Tue, 4 Sep 2018 14:33:39 -0700 (PDT)
In-Reply-To:
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com> <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
From: Samuel Erdtman
Date: Tue, 4 Sep 2018 23:33:39 +0200
Message-ID:
To: "" , dave.tonge@momentumft.co.uk
Cc: Anders Rundgren , Mike Jones , Daniel Lindau
Content-Type: multipart/alternative; boundary="0000000000004b0482057512694b"
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 04 Sep 2018 21:33:46 -0000
--0000000000004b0482057512694b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi
As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
think this is the way to go. The initial use case was to sign transaction
requests and responses, and as was mentioned in previous emails it is very
much desirable to not obfuscate the payload with base64 encoding.
The current draft just expired but if we have found interest I would be
more than willing to post an update. I was supposed to do so earlier but
since it has been hard to find a home for the work (an interested WG) it
has not be top of my proirity list.
With the potential update we (I and the co authors) intended to do some
cleanup and one significant change. We think we should move from ES6
serialization to canonicalization based on
draft-rundgren-json-canonicalization-scheme
.
After a lot of research and emails we have come to the conclusion that it
would be easier to get buy in for this method than to get languages to
support ES6 compatible serialization.
draft-rundgren-json-canonicalization-scheme has the additional benefit that
non-intrusive modifications such as attribute reordering would not make
ruin this signature which was the case with ES6 serialization (and we could
avoid some minor ES6 quirks).
Implementations for the draft-rundgren-json-canonicalization-scheme
canonicalization schema is available in JavaScript
, .NET
, J=
ava
,
and Python
.
Anders is currently putting a lot of effort into the canonicalization to
make sure it is stable, and it has been reviewed by several people
knowledgeable in JSON.
When it comes to draft-erdtman-jose-cleartext-jws implementations, I have
done one in JavaScript (I modified an existing JOSE implementation in a few
hours) and Anders has done a Java implementation (at least). The examples
in the specification was created and validated with different
implementations.
I know canonicalization is a scary thing if you have worked with
canonicalization of XML, but I can tell you canonicalization of JSON is not
even close to that complex.
Best regards
//Samuel Erdtman
On Mon, Sep 3, 2018 at 3:09 PM, Vladimir Dzhuvinov
wrote:
> Hi George,
>
> JSON-LD still requires c14n. I opened the particular spec and the c14n jo=
b
> with JSON-LD appears quite complex. The structure of the linked data must
> also be brought into some particular form.
>
> https://json-ld.github.io/normalization/spec/
>
> C10n of plain JSON should be a simpler job. There should also be more and
> better software support for that. I don't think we can get around JSON
> c10n, if we want to keep the message content in clear text.
>
> Vladimir
>
> On 03/09/18 15:27, George Fletcher wrote:
>
> I'm not a big fan of canonicalization for signatures. In the past it has
> been brittle, the libraries subject to bugs, and hard for developers to
> adopt. That said, if no canonicalization is not a requirement, have you
> checked out JSON-LD? It has embedded signature support.
> https://json-ld.org/spec/latest/
>
> On 9/3/18 6:23 AM, Dave Tonge wrote:
>
> Hi Phil
>
> Thanks again for the helpful reply.
> I 100% agree with you about the problem of false negatives with RFC3230.
> I am not in favour of the its use and will do my best to highlight these
> issues with those who are proposing its use with the draft cavage spec.
>
> I also share your worry about the potential for things to move back to a
> SOAP style of API.
>
> Having a look at the https://tools.ietf.org/html/dr
> aft-ietf-oauth-signed-http-request-03 spec it is quite general purpose,
> whereas I'm in favour of something that is explicitly designed for JSON
> requests and responses. If there was confidence in the
> JSON canonicalisation described in https://tools.ietf.org/html/dr
> aft-erdtman-jose-cleartext-jws-00 then this seems to enable APIs to stay
> REStful but with the support for self-contained signatures. For many
> applications I agree that there will need to be some repetition of values
> in the JSON payload that are already in the header, e.g. audience, issuer
> and time. But if general purpose HTTP signing is a lost cause, then
> "Cleartext JSON Web Signatures" seem the next best thing.
>
> Dave
>
>
>
>
>
>
> On Sat, 1 Sep 2018 at 01:06, Phil Hunt > wrote:
>
> Dave,
>
> I=E2=80=99m not sure this is as useful as one might think - from RFC3=
230=E2=80=A6
>
>
>
> 7
> Security
> Considerations
>
>
>
> This document specifies a data integrity mechanism that protects
> HTTP
> instance data, but not HTTP entity headers, from certain kinds of
> accidental corruption. It is also useful in detecting at least
> one
> spoofing attack [9
> ]. However, it is not
> intended as general
> protection against malicious tampering with HTTP messages.
>
> The HTTP Digest Access Authentication mechanism [5
>
> ] provides some
> protection against malicious tampering.
>
>
> For example, if you have a corporate web proxy or ISP that decides
> to help out by doing content compression as an example, all your
> requests will start failing (so-called accidental corruption). We
> learned from XML that consistent canonicalization of the request
> data is important.
>
> IOW=E2=80=A6RFC3230 is valid when it works, but what about all the ti=
mes
> it fails for no apparent reason? (false negatives)
>
> In my humble experience with REST, the HTTP body is only a small
> part of the transaction. The headers, method, and URL parameters
> contain all of the semantics to an application transaction. Sure
> there are some requests that are just built on HTTP POST. But you
> have to be sure, there are no parameters that matter in the
> headers or URL.
>
> The OAuth WG took a big ambitious stab at this (thanks Justin),
> but we weren=E2=80=99t convinced implementations would be stable..
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
>
> I can=E2=80=99t help but worry we are headed back to RPC style SOAP l=
ike
> containers based on JSON tokens that can be signed and that
> contain all the semantics and data of a transaction to be signed.
> Now that I said that, I=E2=80=99m going to go wash my mouth out. Ugh.
>
> Phil
>
>
>
> On Aug 31, 2018, at 3:05 PM, Dave Tonge
> >
> wrote:
>
> Thanks for the replies.
> You're absolutely right Phil and George - apologies I omitted the
> digest step from the first email.
> Both the STET and Berlin Group specs require the use of SHA-256
> or SHA-512 digest header as per RFC3230
> (https://tools.ietf.org/html/rfc3230
> ietf.org_html_rfc3230&d=3DDwMFaQ&c=3DRoP1YumCXCgaWHvlZYR8P
> Zh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aL
> cLN4KZNA&m=3D_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=3D
> y5Rg_ik_9mvP1Whrv68p0G885X7gRo32oxxeEeA08Ys&e=3D>
>
> )
> They then use the draft cavage spec to sign a defined set of
> headers which includes the date and digest headers..
>
> > If you want attestation, better to use SET or plain JWT.
>
> The pushback on this has been that to use JWTs for all API
> request bodies and responses would make the APIs harder to
> develop against and debug.
> However I do think it is a better option than having signatures
> in headers. I like the idea of using content negotiation to allow
> clients to request either application/json or application/jwt
> from an API endpoint.
>
> I'd be interested if there is any interest in the working group
> for this draft though:
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00
> ietf..org_html_draft-2Derdtman-2Djose-2Dcleartext-
> 2Djws-2D00&d=3DDwMFaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap
> I_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D_ipDvD
> LnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=3D0G1ikcDnNzvZqp7w6xlL
> nfhtq6GZGc0HlswqLcp4OK4&e=3D>
>
> .
> As Ben mentioned, does the issue of JSON canonicalization make
> this a non-starter?
>
> Thanks
>
> Dave
>
>
>
>
> --
> Dave Tonge
> CTO
> Moneyhub Enterprise ttp%3A%2F%2Fmoneyhubenterprise.com%2F&sa=3DD&sntz=3D1&usg=3DAFQjCN
> GUnR5opJv5S1uZOVg8aISwPKAv3A>
>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F=
L
> t: +44 (0)117 280 5120
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at fca.org.uk/register
> .
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772 .
> Moneyhub Financial Technology Limited 2018 =C2=A9
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email o=
r
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachmen=
ts
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company ma=
y
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
--0000000000004b0482057512694b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi=
As one of the authors of draft-erdtman-jose-clear=
text-jws I definitely think this is the way to go. The initial use cas=
e was to sign transaction requests and responses, and as was mentioned in p=
revious emails it is very much desirable to not obfuscate the payload with =
base64 encoding.
The current draft just expired bu=
t if we have found interest I would be more than willing to post an update.=
I was supposed to do so earlier but since it has been hard to find a home =
for the work (an interested WG) it has not be top of my proirity list.
=
With the potential update we (I and the co author=
s) intended to do some cleanup and one significant change. We think we shou=
ld move from ES6 serialization to canonicalization based on
dra=
ft-rundgren-json-canonicalization-scheme. After a lot of research and e=
mails we have come to the conclusion that it would be easier to get buy in =
for this method than to get languages to support ES6 compatible serializati=
on. draft-rundgren-json-canonicalization-scheme has the additional benefit =
that non-intrusive modifications such as attribute reordering would not mak=
e ruin this signature which was the case with ES6 serialization (and we cou=
ld avoid some minor ES6 quirks).
Implementati=
ons for the=C2=A0draft-rundgren-json-canonicalization-scheme canonicalizati=
on schema is available in
JavaScript,
.NET,
Java , =
and
Python. Anders is currently putting a lot of effort into t=
he canonicalization to make sure it is stable, and it has been reviewed by =
several people knowledgeable in JSON.
When it =
comes to draft-erdtman-jose-cleartext-jws implementations, I have done=
one in JavaScript (I modified an existing JOSE implementation in a few hou=
rs) and Anders has done a Java implementation (at least). The examples in t=
he specification was created and validated with different implementations.<=
br>
I know canonicalization is a scary thing if yo=
u have worked with canonicalization of XML, but I can tell you canonicaliza=
tion of JSON is not even close to that complex.
Be=
st regards
//Samuel Erdtman
--0000000000004b0482057512694b--
From nobody Wed Sep 5 06:54:48 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A73126CC7 for ; Wed, 5 Sep 2018 06:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Imm_a4LgRxeZ for ; Wed, 5 Sep 2018 06:54:43 -0700 (PDT)
Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4341128BAC for ; Wed, 5 Sep 2018 06:54:42 -0700 (PDT)
Received: by mail-lf1-x144.google.com with SMTP id h64-v6so6054261lfi.10 for ; Wed, 05 Sep 2018 06:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jUBFQCdyB/O80JmAcT8KaL41DRQoF/6m/HuW2sLb+2U=; b=YaRwJpPK/QWKr2UB1zhQnJSZrURJFbNRI+BO/e9v3/7RN/CalRMm9YNNoWykvUy7Fx 9nki307qvksTZ/6OWug6pkVgCif25i1t0SHGPRw1lsONVfNlJGUS8AU6mqmULbPhMfMK smC8xnVQjBHTj15A7uhhYJhKFWcYUGg6ZDlI8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jUBFQCdyB/O80JmAcT8KaL41DRQoF/6m/HuW2sLb+2U=; b=TYTH/gg3Y/aCIEdOes5zgXPmXIiDfNJHE0T57s3HELA8Y2mCXav34HioinR6hpJk1Z hvqyX6De+uTkfyWNefcQop9RszTPQjYJGF3aw0RjplZhFWcko8e0PZWa7iZCooFAhqQW +/SoakSniZbrMjuQBFiQC7jhOmfbQ/0vv0kWRrHptuRxkN/D4+2HmDiBsjqKjrOjntcv yCHI5BArSqK9jsOck4KffcC/BqXMTLTmGsjzdjT+5NWI929qDZtVHuPs/4fhjg0xj/JK USy4+85RwQ3NKzhOkCA8gGN+UhEYOi4Q3/D/TPhXL1bTIRIu8pj26fWvsJ/8SozFYo48 NkyA==
X-Gm-Message-State: APzg51B69x0aP+6++L2vbd2WY1At4awCGkx/1foE5W/LXjioTykNwj9P 7AxjxvWu5LxoBxExtG9H24ZapFt7u47MaylDUbyPiw==
X-Google-Smtp-Source: ANB0VdY19Ixb2hLEQrjb5PBx6BJ2V84l3wAEV2JKxvEy1cAquuWKgXYDigjeY9KHp2I9l+C6yilo5atITLVFB4KxTRI=
X-Received: by 2002:a19:2bcd:: with SMTP id r196-v6mr17754778lfr.30.1536155681063; Wed, 05 Sep 2018 06:54:41 -0700 (PDT)
MIME-Version: 1.0
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com> <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
In-Reply-To:
From: Dave Tonge
Date: Wed, 5 Sep 2018 15:54:29 +0200
Message-ID:
To: Samuel Erdtman
Cc: oauth , Anders Rundgren , Mike Jones , d.lindau@gmail.com
Content-Type: multipart/alternative; boundary="000000000000b0a4990575201d1c"
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2018 13:54:46 -0000
--000000000000b0a4990575201d1c
Content-Type: text/plain; charset="UTF-8"
Hi Samuel,
Thanks for the reply, I would definitely be interested in an updated draft.
Both the signing spec and the canonicalization spec seem a lot simpler than
JSON-LD.
It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs
Thanks
Dave
On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman wrote:
> Hi
>
> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
> think this is the way to go. The initial use case was to sign transaction
> requests and responses, and as was mentioned in previous emails it is very
> much desirable to not obfuscate the payload with base64 encoding.
>
> The current draft just expired but if we have found interest I would be
> more than willing to post an update. I was supposed to do so earlier but
> since it has been hard to find a home for the work (an interested WG) it
> has not be top of my proirity list.
>
> With the potential update we (I and the co authors) intended to do some
> cleanup and one significant change. We think we should move from ES6
> serialization to canonicalization based on
> draft-rundgren-json-canonicalization-scheme
> .
> After a lot of research and emails we have come to the conclusion that it
> would be easier to get buy in for this method than to get languages to
> support ES6 compatible serialization.
> draft-rundgren-json-canonicalization-scheme has the additional benefit that
> non-intrusive modifications such as attribute reordering would not make
> ruin this signature which was the case with ES6 serialization (and we could
> avoid some minor ES6 quirks).
>
> Implementations for the draft-rundgren-json-canonicalization-scheme
> canonicalization schema is available in JavaScript
> , .NET
> , Java
>
> ,
> and Python
> .
> Anders is currently putting a lot of effort into the canonicalization to
> make sure it is stable, and it has been reviewed by several people
> knowledgeable in JSON.
>
> When it comes to draft-erdtman-jose-cleartext-jws implementations, I have
> done one in JavaScript (I modified an existing JOSE implementation in a few
> hours) and Anders has done a Java implementation (at least). The examples
> in the specification was created and validated with different
> implementations.
>
> I know canonicalization is a scary thing if you have worked with
> canonicalization of XML, but I can tell you canonicalization of JSON is not
> even close to that complex.
>
> Best regards
> //Samuel Erdtman
>
>
--000000000000b0a4990575201d1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Samuel,
<=
br>
Thanks for the reply, I would definitely be interested=
in an updated draft.
Both the signing spec and the=C2=A0<=
span style=3D"font-family:Arial,Helvetica,sans-serif">canonicalization spec=
seem a lot simpler than JSON-LD.
It wouldn't be hard to add cleart=
ext-jws signatures to existing JSON APIs
T=
hanks
Dave
Hi=
div>
As one of the authors of draft-erdtman-jose-clearte=
xt-jws I definitely think this is the way to go. The initial use case was t=
o sign transaction requests and responses, and as was mentioned in previous=
emails it is very much desirable to not obfuscate the payload with base64 =
encoding.
The current draft just expired but if we=
have found interest I would be more than willing to post an update. I was =
supposed to do so earlier but since it has been hard to find a home for the=
work (an interested WG) it has not be top of my proirity list.
<=
div>
With the potential update we (I and the co authors) inte=
nded to do some cleanup and one significant change. We think we should move=
from ES6 serialization to canonicalization based on
draft-rundgren-json-canonicalization-scheme. After a lot of res=
earch and emails we have come to the conclusion that it would be easier to =
get buy in for this method than to get languages to support ES6 compatible =
serialization. draft-rundgren-json-canonicalization-scheme has the addition=
al benefit that non-intrusive modifications such as attribute reordering wo=
uld not make ruin this signature which was the case with ES6 serialization =
(and we could avoid some minor ES6 quirks).
I=
mplementations for the=C2=A0draft-rundgren-json-canonicalization-scheme can=
onicalization schema is available in
JavaScript,
.NET,
Java , and
Python. Anders is currently putting a lot of effor=
t into the canonicalization to make sure it is stable, and it has been revi=
ewed by several people knowledgeable in JSON.
=
When it comes to draft-erdtman-jose-cleartext-jws implementations, I have d=
one one in JavaScript (I modified an existing JOSE implementation in a few =
hours) and Anders has done a Java implementation (at least). The examples i=
n the specification was created and validated with different implementation=
s.
I know canonicalization is a scary thing if=
you have worked with canonicalization of XML, but I can tell you canonical=
ization of JSON is not even close to that complex.
Best regards
//Samuel Erdtman
--000000000000b0a4990575201d1c--
From nobody Wed Sep 5 07:02:15 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412B8130E01 for ; Wed, 5 Sep 2018 07:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6_UtL17iWIy for ; Wed, 5 Sep 2018 07:02:10 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21647130DF7 for ; Wed, 5 Sep 2018 07:02:09 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id x17-v6so3544641pfh.5 for ; Wed, 05 Sep 2018 07:02:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ni7+5fArclLa1sAZ8UUzVjvsfq6+9UpZPdFqd28FSV4=; b=ZuhEwte7gqmxl4RWAgE/k2zQwRm2PGdayVl976wQPmdMQP5E65ZEuWsFXn5z46YXDh cv4z6LuhSfX1qZu3K41f8lZwshw4E5N4sjuOgLKUCmhm7QAFaGeEMLeW9pI0Assn5/7z vEmmb4qP5IqJqP7xxcCMQs3tXQfhrvoZocS0sJWbKApQsBrQ1TNf2TtiBWb+LQjpwClZ LefKV8HqdTV1E2BakVG2unNyrhGzXjRMv0DLBCOe55qLHZrnR92hYlKVVPGLC4XJujJ6 S0s3hTt8GTK9xPKO1Dt+EdkYCWh9atkX2u6t/IxK5ECJFder6+0Pzle25FUWOdH7LR7A kxuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ni7+5fArclLa1sAZ8UUzVjvsfq6+9UpZPdFqd28FSV4=; b=uQwDp5w669veKg76NBaFDVzGW7zf/fUqgtMymknxXCKzoFmeM26dcOBl0XOPzwRRF/ QXSWQtDnKESBPZ9Mxmlim3YWs4sp23iEc9Ey5EaYRdEv6PbjzIocAPGnHqIDOODb52fK IAHJM8JCNICk5V3oFEG0XKMBqkvPqi+dgn7tMyvGRalc74Bl1yPTrT018HP/htPqmQV6 gLIsGJwz5VzH1/9SWuFo7quf8yiy6Cx0ahyD3uADON3G96DqKZJHUCtZnmi4OAHQ8bVN qCfalqB69Em1BIhXo0dNRj3QkqdqUMldhU+ra+a8PFg8pdlcWfMJ9GdfUm5wamuekZX0 gifA==
X-Gm-Message-State: APzg51CO9/y81Un6jjhyk82tSqz2YDzcz3jYoysWCBAUYcmNWHOLYwXu DHD5etWWJQtsfandmxWlxUlyOYST5xOEGnnwJP53mw==
X-Google-Smtp-Source: ANB0VdZRfnPnmCcKHFiwYwyYpNekSJK7BooMlU3+K5D0v/ll8ie63hn3dMDawaaYsd6232kANNEradty0BvTXIKj88M=
X-Received: by 2002:a63:1a5a:: with SMTP id a26-v6mr1808694pgm.9.1536156129368; Wed, 05 Sep 2018 07:02:09 -0700 (PDT)
MIME-Version: 1.0
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com> <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
In-Reply-To:
From: Samuel Erdtman
Date: Wed, 5 Sep 2018 16:01:57 +0200
Message-ID:
To: Dave Tonge
Cc: oauth , Anders Rundgren , Mike Jones , d.lindau@gmail.com
Content-Type: multipart/alternative; boundary="000000000000693193057520388f"
Archived-At:
Subject: Re: [OAUTH-WG] Non-repudiation for API requests and responses
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2018 14:02:14 -0000
--000000000000693193057520388f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Then I=E2=80=99ll post an update within a ~week.
There is one thing that could make implementing even simpler (from my
experience). That is how to handle multiple signatures. Today the
specification supports sharing of headers between signatures. If signatures
instead are completely independent and put in an array at the top level
cleartext_signature attribute one could just do a minor change to existing
implementations to support cleartext signatures.
On Wed, 5 Sep 2018 at 15:54, Dave Tonge wrote=
:
> Hi Samuel,
>
> Thanks for the reply, I would definitely be interested in an updated draf=
t.
> Both the signing spec and the canonicalization spec seem a lot simpler
> than JSON-LD.
> It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs
>
> Thanks
>
> Dave
>
> On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman wrote:
>
>> Hi
>>
>> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely
>> think this is the way to go. The initial use case was to sign transactio=
n
>> requests and responses, and as was mentioned in previous emails it is ve=
ry
>> much desirable to not obfuscate the payload with base64 encoding.
>>
>> The current draft just expired but if we have found interest I would be
>> more than willing to post an update. I was supposed to do so earlier but
>> since it has been hard to find a home for the work (an interested WG) it
>> has not be top of my proirity list.
>>
>> With the potential update we (I and the co authors) intended to do some
>> cleanup and one significant change. We think we should move from ES6
>> serialization to canonicalization based on
>> draft-rundgren-json-canonicalization-scheme
>> .
>> After a lot of research and emails we have come to the conclusion that i=
t
>> would be easier to get buy in for this method than to get languages to
>> support ES6 compatible serialization.
>> draft-rundgren-json-canonicalization-scheme has the additional benefit t=
hat
>> non-intrusive modifications such as attribute reordering would not make
>> ruin this signature which was the case with ES6 serialization (and we co=
uld
>> avoid some minor ES6 quirks).
>>
>> Implementations for the draft-rundgren-json-canonicalization-scheme
>> canonicalization schema is available in JavaScript
>> , .NET
>> =
,
>> Java
>> ,
>> and Python
>> .
>> Anders is currently putting a lot of effort into the canonicalization to
>> make sure it is stable, and it has been reviewed by several people
>> knowledgeable in JSON.
>>
>> When it comes to draft-erdtman-jose-cleartext-jws implementations, I hav=
e
>> done one in JavaScript (I modified an existing JOSE implementation in a =
few
>> hours) and Anders has done a Java implementation (at least). The example=
s
>> in the specification was created and validated with different
>> implementations.
>>
>> I know canonicalization is a scary thing if you have worked with
>> canonicalization of XML, but I can tell you canonicalization of JSON is =
not
>> even close to that complex.
>>
>> Best regards
>> //Samuel Erdtman
>>
>>
--000000000000693193057520388f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Then I=E2=80=99ll post an update within a ~week.
There is one thing =
that could make implementing even simpler (from my experience). That is how=
to handle multiple signatures. Today the specification supports sharing of=
headers between signatures. If signatures instead are completely independe=
nt and put in an array at the top level cleartext_signature attribute one c=
ould just do a minor change to existing implementations to support cleartex=
t signatures.
Thanks for the reply, I would definitely be =
interested in an updated draft.
Both the signing spec and =
the=C2=A0canonicaliz=
ation spec seem a lot simpler than JSON-LD.
It wouldn't be hard to =
add cleartext-jws signatures to existing JSON APIs
<=
div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s=
ans-serif">Thanks
Dave
Hi
As one of the authors of draft-erdtman-jose-cleartext-jws I definite=
ly think this is the way to go. The initial use case was to sign transactio=
n requests and responses, and as was mentioned in previous emails it is ver=
y much desirable to not obfuscate the payload with base64 encoding.
The current draft just expired but if we have found inter=
est I would be more than willing to post an update. I was supposed to do so=
earlier but since it has been hard to find a home for the work (an interes=
ted WG) it has not be top of my proirity list.
With the potential update we (I and the co authors) intended to do some c=
leanup and one significant change. We think we should move from ES6 seriali=
zation to canonicalization based on draft-run=
dgren-json-canonicalization-scheme. After a lot of research and emails =
we have come to the conclusion that it would be easier to get buy in for th=
is method than to get languages to support ES6 compatible serialization. dr=
aft-rundgren-json-canonicalization-scheme has the additional benefit that n=
on-intrusive modifications such as attribute reordering would not make ruin=
this signature which was the case with ES6 serialization (and we could avo=
id some minor ES6 quirks).
Implementations fo=
r the=C2=A0draft-rundgren-json-canonicalization-scheme canonicalization sch=
ema is available in
JavaScript,
.NET,
Java , and
Python. Anders is currently putting a lot of effort into the canoni=
calization to make sure it is stable, and it has been reviewed by several p=
eople knowledgeable in JSON.
When it comes to =
draft-erdtman-jose-cleartext-jws implementations, I have done one in JavaSc=
ript (I modified an existing JOSE implementation in a few hours) and Anders=
has done a Java implementation (at least). The examples in the specificati=
on was created and validated with different implementations.
=
I know canonicalization is a scary thing if you have worked =
with canonicalization of XML, but I can tell you canonicalization of JSON i=
s not even close to that complex.
Best regards
//Samuel Erdtman
--000000000000693193057520388f--
From nobody Wed Sep 5 07:52:25 2018
Return-Path:
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F62130E71 for ; Wed, 5 Sep 2018 07:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Q0SmW8kGrb for ; Wed, 5 Sep 2018 07:52:07 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC54130E23 for ; Wed, 5 Sep 2018 07:52:07 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id x26-v6so6232401lfi.7 for ; Wed, 05 Sep 2018 07:52:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BiRIC/uyipX+vZDZikiybWME8PzZvGjTy3vLslklxHY=; b=D+gKcKJs23ffc22BuTUpY7RXwdmWDc7Fgkfp1XdlN0y1M9p0r4/fZkccT3eTf9uZ90 bQRXOKnzAA4aH8sGZj9hwptOn76w5iRzM9xyQSZKP86RDnh75WFwmjxDNhFTfnpZkoQb 0C7T4V+vZNHnhSQbBMp0d0LgsYCfz8JlgUGcs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BiRIC/uyipX+vZDZikiybWME8PzZvGjTy3vLslklxHY=; b=XKLPdwP4H8JlJP7m2o73dezTpBURAdF7oYDtfss5tePcfgf1LzJLWHgz/MQbJxPKza S1lk1tGRiCWRXZgf94Mp+eYnUVyP5UhHxQriX7D04Saa6CrSrdem/xUMFQ7oypumzTkU auRb3v8wr83F6egJTYzmYujJBCXkStJ8JUIUDzE70twgN2SlcdpTqP3xwRylHHraY6fU cMyEfVVR3jHyWLeQiCbjZ2kos54U+UPMKVleEerLVQdo/sSnxAfJ+JZ1bMnQ0oNG8lZD GpRgFOv6hQJCDfqW/m5VAWUl+L+uHiP73ZXRWMQbUnLPAvZUgpZXjShjkKOBpDapK9+3 LmRA==
X-Gm-Message-State: APzg51ClZwGkKW71Y9qnJJ92E8df+17WP9AkIOnrxvmjDeCLt9iyq1VC xZLg3K2SuKwAyih/alVB+kB8EAfxRKTlca5gYNMRlzGyhEM=
X-Google-Smtp-Source: ANB0VdbO4oCshQbv5W4UKuDWIzE0GBTpqaeNJT1/hzZZw7KDsS1B+1yLmbNc7Im9yskxL0awgtiOtn+AsuIWGxHxOPo=
X-Received: by 2002:a19:d38b:: with SMTP id k133-v6mr23040197lfg.43.1536159125634; Wed, 05 Sep 2018 07:52:05 -0700 (PDT)
MIME-Version: 1.0
References: <20180831144510.GO15624@kduck.kaduk.org> <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com> <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>
In-Reply-To: