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.
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>
On Sat, 1 Sep 2018 at =
01:06, Phil Hunt <phil.hunt@orac=
le.com> wrote:
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

The OAuth WG took a big ambitious stab at this (thank=
s Justin), but we weren=E2=80=99t convinced implementations would be stable=
. https://tools.ietf.org/html/draft-ietf-oauth-signe=
d-http-request-03=C2=A0=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.



Phil







On Aug 31, 2018, at 3:05 PM, Dave T=
onge <d=
ave.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 B=
erlin Group specs require the use of SHA-256 or SHA-512 digest header as pe=
r 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, 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
3D"Moneyhub
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

                    


                    

                    


                    

                    


                      

                    
 

                    


                      

                    


                      

                  

                

              

            

          

        

      

      

      

        
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 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 <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)

                              
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--


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

 






On Mon, Sep 3,=
 2018 at 3:09 PM, Vladimir Dzhuvinov <vladimir@connect2id.com>=
; wrote:

 =20
   =20
 =20
  

    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=A0RFC3230.
        

        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=A0canonicali=
sation
        described in
        https://tools.ietf.org/html/draft-erd=
tman-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 <phil.hunt@oracle.com
        <=
;mailto:phil.hunt@oracle.com>> 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 mi=
ght think - from
        RFC3230=E2=80=A6
        

        

          

          

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7
          <https://tools.ietf.org/html/rfc3230#section-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 specifie=
s 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=
 HTTP 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
          <https://tools.ietf.org/html/rfc3230#ref-9>].=
=C2=A0 However,
          it is not intended as general
          

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protection against mal=
icious tampering with HTTP
          messages.
          

          

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The HTTP Digest Access=
 Authentication mechanism [5
          <https://tools.ietf.org/html/rfc3230#ref-5>] pr=
ovides
          some
          

          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protection against mal=
icious tampering.
          

        

        

        =C2=A0=C2=A0=C2=A0 For example, if you have a corporate web proxy o=
r ISP that
        decides
        

        =C2=A0=C2=A0=C2=A0 to help out by doing content compression as an e=
xample, all
        your
        

        =C2=A0=C2=A0=C2=A0 requests will start failing (so-called accidenta=
l
        corruption).=C2=A0 We
        

        =C2=A0=C2=A0=C2=A0 learned from XML that consistent canonicalizatio=
n of 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 =
what about all the
        times
        

        =C2=A0=C2=A0=C2=A0 it fails for no apparent reason? (false negative=
s)
        

        

        =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, an=
d URL
        parameters
        

        =C2=A0=C2=A0=C2=A0 contain all of the semantics to an application t=
ransaction.
        Sure
        

        =C2=A0=C2=A0=C2=A0 there are some requests that are just built on H=
TTP POST.
        But you
        

        =C2=A0=C2=A0=C2=A0 have to be sure, there are no parameters that ma=
tter 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 (=
thanks
        Justin),
        

        =C2=A0=C2=A0=C2=A0 but we weren=E2=80=99t convinced implementations=
 would 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 bac=
k to RPC style SOAP
        like
        

        =C2=A0=C2=A0=C2=A0 containers based on JSON tokens that can be sign=
ed and that
        

        =C2=A0=C2=A0=C2=A0 contain all the semantics and data of a transact=
ion to be
        signed.=C2=A0
        

        =C2=A0=C2=A0=C2=A0 Now that I said that, I=E2=80=99m going to go wa=
sh 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 <dave.tonge@momentumft.co.uk
          

          =C2=A0=C2=A0=C2=A0 <mailto:dave.tonge@momentumft.co.uk>> wrote:
          

          

          =C2=A0=C2=A0=C2=A0 Thanks for the replies.
          

          =C2=A0=C2=A0=C2=A0 You're absolutely right Phil and George - =
apologies 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 t=
he use 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
<https://urldefense.=
proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_rfc3230&a=
mp;d=3DDwMFaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=
&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D_ipD=
vDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=3Dy5Rg_ik_9mvP1Whrv=
68p0G885X7gRo32oxxeEeA08Ys&e=3D>)

          =C2=A0=C2=A0=C2=A0 They then use the draft cavage spec to sign a =
defined set
          of
          

          =C2=A0=C2=A0=C2=A0 headers which includes the date and digest hea=
ders..
          

          

          =C2=A0=C2=A0=C2=A0 > If you want attestation, better to use SE=
T or plain
          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 AP=
Is harder 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 =
having
          signatures
          

          =C2=A0=C2=A0=C2=A0 in headers. I like the idea of using content n=
egotiation
          to allow
          

          =C2=A0=C2=A0=C2=A0 clients to request either application/json or
          application/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-e=
rdtman-jose-cleartext-jws-00
          

          =C2=A0=C2=A0=C2=A0
<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-=
3A__tools.ietf..org_html_draft-2Derdtman-2Djose-2Dcleartext-=
2Djws-2D00&d=3DDwMFaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e=
apI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
=3D_ipDvDLnPDvRc4f-nizqhqic-6zojUcwkws7Fel97CU&s=3D0G1ikcDnNz=
vZqp7w6xlLnfhtq6GZGc0HlswqLcp4OK4&e=3D>.

          =C2=A0=C2=A0=C2=A0 As Ben mentioned, does the issue of JSON canon=
icalization
          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
<http://www.google.com/url?q=3Dhttp%3A%2F%2=
Fmoneyhubenterprise.com%2F&sa=3DD&sntz=3D1&usg=3DAFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>

        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 Financ=
ial
        Technology is entered on the Financial Services Register (FRN
        809360) at fca.org.uk/register
        <=
http://fca.org.uk/register>. Moneyhub=C2=A0Financial
        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


    

    

  



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--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

On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman <=
;samuel@erdtman.se> wrote:
Hi

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.
On Wed, 5 Sep =
2018 at 15:54, Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
Hi Samuel,

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

On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman <samuel@erdtman.se> wrote:
=

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: 
From: Dave Tonge 
Date: Wed, 5 Sep 2018 16:51:54 +0200
Message-ID: 
To: James.H.Manger@team.telstra.com
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000009eba057520eb5d"
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:52:20 -0000

--000000000000009eba057520eb5d
Content-Type: text/plain; charset="UTF-8"

Thanks James - definitely an interesting case.
I'd be sorry to see ACME and other APIs go down the route of POSTing base64
encoded blobs for all API interactions.


On Mon, 3 Sep 2018 at 14:56, Manger, James 
wrote:

> ACME 
> (Automatic Certificate Management Environment) [draft-ietf-acme-acme] (eg
> Lets Encrypt CA) is an interesting case. It POSTs JWS objects using the
> Flattened JSON Serialization with a "url" member in the protected header.
> It is likely to use the same scheme (POST a JWS) to replace GET methods as
> well.
>
>
>
> --
>
> James Manger
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000009eba057520eb5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks James - definitely an interesting case.=C2=A0
=

=
I'd be sorry to see ACME and other APIs go down the route of POSTing ba=
se64 encoded blobs for all API interactions.


On Mon, 3 Sep 2018 at 14:56, Manger, Jame=
s <James.H.Manger@tea=
m.telstra.com> wrote:











ACME (Automatic =
Certificate Management Environment) [draft-ietf-acme-acme]
 (eg Lets Encrypt CA) is an interesting case. It POSTs JWS objects using th=
e Flattened JSON Serialization with a "url" member in the protect=
ed header. It is likely to use the same scheme (POST a JWS) to replace GET =
methods as well.


=C2=A0




--


James Manger




=C2=A0






_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth







--000000000000009eba057520eb5d--


From nobody Wed Sep  5 08:30:16 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 8D2D9126CC7 for ; Wed,  5 Sep 2018 08:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6Zq56L2rQIWD for ; Wed,  5 Sep 2018 08:29:59 -0700 (PDT)
Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 E2B901252B7 for ; Wed,  5 Sep 2018 08:29:58 -0700 (PDT)
Received: by mail-it0-x241.google.com with SMTP id f14-v6so10454499ita.4 for ; Wed, 05 Sep 2018 08:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:date:message-id:subject:to; bh=2M1zgX+GCOYA8pNmNXaUunk7i47rU/Oy9uNZenj6sh4=; b=FXAOptX7ffIWDtA3g4YzFMywLysmnL5YzAcDoSztpxYdsc8Ak7HXuLlke1l/DtsKIV UUfHZegRNgGIV5PlvDwj/F93qZDF0dRxYBaCGvkA1zc2E3QJaefnGNSgaj2EAqNbbabX LS2iVFmTX1DDRsEgtG7wJBPil+lo2s0JFpA8V/HgM4PN1e65pIyUUIn7kr1L8izVv4yF mSBUyVMhZ4NKGA7Y+2TPo68l1aR14rh6xf9dfn+gf6wiNgk87pdbVlLnOyAfDdY2ngG/ pT3Q3s3Yyz/bhyh8ehTbGUOIZ9XtoXG4gas92LHlusVac59DnCPEHmY/a1FC1p7qSvR/ xxLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=2M1zgX+GCOYA8pNmNXaUunk7i47rU/Oy9uNZenj6sh4=; b=r32LO7KxYZmDbPyEz02CzvedmaSUS9DwYFmAwc2ngafhUaUHGjOylEENNvA90LPoct ChLiVma18qyhyv+GP3Q6z1EEJrT37hZWk0dC0wA+q15kpcvj21gBIFdd3DkujYU+xyQw I1bBJcbb4bdtckRT9FU1HYnQOawdKa756CBs6ZoIijogxxanG8kUVTX3bu8hWceytA4U 8UzPo+fxRhGA6s638CFhb+V+SDen4mB/1Ml20oRgt4FToncNQArZ1Ikle8fKnH/frtmK LhM6gcPOqbkY5L0o7WZk/Tp9LRycVlJ3yPwLHkVU6TJZZqkzNMMI20CPeTIaScAuZJyu 8p+Q==
X-Gm-Message-State: APzg51Di/TAih8e0baDt/dTGGYx5fCMyd9J27Nw9RujS1U2PNOcna6/g Bzgu9oU3MSznp6HdGT8PYjZVe2uAL5oCdcBDVImOFA==
X-Google-Smtp-Source: ANB0VdZTGy+5lhsfYN4xfXf3M9ELSWmqQW3DbjzIJ5zfYKhI2Yq2kK/o9k/5cgueuCb+bh4kFaoZ6gI80Xz3FVac80c=
X-Received: by 2002:a02:2b12:: with SMTP id h18-v6mr27126458jaa.10.1536161397908;  Wed, 05 Sep 2018 08:29:57 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 5 Sep 2018 11:29:57 -0400
From: Ron Alleva 
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Wed, 5 Sep 2018 11:29:57 -0400
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000070ab8e05752172d9"
Archived-At: 
Subject: [OAUTH-WG] Mobile Native apps and renewing access tokens
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 15:30:01 -0000

--00000000000070ab8e05752172d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

I was looking around for guidance around how to refresh access tokens on
native mobile experiences.

Suppose we=E2=80=99re using a normal OAuth auth code flow with a mobile app=
 (Chrome
custom tabs/ASWebAuthenticationSession and all). Also, want to reduce the
interruptions to the end user.

In general, it seems like refresh token is not the tool for the job, as it
generally implies offline_access, when the user is not there. So if the
user signed out of their identity provider, I would not want them to be
able to get a new access token.

Via normal web flow, the =E2=80=9Cprompt=3Dnone=E2=80=9D ability is availab=
le (called Silent
Authentication by Auth0), so the refresh can be done in the background,
without ever bothering the user at all if they are still logged in. I don=
=E2=80=99t
think this is possible with a chrome custom tab or iOS equivalent, even if
the user never needs to enter their password.

Is there some type of similar flow for native mobile applications? It seems
like most of the suggestions out there refer to just using the refresh
tokens. Also, another note, SMART on FHIR seems to introduce the concept of
=E2=80=9Conline_access=E2=80=9D, which seems to indicate a refresh token th=
at is tied to an
authentication session. That also seems interesting to me.

So anyway, is there any general guidance? Is everyone just using refresh
tokens? Some combination of long access tokens and longer web
authentication sessions?

Thanks in advance,

Ron

--00000000000070ab8e05752172d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Hi all,

I was looking around for guidance=
 around how to refresh access tokens on native mobile experiences.=C2=A0

Suppose we=E2=80=99re u=
sing a normal OAuth auth code flow with a mobile app (Chrome custom tabs/AS=
WebAuthenticationSession and all). Also, want to reduce the interruptions t=
o the end user.=C2=A0

In general, it seems like refresh token is not the tool for the job, as it=
 generally implies offline_access, when the user is not there. So if the us=
er signed out of their identity provider, I would not want them to be able =
to get a new access token.

Via normal web flow, the =E2=80=9Cprompt=3Dnone=E2=80=9D ability is a=
vailable (called Silent Authentication by Auth0), so the refresh can be don=
e in the background, without ever bothering the user at all if they are sti=
ll logged in. I don=E2=80=99t think this is possible with a chrome custom t=
ab or iOS equivalent, even if the user never needs to enter their password.=


Is there some type o=
f similar flow for native mobile applications? It seems like most of the su=
ggestions out there refer to just using the refresh tokens. Also, another n=
ote, SMART on FHIR seems to introduce the concept of =E2=80=9Conline_access=
=E2=80=9D, which seems to indicate a refresh token that is tied to an authe=
ntication session. That also seems interesting to me.

So anyway, is there any general guidance? =
Is everyone just using refresh tokens? Some combination of long access toke=
ns and longer web authentication sessions?

Thanks in advance,

Ron


--00000000000070ab8e05752172d9--


From nobody Wed Sep  5 09:13:45 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 9247F1277C8 for ; Wed,  5 Sep 2018 09:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wework.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 aXIbxK02xIl5 for ; Wed,  5 Sep 2018 09:13:41 -0700 (PDT)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 E43F31277BB for ; Wed,  5 Sep 2018 09:13:40 -0700 (PDT)
Received: by mail-io0-x241.google.com with SMTP id q5-v6so6427986iop.3 for ; Wed, 05 Sep 2018 09:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wework.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x8+OUoD5Ft0bO+MBScp3KLoBh3xuGDUJxWuCZ0eXAlc=; b=Srpe/HipF0/VLIGRbIOK476yTVsU80rvjonwuxBmAC4tq49GRiu0vPPzIA+ta/hpbO XZ3YEK19YM8bL188HDciYwED3hijH2rAvO30/3D/AFC+H4Uv22BCtSpkHcpExz8lDbHx g9sgK8Dcr4CU0ugweSmpxeEaKuXryIGVhrJ80R8cf1jdwa74RiIDPqmq3I51qW+nySuM FnW8M1urblmceNPZlUfd/ZRM7rhU0TwnnIAzGUlxjI8b7eGjaXp1jxx+o0M8jY8KL/ko dd3JK1/pq8CfzfDW8aCclHGLL0FOnU6L7wAJAYYs4l/mGW0Mvu9k6iLKT2IFULpQEHY5 doRQ==
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=x8+OUoD5Ft0bO+MBScp3KLoBh3xuGDUJxWuCZ0eXAlc=; b=R2DShKPtDGnJcI+xBlawF/yCJjvR9u+M3rnW9l9UnIQICsRorWjbiKRlwpk80i60Ij 5rIVAXlaB19MPuZnU7h25X+H6vBGFm6UENOCdJQZeQ++5IlUCBjFCwnnTQkaf9rSzCxr OLNYfOJBFu8Zv7pFQbatUsUehux5tgWssAkBPsLe4eO+omQilByAK0qQaNTl1IGcSvNg qV564RSTt8uxC5GKjqPA6oz2QXd3eSMOAnE4OXZgXoXR7AEJts2q+c0y2V0KY7jYjzOy NBhqcu49rNTIry2TZr805CoDUHLuREKmwLM0IRO8e5XJuIcR9YkysAXX5SJpg9UBbkoS TcBw==
X-Gm-Message-State: APzg51B6Re/ouFdUPRO9bgWoBQnzKW6Xd46oHJ9nYzmiz3sQuy4H84Hr VltB5BC9GJgVyOABPZeGuuEXMlGvUJ4Jo4TzQ0VH+g==
X-Google-Smtp-Source: ANB0VdaGocar+JStzwOtfAboFmPhvzAHvr62LBA7n0yBLubcATtfUD2v70aZKte3BGQm5ZogHyTIB0u7zMq5tDeE4J0=
X-Received: by 2002:a6b:a188:: with SMTP id k130-v6mr26270786ioe.128.1536164020119;  Wed, 05 Sep 2018 09:13:40 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Iain McGinniss 
Date: Wed, 5 Sep 2018 09:13:27 -0700
Message-ID: 
To: Ron Alleva 
Cc: oauth@ietf.org, William Denniss 
Content-Type: multipart/alternative; boundary="000000000000bc91e20575220eb8"
Archived-At: 
Subject: Re: [OAUTH-WG] Mobile Native apps and renewing access tokens
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 16:13:44 -0000

--000000000000bc91e20575220eb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, I'm the maintainer of AppAuth-Android, I've also cc'd William Denniss,
the maintainer of AppAuth-iOS and the author of the OAuth2 for Native Apps
BCP (BCP 212).

We recommend using the code flow to get a refresh token in order to
transparently acquire new access tokens as required, along with some other
recommendations in the BCP. There isn't a feasible alternative within the
spec for mobile apps, as repeatedly surfacing a browser tab is too
disruptive to the UX, and using an embedded web view is bad security
practice.

Whether the refresh token is "bound" to the lifetime of some other
revocable session is implementation specific, but if that implementation is
under your control you could tie the validity of the refresh token to that
of a web auth cookie, how recently it has been used, etc. There is no
reliable way of detecting browser state within an app without the user
interacting with a browser tab, unfortunately.

On Wed, Sep 5, 2018, 08:30 Ron Alleva  wrote:

> Hi all,
>
> I was looking around for guidance around how to refresh access tokens on
> native mobile experiences.
>
> Suppose we=E2=80=99re using a normal OAuth auth code flow with a mobile a=
pp
> (Chrome custom tabs/ASWebAuthenticationSession and all). Also, want to
> reduce the interruptions to the end user.
>
> In general, it seems like refresh token is not the tool for the job, as i=
t
> generally implies offline_access, when the user is not there. So if the
> user signed out of their identity provider, I would not want them to be
> able to get a new access token.
>
> Via normal web flow, the =E2=80=9Cprompt=3Dnone=E2=80=9D ability is avail=
able (called Silent
> Authentication by Auth0), so the refresh can be done in the background,
> without ever bothering the user at all if they are still logged in. I don=
=E2=80=99t
> think this is possible with a chrome custom tab or iOS equivalent, even i=
f
> the user never needs to enter their password.
>
> Is there some type of similar flow for native mobile applications? It
> seems like most of the suggestions out there refer to just using the
> refresh tokens. Also, another note, SMART on FHIR seems to introduce the
> concept of =E2=80=9Conline_access=E2=80=9D, which seems to indicate a ref=
resh token that is
> tied to an authentication session. That also seems interesting to me.
>
> So anyway, is there any general guidance? Is everyone just using refresh
> tokens? Some combination of long access tokens and longer web
> authentication sessions?
>
> Thanks in advance,
>
> Ron
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000bc91e20575220eb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, I'm the maintainer of AppAuth-Android, I've a=
lso cc'd William Denniss, the maintainer of AppAuth-iOS and the author =
of the OAuth2 for Native Apps BCP (BCP 212).

We recommend using the code flow to get a refresh token in o=
rder to transparently acquire new access tokens as required, along with som=
e other recommendations in the BCP. There isn't a feasible alternative =
within the spec for mobile apps, as repeatedly surfacing a browser tab is t=
oo disruptive to the UX, and using an embedded web view is bad security pra=
ctice.

Whether the refre=
sh token is "bound" to the lifetime of some other revocable sessi=
on is implementation specific, but if that implementation is under your con=
trol you could tie the validity of the refresh token to that of a web auth =
cookie, how recently it has been used, etc. There is no reliable way of det=
ecting browser state within an app without the user interacting with a brow=
ser tab, unfortunately.

On Wed, Sep 5, 2018, 08:30 Ron Alleva <ronallevatech@gmail.com> wrote:
Hi all,

I was looking around for guida=
nce around how to refresh access tokens on native mobile experiences.=C2=A0=


Suppose we=E2=80=99re using a normal OAuth auth code=
 flow with a mobile app (Chrome custom tabs/ASWebAuthenticationSession and =
all). Also, want to reduce the interruptions to the end user.=C2=A0

In general, it seems like refresh token is not the tool for t=
he job, as it generally implies offline_access, when the user is not there.=
 So if the user signed out of their identity provider, I would not want the=
m to be able to get a new access token.

Via normal web=
 flow, the =E2=80=9Cprompt=3Dnone=E2=80=9D ability is available (called Sil=
ent Authentication by Auth0), so the refresh can be done in the background,=
 without ever bothering the user at all if they are still logged in. I don=
=E2=80=99t think this is possible with a chrome custom tab or iOS equivalen=
t, even if the user never needs to enter their password.

=

Is there some type of similar flow for native mobile applications? It se=
ems like most of the suggestions out there refer to just using the refresh =
tokens. Also, another note, SMART on FHIR seems to introduce the concept of=
 =E2=80=9Conline_access=E2=80=9D, which seems to indicate a refresh token t=
hat is tied to an authentication session. That also seems interesting to me=
.

So an=
yway, is there any general guidance? Is everyone just using refresh tokens?=
 Some combination of long access tokens and longer web authentication sessi=
ons?

Thanks in advance,

Ron
=


_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

https://www.ietf.org/mailman/listinfo/oauth



--000000000000bc91e20575220eb8--


From nobody Wed Sep  5 10:42:58 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 26236130DDA for ; Wed,  5 Sep 2018 10:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, 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 (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 VNhDPRlcYKwN for ; Wed,  5 Sep 2018 10:42:55 -0700 (PDT)
Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (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 7E199130DE2 for ; Wed,  5 Sep 2018 10:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1536169374; bh=jgcmobH2E+cN6IvpnFONdMBADQGZmeM+l+vM9q/EyE0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=iwDtVotkQQ9mZh+CjkljzPT5MFHhnemt3DC6+oLTMWa0pfSl3EkiBXuD6g4XkZilIEsjurBT5lOtOCDijdMVwo7FCphrXbf6kxOubXTDmBqbW5/WJ19lmUk5F/5Uv3AKECI+fMCcolTVmSZ5457uGFVHHyyYUtRliao+V/hjtatF4jbtmRtmRuYD3O6ILzRS5vM122bAI7gisjdogwjWNnl37d/x/4XK8cBirEd5Eb5w+8GGsdDqVvpcTEf1rlzVwm4/7R7nVXJcAMNPv2BoZjVbO6CvrIofpMRvdrU+MRIIETBlxZ4JRoJWreahKodSmwRGFCBNac8Gg4WAj6JAuw==
X-YMail-OSG: Mmkl_OgVM1mMBdRawbc0b7yj_knMNpE7wFDiLXXaBJz.EnXbSB13nfl8Qh2CbYw fRt460KkK0bOHOUelCXsG1JFg2PM7sbIjSDyxPuZ3tUtljQF.j9_ww1LXetXwPKIoV910wU1qg.h mkhXUPi0GK4I7xPKkKDgUB3WUK0UxZXH3LYcVIN5w8oJi8BY3200gL54lOQzuzSdaETdA9P39KZf PIdqJaxYvyoeXnEZdCJeN8VK1v0fjiwNeM2uOM.STyekcvEoJR2RdmrlKDtT93mhvuTDeMwHtnHq IF3RHDHyWnu4GfF3iwj_65ESj9TAxViA1HwDRtfRrIQeaxjAK_GpMG0mO0JxLWma6ZOC6q8q2zC7 3SgGJIOrRb5DTi2kWuTW0QMhY89qFb1zpMP0E5qBwjF7BO41l_7mpUQb_K36VYRJUFKBjpTnG.Oc da2ZfrHd5KxjENY13vcF5iIJOy6SOjKbZZbzqWJBZzRvnda4ZeIQXzp9I7_x7Gks0duSlJZKqfgv NDYutb98UtXWmIrsXfi6lYGpuX8DURG0UR3tD4hm3ReuyBJ60RfPBscIdgu4rLFk.u8Aj0XwniXR RM6h7D0UN82WFdWMh_5CvSQubQ3lrDwzAg9DHb_BcsPG1ZQNYpFA3hIaKNOdNSOHPrYSc7Ot.s47 l75wFMREOpO.sqI__S5CVRXOw02aZ2DjGDzaR5PsQdZRkqtiBTqU1Xu_hrE0w7vkCAVMymXwlKxj RrKUL7DlzV32uQAhnARAsHeWf4bFCJuHt94xPB2MxEniEjAQ0QKvwOkG1wsn.FqX.OR1GHt9ovJB mTSqPd94_Ws8Pg5a4lGFHMmHhdGLkRO7XAC9sTzeVB9BFidUe7KobIrK.lLoUaTSY10tbLE2Gtq3 VUnwoVFuTkm.pWAsnlAnJ1YppVZohzgtjMgyJEf.hH7fDv4o4S6qHyvSG8CM5dJKxBo3A7v8scN6 d_LsXWPOluErYIxQ5q5JHlcWDkUfYHA_Nx89Pb9aZNTA.fsDa3W41dACclWagiZniPIGZGRRvmSL YiE2Sf1E-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 5 Sep 2018 17:42:54 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 34e0863f3e3d703e8c3c75a8fa653dde;  Wed, 05 Sep 2018 17:42:52 +0000 (UTC)
To: Iain McGinniss , Ron Alleva 
Cc: oauth@ietf.org
References:  
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Wed, 5 Sep 2018 13:42:51 -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="------------BC164213B991ABB076E40E74"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Mobile Native apps and renewing access tokens
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 17:42:58 -0000

This is a multi-part message in MIME format.
--------------BC164213B991ABB076E40E74
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I second the suggestion to use refresh_tokens even in an "online_access" 
model. You are correct that most Authorization Servers will grant 
offline_access to mobile apps because that produces a better user 
experience. However, if your requirements prohibit granting 
offline_access to the mobile app that doesn't preclude you from using 
refresh_tokens. Instead, the refresh_token is bound to a server side 
session and when the mobile app makes a refresh_token request and the 
server side session has expired, the refresh_token request fails and the 
mobile app knows it needs to ask the user to re-authenticate.

If tracking server-side sessions is a problem, you can also have the 
Authorization Server issue time-bound refresh_tokens (i.e. the 
refresh_token is only good for 90 minutes). The mobile app then 
refreshes it's access token as often as it needs until the refresh token 
flow fails at which point the mobile app asks the user to re-authenticate.

Hope that helps,
George

On 9/5/18 12:13 PM, Iain McGinniss wrote:
> Hi, I'm the maintainer of AppAuth-Android, I've also cc'd William 
> Denniss, the maintainer of AppAuth-iOS and the author of the OAuth2 
> for Native Apps BCP (BCP 212).
>
> We recommend using the code flow to get a refresh token in order to 
> transparently acquire new access tokens as required, along with some 
> other recommendations in the BCP. There isn't a feasible alternative 
> within the spec for mobile apps, as repeatedly surfacing a browser tab 
> is too disruptive to the UX, and using an embedded web view is bad 
> security practice.
>
> Whether the refresh token is "bound" to the lifetime of some other 
> revocable session is implementation specific, but if that 
> implementation is under your control you could tie the validity of the 
> refresh token to that of a web auth cookie, how recently it has been 
> used, etc. There is no reliable way of detecting browser state within 
> an app without the user interacting with a browser tab, unfortunately.
>
> On Wed, Sep 5, 2018, 08:30 Ron Alleva  > wrote:
>
>     Hi all,
>
>     I was looking around for guidance around how to refresh access
>     tokens on native mobile experiences.
>
>     Suppose we’re using a normal OAuth auth code flow with a mobile
>     app (Chrome custom tabs/ASWebAuthenticationSession and all). Also,
>     want to reduce the interruptions to the end user.
>
>     In general, it seems like refresh token is not the tool for the
>     job, as it generally implies offline_access, when the user is not
>     there. So if the user signed out of their identity provider, I
>     would not want them to be able to get a new access token.
>
>     Via normal web flow, the “prompt=none” ability is available
>     (called Silent Authentication by Auth0), so the refresh can be
>     done in the background, without ever bothering the user at all if
>     they are still logged in. I don’t think this is possible with a
>     chrome custom tab or iOS equivalent, even if the user never needs
>     to enter their password.
>
>     Is there some type of similar flow for native mobile applications?
>     It seems like most of the suggestions out there refer to just
>     using the refresh tokens. Also, another note, SMART on FHIR seems
>     to introduce the concept of “online_access”, which seems to
>     indicate a refresh token that is tied to an authentication
>     session. That also seems interesting to me..
>
>     So anyway, is there any general guidance? Is everyone just using
>     refresh tokens? Some combination of long access tokens and longer
>     web authentication sessions?
>
>     Thanks in advance,
>
>     Ron
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------BC164213B991ABB076E40E74
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I second the suggestion to
      use refresh_tokens even in an "online_access" model. You are
      correct that most Authorization Servers will grant offline_access
      to mobile apps because that produces a better user experience.
      However, if your requirements prohibit granting offline_access to
      the mobile app that doesn't preclude you from using
      refresh_tokens. Instead, the refresh_token is bound to a server
      side session and when the mobile app makes a refresh_token request
      and the server side session has expired, the refresh_token request
      fails and the mobile app knows it needs to ask the user to
      re-authenticate.

      

      If tracking server-side sessions is a problem, you can also have
      the Authorization Server issue time-bound refresh_tokens (i.e. the
      refresh_token is only good for 90 minutes). The mobile app then
      refreshes it's access token as often as it needs until the refresh
      token flow fails at which point the mobile app asks the user to
      re-authenticate.

      

      Hope that helps,

      George

    

    
On 9/5/18 12:13 PM, Iain McGinniss
      wrote:

    

    

      
      
Hi, I'm the maintainer of AppAuth-Android, I've
        also cc'd William Denniss, the maintainer of AppAuth-iOS and the
        author of the OAuth2 for Native Apps BCP (BCP 212).
        


        

        
We recommend using the code flow to get a
          refresh token in order to transparently acquire new access
          tokens as required, along with some other recommendations in
          the BCP. There isn't a feasible alternative within the spec
          for mobile apps, as repeatedly surfacing a browser tab is too
          disruptive to the UX, and using an embedded web view is bad
          security practice.

        


        

        
Whether the refresh token is "bound" to the
          lifetime of some other revocable session is implementation
          specific, but if that implementation is under your control you
          could tie the validity of the refresh token to that of a web
          auth cookie, how recently it has been used, etc. There is no
          reliable way of detecting browser state within an app without
          the user interacting with a browser tab, unfortunately.

      

      

      

        
        

          

            
Hi
              all,

            


            

            
I
              was looking around for guidance around how to refresh
              access tokens on native mobile experiences. 

            


            

            
Suppose
              we’re using a normal OAuth auth code flow with a mobile
              app (Chrome custom tabs/ASWebAuthenticationSession and
              all). Also, want to reduce the interruptions to the end
              user. 

            


            

            
In
              general, it seems like refresh token is not the tool for
              the job, as it generally implies offline_access, when the
              user is not there. So if the user signed out of their
              identity provider, I would not want them to be able to get
              a new access token.

            


            

            
Via
              normal web flow, the “prompt=none” ability is available
              (called Silent Authentication by Auth0), so the refresh
              can be done in the background, without ever bothering the
              user at all if they are still logged in. I don’t think
              this is possible with a chrome custom tab or iOS
              equivalent, even if the user never needs to enter their
              password.

            


            

            
Is
              there some type of similar flow for native mobile
              applications? It seems like most of the suggestions out
              there refer to just using the refresh tokens. Also,
              another note, SMART on FHIR seems to introduce the concept
              of “online_access”, which seems to indicate a refresh
              token that is tied to an authentication session. That also
              seems interesting to me..

            


            

            
So anyway,
              is there any general guidance? Is everyone just using
              refresh tokens? Some combination of long access tokens and
              longer web authentication sessions?

            


            

            
Thanks
              in advance,

            


            

            
Ron

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mailman/listinfo/oauth

        

      

      

      

      

      
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


    

    

  


--------------BC164213B991ABB076E40E74--


From nobody Wed Sep  5 15:10:49 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 E8C99127332 for ; Wed,  5 Sep 2018 15:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 H53A61cp7p9x for ; Wed,  5 Sep 2018 15:10:46 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 DEC8D130DCC for ; Wed,  5 Sep 2018 15:10:45 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id d10-v6so12098897itj.5 for ; Wed, 05 Sep 2018 15:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W6eeNwhVeMySwwzii0Tp4F9O9U/TRS4JPHfYIWjnris=; b=e2QS8ggEXd1QOdvOVnRPUfc1KnSVAM+HEIeX1hdWcBCeEJiQIc+Zgs4ljG4801iSfR j5aTYlUj1xwhMosVX3LQgiZgP9H+Lu502wEPUQyJvl9WvqqCqw85afnqfvG/+5+seMEy GMswkuPdNr5ltEfUl3QEdXLcjyxHUysKC9p6M=
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=W6eeNwhVeMySwwzii0Tp4F9O9U/TRS4JPHfYIWjnris=; b=RDLpu53dpMNs4pOI5l1O51XaCCSMLPq/z+tYX+OQB9kmVV40KDNmrIBhZko/1OYE5s X4G7nZm9zMnEsdok0UWi4Qxb3pYCp5YDrysptObOsuGUHLPrvUMCvdV80aAnSYSrHLea EP4Xw2Ria0P5zXCJuBrDCRGl/xKwQSGkQf2aL5/ym6lSJF301EEgQ40lg/ekiruwScx/ VVZQSWfc+7Tz/y/L78aIw9idoGfhFKMFBFpGVHzITTdZHcqyW+Rfh4is5838yOvj5Jgk 64VlhoWqvL/+Trva27W+7bLCwbZvtLhh+VHF+XFtYoJC5BLWbRtBd91iGedT5SyCvCOi cTaA==
X-Gm-Message-State: APzg51AWFE++CeTRa4rfmFOLTs/7lU7WtaFxW4TywcER8u//v2eg7Qo4 zCc5AAo49iDm2Q74X+PR16YwHFAuxQOBRgdA0reKgo/4Gk3qD7MrX7pBxmvbip/gmnFYFhYC1zW +WbJDFohrb4eqxA==
X-Google-Smtp-Source: ANB0VdaBY8SpmCiPKmXCeHcYiWn0IeNJsZ54Or5wzn+kpMmZS+519eLKLCJjPXcgsxIkQI9MkIebvsK7AHzI9oGUolA=
X-Received: by 2002:a24:4703:: with SMTP id t3-v6mr412624itb.54.1536185445054;  Wed, 05 Sep 2018 15:10:45 -0700 (PDT)
MIME-Version: 1.0
References: <153335394820.18507.18435740800535187975@ietfa.amsl.com> <32ca6f57-553d-9255-c2be-11e21b678c93@aol.com>
In-Reply-To: <32ca6f57-553d-9255-c2be-11e21b678c93@aol.com>
From: Brian Campbell 
Date: Wed, 5 Sep 2018 16:10:18 -0600
Message-ID: 
To: George Fletcher 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000c31a6b0575270b0d"
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt
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 22:10:48 -0000

--000000000000c31a6b0575270b0d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the review, George. I'll add some more color to the text around
the RFC 6749 references/links so one can know what they are without having
to follow the reference (or have RFC 6749 memorized :)).  And adding some
more guidance/discussion about the interplay of scope and resource is
already on my todo list for the next revision based on feedback/requests
from several other folks. The content of the draft is long overdue for some
updates but I just haven't had the chance to do the work yet. I don't think
there's anything that precludes using a logical URI for a resource but I
think the text should be focused on the nominal case of the resource
indicating the location of the resource.







On Thu, Aug 30, 2018 at 1:00 PM George Fletcher  wrote:

> Comments...
>
> I found the following paragraph a little confusing:
>
>    When an access token will be returned from the authorization
>    endpoint, the "resource" parameter is used in the authorization
>    request to the authorization endpoint as defined in Section 4.2.1  of
>    OAuth 2.0 [RFC6749 ].  An example=
 of an authorization request where
>    the client tells the authorization server that it wants a token for
>    use at "https://rs.example.com/"  is shown in=
 Figure 1 below.
>
> I don't have RFC 6749 memorized to the level of section numbers:) I would=
 recommend calling out that for the co
>
> I don't have RFC 6749 memorized to the level of section numbers so it too=
k
> a bit to realize you were talking about Implicit and "Hybrid" flows.
> Suggested text addition...
>
>    When an access token will be returned from the authorization
>    endpoint (such as the Implicit flow [Section 4.2.1  of
>    OAuth 2.0 [RFC6749 ]]), the "reso=
urce" parameter is used in the authorization
>    request to the authorization endpoint.  For OAuth flows that only retu=
rn an
>    access token from the token endpoint, the resource parameter MUST NOT =
be
>    used in the authorization request. An example of an authorization requ=
est where
>    the client tells the authorization server that it wants a token for
>    use at "https://rs.example.com/"  is shown in=
 Figure 1 below.
>
>
> Or something like that.
>
> Also, should there be some discussion regarding using logical URIs for
> resources rather than requiring a specific physical path? The AS can alwa=
ys
> translate the resource URI to a physical endpoint if necessary.
>
> Finally, should we define more guidance on the separate of scopes and
> resource indicators? For example, for an instant messaging services there
> might be scopes of "sendIM", "readBuddyList", "adminAccount". And then th=
e
> resource indicator might be https://api.im.example.com. Given the client
> is requesting a token with a scope of "sendIM" is it really necessary to
> also specify a resource indicator of "https://api.im.example.com"
>  as the AS could probably infer that from the
> scope parameter.
>
> Thanks,
> George
>
> On 8/3/18 11:39 PM, 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
>
>
>
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000c31a6b0575270b0d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the review, Geo=
rge. I'll add some more color to the text around the RFC 6749 reference=
s/links so one can know what they are without having to follow the referenc=
e (or have RFC 6749 memorized :)).=C2=A0 And adding some more guidance/disc=
ussion about the interplay of scope and resource is already on my todo list=
 for the next revision based on feedback/requests from several other folks.=
 The content of the draft is long overdue for some updates but I just haven=
't had the chance to do the work yet. I don't think there's any=
thing that precludes using a logical URI for a resource but I think the tex=
t should be focused on the nominal case of the resource indicating the loca=
tion of the resource. =C2=A0 
<=
div>




<=
div>

On Thu, Aug 30, 2018 at 1:00 PM George Fletche=
r <gffletch@aol.co=
m> wrote:

 =20
   =20
 =20
  

    Comments...

    

    I found the following paragraph a little confusing:

    
   When an access token will be returned from the authorization
   endpoint, the "resource" parameter is used in the authorizatio=
n
   request to the authorization endpoint as defined in Section 4.2.1 of
   OAuth 2.0 [RFC6749].  An example of an authorization request where
   the client tells the authorization server that it wants a token for
   use at "https://rs.example.com/" is shown in Figure 1 below.

I don't have RFC 6749 memorized to the level of section numbers:) I wou=
ld recommend calling out that for the co


    I don't have RFC 6749 memorized to the level of section numbers so
    it took a bit to realize you were talking about Implicit and
    "Hybrid" flows. Suggested text addition...

    

    
   When an access token will be returned from the authorization
   endpoint (such as the Implicit flow [Section 4.2.1 of
   OAuth 2.0 [RFC6749]]), the "resource" parameter is used in the authorization
   request to the authorization endpoint.  For OAuth flows that only return=
 an
   access token from the token endpoint, the resource parameter MUST NOT be=
=20
   used in the authorization request. An example of an authorization reques=
t where
   the client tells the authorization server that it wants a token for
   use at "https://rs.example.com/" is shown in Figure 1 below.
 =20


    Or something like that.

    

    Also, should there be some discussion regarding using logical URIs
    for resources rather than requiring a specific physical path? The AS
    can always translate the resource URI to a physical endpoint if
    necessary.

    

    Finally, should we define more guidance on the separate of scopes
    and resource indicators? For example, for an instant messaging
    services there might be scopes of "sendIM", "readBuddyLi=
st",
    "adminAccount". And then the resource indicator might be
    ht=
tps://api.im.example.com. Given the client is requesting a token
    with a scope of "sendIM" is it really necessary to also speci=
fy a
    resource indicator of "https://api.im.example.com" as the AS co=
uld
    probably infer that from the scope parameter.

    

    Thanks,

    George

    

    
    
On 8/3/18 11:39 PM,
      internet-drafts@ietf.org wrote:

    

    

      
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
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



    

    

  







<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000c31a6b0575270b0d--


From nobody Wed Sep  5 22:09:56 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 4865612F1AB for ; Wed,  5 Sep 2018 22:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hHYseeScaQLz for ; Wed,  5 Sep 2018 22:09:53 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEDE129C6A for ; Wed,  5 Sep 2018 22:09:53 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:15ad:a721:fe50:59e6] (unknown [IPv6:2601:282:202:b210:15ad:a721:fe50:59e6]) by alkaline-solutions.com (Postfix) with ESMTPSA id BEDC331685; Thu,  6 Sep 2018 05:09:51 +0000 (UTC)
From: David Waite 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_E396ECB4-DAD2-4E5F-91B8-99F2E1B3F4E4"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 5 Sep 2018 23:09:50 -0600
In-Reply-To: 
Cc: oauth@ietf.org
To: Ron Alleva 
References: 
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [OAUTH-WG] Mobile Native apps and renewing access tokens
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: Thu, 06 Sep 2018 05:09:55 -0000

--Apple-Mail=_E396ECB4-DAD2-4E5F-91B8-99F2E1B3F4E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The offline_access scope is defined as part of OpenID Connect, not as =
part of OAuth. There is no requirement that offline_access scope be the =
only way to have a refresh token issued, although some implementations =
have chosen to do this. My interpretation is that the offline_access is =
a partial misnomer - the user is only =E2=80=98offline=E2=80=99 in the =
sense of whether they currently have an authenticated session with the =
IDP.

The reason many OIDC implementations try to not return refresh tokens is =
that they want to have all authentication decisions flow through the =
user agent as potentially interactive. You can track user authentication =
within a refresh token, but this adds complications such as requiring =
persistent state within the application.

The question is whether your app cares about current user authentication =
at the IDP. If your application either:
- Uses IDP authentication more as a registration/account recovery to a =
local application account
- Doesn=E2=80=99t care about IDP authentication but is just using the =
token for authorization purposes

Then there isn=E2=80=99t a reason to go back through the web-based =
authentication process. Just do what you need to get a refresh token =
within the TOS of the IDP and go with that.

IMO, the value of knowing active IDP authentication is reduced for =
mobile use cases, because (rightly or wrongly) users are expected to =
control access to the native applications through screen locks, =
passcodes, and biometrics. The primary user authentication is local and =
implicit in being able to open the app. The UX expectation is that =
further authentication challenges by remote services are to be done only =
as needed for their own CYA.

If however you do want to rely on the IDP authentication, you=E2=80=99ll =
need to play within the process of the IDP chosen. Don=E2=80=99t request =
offline access, hope they give you a refresh token to use, and if not =
you=E2=80=99ll be popping up a browser pane (with a user consent on iOS =
11+) every time the access token expires so the IDP can determine if the =
authentication still holds.

And hope in the future that in the absence of offline_access, the IDP =
give a refresh token tracking the user authentication session, in order =
to reduce the frequency users are sent through that browser pane.

-DW

> On Sep 5, 2018, at 9:29 AM, Ron Alleva  =
wrote:
>=20
> Hi all,
>=20
> I was looking around for guidance around how to refresh access tokens =
on native mobile experiences.=20
>=20
> Suppose we=E2=80=99re using a normal OAuth auth code flow with a =
mobile app (Chrome custom tabs/ASWebAuthenticationSession and all). =
Also, want to reduce the interruptions to the end user.=20
>=20
> In general, it seems like refresh token is not the tool for the job, =
as it generally implies offline_access, when the user is not there. So =
if the user signed out of their identity provider, I would not want them =
to be able to get a new access token.
>=20
> Via normal web flow, the =E2=80=9Cprompt=3Dnone=E2=80=9D ability is =
available (called Silent Authentication by Auth0), so the refresh can be =
done in the background, without ever bothering the user at all if they =
are still logged in. I don=E2=80=99t think this is possible with a =
chrome custom tab or iOS equivalent, even if the user never needs to =
enter their password.
>=20
> Is there some type of similar flow for native mobile applications? It =
seems like most of the suggestions out there refer to just using the =
refresh tokens. Also, another note, SMART on FHIR seems to introduce the =
concept of =E2=80=9Conline_access=E2=80=9D, which seems to indicate a =
refresh token that is tied to an authentication session. That also seems =
interesting to me.
>=20
> So anyway, is there any general guidance? Is everyone just using =
refresh tokens? Some combination of long access tokens and longer web =
authentication sessions?
>=20
> Thanks in advance,
>=20
> Ron
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_E396ECB4-DAD2-4E5F-91B8-99F2E1B3F4E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


The offline_access scope is defined as part of OpenID =
Connect, not as part of OAuth. There is no requirement that =
offline_access scope be the only way to have a refresh token issued, =
although some implementations have chosen to do this. My interpretation =
is that the offline_access is a partial misnomer - the user is only =
=E2=80=98offline=E2=80=99 in the sense of whether they currently have an =
authenticated session with the IDP.

The reason many OIDC implementations try to not =
return refresh tokens is that they want to have all authentication =
decisions flow through the user agent as potentially interactive. You =
can track user authentication within a refresh token, but this adds =
complications such as requiring persistent state within the =
application.

The question is whether =
your app cares about current user authentication at the IDP. If your =
application either:
- Uses IDP authentication more as a =
registration/account recovery to a local application account
- =
Doesn=E2=80=99t care about IDP authentication but is just using the =
token for authorization purposes

Then =
there isn=E2=80=99t a reason to go back through the web-based =
authentication process. Just do what you need to get a refresh token =
within the TOS of the IDP and go with that.

IMO, the value of knowing active IDP =
authentication is reduced for mobile use cases, because (rightly or =
wrongly) users are expected to control access to the native applications =
through screen locks, passcodes, and biometrics. The primary user =
authentication is local and implicit in being able to open the app. The =
UX expectation is that further authentication challenges by remote =
services are to be done only as needed for their own CYA.

If however you do want to rely on the IDP =
authentication, you=E2=80=99ll need to play within the process of the =
IDP chosen. Don=E2=80=99t request offline access, hope they give you a =
refresh token to use, and if not you=E2=80=99ll be popping up a browser =
pane (with a user consent on iOS 11+) every time the access token =
expires so the IDP can determine if the authentication still =
holds.

And hope in the future that =
in the absence of offline_access, the IDP give a refresh token tracking =
the user authentication session, in order to reduce the frequency users =
are sent through that browser pane.

-DW

On Sep 5, 2018, at 9:29 AM, Ron =
Alleva <ronallevatech@gmail.com> wrote:

Hi all,

I was looking around for =
guidance around how to refresh access tokens on native mobile =
experiences. 

Suppose we=E2=80=99re using a normal =
OAuth auth code flow with a mobile app (Chrome custom =
tabs/ASWebAuthenticationSession and all). Also, want to reduce the =
interruptions to the end user. 

In general, it seems =
like refresh token is not the tool for the job, as it generally implies =
offline_access, when the user is not there. So if the user signed out of =
their identity provider, I would not want them to be able to get a new =
access token.

Via normal web flow, the =
=E2=80=9Cprompt=3Dnone=E2=80=9D ability is available (called Silent =
Authentication by Auth0), so the refresh can be done in the background, =
without ever bothering the user at all if they are still logged in. I =
don=E2=80=99t think this is possible with a chrome custom tab or iOS =
equivalent, even if the user never needs to enter their =
password.

Is there some type of =
similar flow for native mobile applications? It seems like most of the =
suggestions out there refer to just using the refresh tokens. Also, =
another note, SMART on FHIR seems to introduce the concept of =
=E2=80=9Conline_access=E2=80=9D, which seems to indicate a refresh token =
that is tied to an authentication session. That also seems interesting =
to me.

So anyway, is there any =
general guidance? Is everyone just using refresh tokens? Some =
combination of long access tokens and longer web authentication =
sessions?

Thanks in =
advance,

Ron
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_E396ECB4-DAD2-4E5F-91B8-99F2E1B3F4E4--


From nobody Thu Sep  6 13:20:10 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 9EEE7130F1F for ; Thu,  6 Sep 2018 13:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level: 
X-Spam-Status: No, score=-1.908 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, 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 nx0TrjiGK1qw for ; Thu,  6 Sep 2018 13:20:04 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 EEF94127133 for ; Thu,  6 Sep 2018 13:20:03 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id v66-v6so5772348pgb.10 for ; Thu, 06 Sep 2018 13:20:03 -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=reAEYtS2DqasTDU+JKkIhaBbPWIOUhWGiWLYrBrBRw0=; b=IKGlamJv7mDQeYhdLs3oHfZxP0tbN/XSUuHMmj5k6r1KEYl61dXF5mvJUiKhSatTxo KW5JsNQRKYq6LC/mbmBFIGtAI6M6ySrqav7ztRV9SrwV2eE/m1PFvwNEeGx6gc+bEm0q x5YfPrVPDJSI0NVPxLYWU65X/jStTYU9+5sZ5Bq6FSp4gVpH+doiDWwZDaf/gt8oOyz9 PVnj1zqZFcCejD6mju1PX5Lmn3aSF8aIRkqnqMM554J484fKYTJwlZX2eJELC1JvitM9 zcOm0r5y2RU0RV1qpk6FISZCR0SIMNNCMqTlsTcwkJ4b9qZSV+FjUucOGYsoE24LT4Zh 7gzw==
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=reAEYtS2DqasTDU+JKkIhaBbPWIOUhWGiWLYrBrBRw0=; b=I/u21mKYRMyNrcJL0/7NmtdSimHHYFoRKlEvnY5eow0dJa6uX4x9nFoGCTsRd/ggJo hw73Yn+rvotGyv3qps48eof7E1XRMjJ23M3EvvA7P0RDzOPpnwO7nxy82QS94BZP6I9/ kl0YdzqZ+4sj3DF5tkS5AGnesMP7yso79TprHrfDXveMwekJOqq3uQJBaJrMMazidimK ED2W4UoRp+tJVCnKiXOHQEJZfGIc6lHwAcS/Wz2zksPElhsL/IkyWAx7oh9VBbUTCHdC cXdAiFZsof9lTh7ZGcF1HpeqY9SxK5WX+MTX6ds/UNrgCTJKne50GqfSXlwVVhtYcCMy N9IA==
X-Gm-Message-State: APzg51BZ0z0nyAHQRZJuF0K8zdcvsDd4FOeFI4Xa/tciNez9oGD/x/eB Zjt//L1uy5BklLa5BhiIZQGUiZZFWBJWEUtJwMsdYQ==
X-Google-Smtp-Source: ANB0Vdb08XWcdWgoGX8imLkyOjjTECZdH/U7wsaVAFCDFwAAYrWEP3Vi1HeiSufQruzTnDLoUGqL/D84CNmHdaa6x/c=
X-Received: by 2002:a65:5304:: with SMTP id m4-v6mr4733793pgq.250.1536265203159;  Thu, 06 Sep 2018 13:20:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:a109:0:0:0:0 with HTTP; Thu, 6 Sep 2018 13:20:02 -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: Thu, 6 Sep 2018 22:20:02 +0200
Message-ID: 
To: Dave Tonge 
Cc: oauth , Anders Rundgren ,  Mike Jones , Daniel Lindau 
Content-Type: multipart/alternative; boundary="000000000000b7254f0575399d8f"
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: Thu, 06 Sep 2018 20:20:08 -0000

--000000000000b7254f0575399d8f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

A new version has been submitted. It would awesome if we could get some
comments on the draft and thoughts about a potential future adoption.

https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01

Changes includes the change of canonicalization method and some minor
clarifications.

Best regards
//Samuel



On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman  wrote:

> 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 signatur=
es
> instead are completely independent and put in an array at the top level
> cleartext_signature attribute one could just do a minor change to existin=
g
> 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
>> 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 API=
s
>>
>> 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 transacti=
on
>>> requests and responses, and as was mentioned in previous emails it is v=
ery
>>> 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 bu=
t
>>> since it has been hard to find a home for the work (an interested WG) i=
t
>>> 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-canonicalizat=
ion-scheme
>>> has the additional benefit that non-intrusive modifications such as
>>> attribute reordering would not make ruin this signature which was the c=
ase
>>> 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 t=
o
>>> 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
>>>
>>>

--000000000000b7254f0575399d8f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

A new v=
ersion has been submitted. It would awesome if we could get some comments o=
n the draft and thoughts about a potential future adoption.

On Wed, Sep 5, =
2018 at 4:01 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
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 cl=
eartext_signature attribute one could just do a minor change to existing im=
plementations to support cleartext signatures.

On Wed, 5 Sep 20=
18 at 15:54, Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
Hi =
Samuel,

Thanks for the reply, I woul=
d definitely be interested in an updated draft.
Both the s=
igning spec and the=C2=A0canonicalization spec seem a lot simpler than JSON-LD.
It wouldn&#=
39;t be hard to add cleartext-jws signatures to existing JSON APIs

=

Thanks

Dave

On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman <<=
a href=3D"mailto:samuel@erdtman.se" target=3D"_blank">samuel@erdtman.se=
> 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 wa=
s to sign transaction requests and responses, and as was mentioned in previ=
ous emails it is very much desirable to not obfuscate the payload with base=
64 encoding.

The current draft just expired but if=
 we have found interest I would be more than willing to post an update. I w=
as 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) i=
ntended to do some cleanup and one significant change. We think we should m=
ove from ES6 serialization to canonicalization based on draft-rundgren-json-canonicalization-scheme. After a l=
ot of research and emails we have come to the conclusion that it would be e=
asier to get buy in for this method than to get languages to support ES6 co=
mpatible serialization. draft-rundgren-json-canonicalization-scheme ha=
s 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=C2=A0draft-rundgren-json-canonica=
lization-scheme canonicalization schema is available in JavaScript, .NET, Ja=
va , and Python. Anders is currently put=
ting a lot of effort into the canonicalization to make sure it is stable, a=
nd it has been reviewed by several people knowledgeable in JSON.
<=
div>
When it comes to draft-erdtman-jose-cleartext-jws i=
mplementations, I have done one in JavaScript (I modified an existing JOSE =
implementation in a few hours) and Anders has done a Java implementation (a=
t least). The examples in the specification was created and validated with =
different implementations.

I know canonicaliza=
tion 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.<=
/div>

Best regards 
//Samuel Erdtman








--000000000000b7254f0575399d8f--


From nobody Thu Sep  6 13:31:01 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 B7045130EBC for ; Thu,  6 Sep 2018 13:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level: 
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9n7iQHWvRmrP for ; Thu,  6 Sep 2018 13:30:57 -0700 (PDT)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 98D60130E9D for ; Thu,  6 Sep 2018 13:30:57 -0700 (PDT)
Received: by mail-ua1-x92a.google.com with SMTP id h1-v6so10162986uao.8 for ; Thu, 06 Sep 2018 13:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/I7yzMC7qP9VIw2LOsSuvBwnZ/4sgGTdVRpCB99LvNI=; b=HxDW110CHG5zwLR9rgDSsooQGusqIAAmHD3SWVdLbuHz1amMTCcKQlYj+60YQb+XVr WfNRXBZn05zwoTaxyFYPR/t3mHbo9Qubr5KkkJEasDzZQ6oSWGRpuVvBpN5wfl1I0rJs KFM8RzmB0BiR+QCU7fVzUzN5F4JG7RDvfGwgpj5lIBMhfoMHLqvfHgd6gwanRLRubAYA vGQqlBrN2TnBPkvWwJwOfmcvtvWXSqlNAmdGr+uF7OP0htHww2/0q3xcAxIDH5ZsHd8U MJG+df7PD27lmWcu8hxH7MhvxNaOI38sy8Q/wZ4nkmmha/zuwK/y7Li25X650cXU0KYo 6zvQ==
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=/I7yzMC7qP9VIw2LOsSuvBwnZ/4sgGTdVRpCB99LvNI=; b=D1qxFOrBjnRO3gAsinBT9/omSvHum0EFhV1U3JBHahgGGGd8+C/hFZdjNMapEFoGPC PZIduDahuxMdkCdzyzeFig80DGu9rfJhGdeDbN83+0Ne3JKYAA3jt4Brgmh8TOtWveQz xpFvZH5HxzC1xJvgCt+SO4PFbaDCHGlP05b39mOpZPZKJocyp8NIff+t36MZyp1xo1AO ZsSvp9pnjpKRo5PF/oblTzCwmYHmxs/3US7yEgWVPjaVH40Zhsb7yzKXU2Zw1ttwW2C7 QOIGX+2EGp797+7oxgDRMSF4FekHSWYacEtiWSA5zX2T6uBgUdJTav+lXtCLI1G7vCfB WG5g==
X-Gm-Message-State: APzg51Dlyhs0OCzFWDpQgX5evr5g5BUTXJ84o78K1jWNVfxQIwIpW0xY U13F4aSy6RaT/hohmu+1M3XO30/0EgzHMidpSHnpSp9ueQjoyw==
X-Google-Smtp-Source: ANB0VdYLt3NVdcdy0emmW5bY/jVHtd9s0Snmeeo7Q+SvFjf17HYDMOUNUZosVTNcZDE4COTz+SQRBQde3ArK/AY0Jk8=
X-Received: by 2002:a1f:8b8b:: with SMTP id n133-v6mr1555007vkd.60.1536265856006;  Thu, 06 Sep 2018 13:30:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab0:718c:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 13:30:35 -0700 (PDT)
In-Reply-To: 
References: 
From: William Denniss 
Date: Thu, 6 Sep 2018 13:30:35 -0700
Message-ID: 
To: Eestermans Dries 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a14563057539c44e"
Archived-At: 
Subject: Re: [OAUTH-WG] Remark on OAuth Device Flow Draft 12
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: Thu, 06 Sep 2018 20:31:00 -0000

--000000000000a14563057539c44e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dries,

Good question. The intent of the expired_token error message is to
communicate to the device client that it should stop polling as the session
has expired. The reason we defined the separate error message for just this
case was so that clients could present an accurate message (i.e. that the
polling should conclude due to the session expiring, but the user could try
again).

There is no requirement in the specification that this error be returned on
all expired tokens, for example implementors could make the decision only
to return expired_token for 5 minutes which would enable the above UI
behavior, or to never return that code if they wanted.  There is also no
requirement to persist expired tokens, this logic is completely up to the
server.

I do think it's good behavior to persist the expired token for several
minutes after expiry and to return the "expired_token" error code during
that time, in order to help the client better serve the user, but after
that time there isn't any value in returning that error code, and no need
to persist the tokens just for that reason.

Best,
William



On Wed, Sep 5, 2018 at 11:45 PM, Eestermans Dries 
wrote:

> Dear all,
>
>
>
> I=E2=80=99ve been implementing the device flow on my own client, and conf=
iguring
> the server side as well.
>
>
>
> I have only one remark/question regarding https://tools.ietf.org/html/
> draft-ietf-oauth-device-flow-12#section-3.5
> 
> :
>
> There=E2=80=99s several error codes defined, the one I=E2=80=99m question=
ing specifically
> is: *expired_token*. When you return expired_token, don=E2=80=99t you
> (implicitly) expose data about once-existing tokens? Wouldn=E2=80=99t a b=
etter
> error definition be something like; invalid_token? That way the client
> knows the code it=E2=80=99s using is invalid, without exposing any histor=
y of
> actual expired tokens, and can conclude the session as intended.
>
>
>
> Furthermore, if expired tokens are a thing, should the server persist
> expired tokens? If so, how long would they have to remain there? Wouldn=
=E2=80=99t
> it be easier at this point to simply discard the tokens once it expires?
>
>
>
> Kind regards,
>
>
>
> Dries Eestermans
>
>
>

--000000000000a14563057539c44e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Dries,

Good question. The intent of the expired_token erro=
r message is to communicate to the device client that it should stop pollin=
g as the session has expired. The reason we defined the separate error me=
ssage for just this case was so that clients could present an accurate mess=
age (i.e. that the polling should conclude due to the session expiring, but=
 the user could try again).

There is no req=
uirement in the specification that this error be returned on all expired to=
kens, for example implementors could make the decision only to return expir=
ed_token=C2=A0for 5 minutes which would enable the above UI behavior, or to=
 never return that code if they wanted.=C2=A0 There is also no requirement =
to persist expired tokens, this logic is completely up to the server.
=


I do think it's good behavior to persist the expire=
d token for several minutes after expiry and to return the "expired_to=
ken" error code during that time, in order to help the client better s=
erve the user, but after that time there isn't any value in returning t=
hat error code, and no need to persist the tokens just for that reason.

Best,
William


=


On Wed, Sep 5, 2018 at 11:45 PM, Eestermans Dries <dries.eesterman=
s@is4u.be> wrote:











Dear all,


=C2=A0


I=E2=80=99ve been implementing the device flow on my=
 own client, and configuring the server side as well.


=C2=A0


I have only one remark/question regarding 
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-12#secti=
on-3.5:


There=E2=80=99s several error codes defined, the one=
 I=E2=80=99m questioning specifically is:
expired_token. When you return expired_token, don=E2=80=99t you (imp=
licitly) expose data about once-existing tokens? Wouldn=E2=80=99t a better =
error definition be something like; invalid_token? That way the client know=
s the code it=E2=80=99s using is invalid, without exposing
 any history of actual expired tokens, and can conclude the session as inte=
nded.


=C2=A0


Furthermore, if expired tokens are a thing, should t=
he server persist expired tokens? If so, how long would they have to remain=
 there? Wouldn=E2=80=99t it be easier at this point to simply discard the t=
okens once it expires?


=C2=A0


Kind regards,


=C2=A0


Dries Eestermans<=
/span>


=C2=A0










--000000000000a14563057539c44e--


From nobody Fri Sep  7 12:41:08 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 B45ED130DDB for ; Fri,  7 Sep 2018 12:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 JpR1AVp05pV7 for ; Fri,  7 Sep 2018 12:41:03 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 78E68127AC2 for ; Fri,  7 Sep 2018 12:41:03 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id u13-v6so21312688iti.1 for ; Fri, 07 Sep 2018 12:41:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CZsJ5R95IVJMFoxBH6nzuKG8bjpDjb+gZJCwm1fLLKs=; b=Xvifnj3aEDqZRkkCOH5HEH95WTHMRwVLgNkwdXWWJANEC4UkVbyHVxPtCGjiBm7DjC Mao7eerVyA+TigUp9bHDXXw/10KCatRlTQONjvclVfC9JlEpvWH7BL2+6eR39YbU1gRs Z+AN9CEuN4IDcOmP9N1V5GrS2aF6mLTwt2Fq0=
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=CZsJ5R95IVJMFoxBH6nzuKG8bjpDjb+gZJCwm1fLLKs=; b=jA/ER6+Mey1g+GNyH23Ch/bwPejUkLqKOio+2PCxR2QhNNlNF0ctm57mN2PydRDRX7 Mk/HwUAKrvkgow7x/wReXLF8yJtq4E2+sQ0HM9RxICdzlh6E2r6aGqe/Iofhpl9apLgs THkBfU6AJk6jbQc8NqbYoO1d0xM/6T50A+779ZYh4NXSxm7IgYpStApOStblCdFQ8zU/ gAqP3iGWmPTIwBysdfbKF7EfVijqYb15g3VY7RrjaAemXRLcLUHPjFz+FK1COxtcZ8i3 glclr3S9SXSRu722ubldDQ0ZyzJFvRq54Tok7CZwBTr4AyhuQL6vntTVby2DL03zfbII lrOg==
X-Gm-Message-State: APzg51BuwQrq+xL/5tzwbuoEynd0YCenuDfumLPQ2R/wBQyjpO4R6Bsb D8LoIS2OhmZQImV4lWrxZghVgc77vzb6OFiIcWiYR5iRv3v4QrBtcXp00Bq8qK6AZoobRbSLxhM h0CokBE4RlE0Fyx54
X-Google-Smtp-Source: ANB0VdZkTuHnRaa3yMCGvh7AwieAcErat0t/BxJBogfn+7gh2ixHTblVGTYbSwGW61IOsbds2WGU0AUmn9b0sRKlR2k=
X-Received: by 2002:a02:c04e:: with SMTP id u14-v6mr8609522jam.110.1536349262421;  Fri, 07 Sep 2018 12:41:02 -0700 (PDT)
MIME-Version: 1.0
References: <153335394820.18507.18435740800535187975@ietfa.amsl.com> <573d1767-18d4-d02a-dd64-ea4fd684b513@connect2id.com>  
In-Reply-To: 
From: Brian Campbell 
Date: Fri, 7 Sep 2018 13:40:36 -0600
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: oauth 
Content-Type: multipart/alternative; boundary="00000000000009c11405754d3014"
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.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Sep 2018 19:41:07 -0000

--00000000000009c11405754d3014
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry again for the slow response Vladimir, I've tried to respond inline
below.


On Sat, Sep 1, 2018 at 2:47 AM Vladimir Dzhuvinov 
wrote:

> 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 vers=
a)
> - how should the AS respond in that case?
>
As I mentioned before, Token Exchange has (and registers) a similar
parameter and error code and I need to reconcile the wording and naming in
the resource indicators draft to better align with that because it's
ultimately the same parameter with just a more generalized usage in this
draft. In particular the error code there is "invalid_target" and I think
that it would be appropriate for issues with the resource parameter as well
as for problematic combinations of resource and scope. And the
"error_description" is always available to provide a more human meaningful
explanation of the problem.



> 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 scope=
s
> belong to which resource, and prevent "invalid_resource" errors.
>
There was quite a bit of discussion around this kind of thing when the
draft was introduced and the general consensuses was not to have AS
metadata about resources. There are ASs that don't know all the resources
or can't know or don't want to have to know. And more generally it just
doesn't scale well.


> Similarly, allowed "resources" in OAuth client metadata?
>
 The client metadata side hasn't really been discussed as far as I know.
But my inclination would similarly be to not define any new 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 encod=
e
> 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.
>
I can look to expand the discussion some. But I'm honestly not sure what
else to say or is appropriate to say. It's a complex and somewhat loaded
topic. It's not exactly related but makes me think of this recent blog from
Vittorio about scopes
. Anyway, if you
have some concrete suggestions here, please share them.


>
>    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?
>
> Yeah, that text was written before the MTLS draft existed and should be
updated to more accurately reflect the current situation and options.
Thanks for pointing that one out.

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--00000000000009c11405754d3014
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Sorry again for the slow response Vladi=
mir, I've tried to respond inline below. 


On Sat, Sep 1, 2018 =
at 2:47 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

 =20
   =20
 =20
  

    
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 i=
n that
      case?
As I mentioned before, Token Exchang=
e has (and registers) a similar=20
parameter and error code and I need to reconcile the wording and naming=20
in the resource indicators draft to better align with that because it's=
 ultimately the same parameter with just a more generalized usage in this d=
raft. In=20
particular the error code there is "invalid_target" and I think t=
hat it=20
would be appropriate for issues with the resource parameter as well as=20
for problematic combinations of resource and scope. And the=20
"error_description" is always available to provide a more human=
=20
meaningful explanation of the problem. 

=C2=A0

    
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.
T=
here was quite a bit of discussion around this kind of thing when the draft=
 was introduced and the general consensuses was not to have AS metadata abo=
ut resources. There are ASs that don't know all the resources or can=
9;t know or don't want to have to know. And more generally it just does=
n't scale well.
=C2=A0

    

    
Similarly, allowed "resources" in OAuth client metadata?
    
=C2=A0The client metadata side hasn't reall=
y been discussed as far as I know. But my inclination would similarly be to=
 not define any new metadata. 
=C2=A0

    

    
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 grea=
tly
      help them with a honest discussion of the pros & cons of the
      two approaches. And perhaps suggest how to migrate between the
      two.
I can look to expand the discussion s=
ome. But I'm honestly not sure what else to say or is appropriate to sa=
y. It's a complex and somewhat loaded topic. It's not exactly relat=
ed but makes me think of this recent blog from Vittorio about scopes. Anyway, i=
f you have some concrete suggestions here, please share them. 
=C2=A0

    


    

    

      

        
   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?

    
Yeah, that text was written before the MTLS dra=
ft existed and should be updated to more accurately reflect the current sit=
uation and options. Thanks for pointing that one out. 

=C2=A0





<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--00000000000009c11405754d3014--


From nobody Sun Sep  9 05:36: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 D2966130DC4 for ; Sun,  9 Sep 2018 05:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 pCKnMh4UP_rg for ; Sun,  9 Sep 2018 05:36:53 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) (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 CF4E912F1A5 for ; Sun,  9 Sep 2018 05:36:52 -0700 (PDT)
Received: from [84.158.238.150] (helo=[192.168.71.126]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fyyxN-0006qt-0H; Sun, 09 Sep 2018 14:36:49 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-3355EEEE-CF28-443E-BD3C-12188916799D; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (15G77)
In-Reply-To: 
Date: Sun, 9 Sep 2018 14:36:48 +0200
Cc: Dave Tonge , Daniel Lindau , oauth , Anders Rundgren 
Content-Transfer-Encoding: 7bit
Message-Id: <51806D1E-29AA-412D-9D42-8B7411E21115@lodderstedt.net>
References:  <20180831144510.GO15624@kduck.kaduk.org>  <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com>    <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>     
To: Samuel Erdtman 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
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: Sun, 09 Sep 2018 12:36:57 -0000

--Apple-Mail-3355EEEE-CF28-443E-BD3C-12188916799D
Content-Type: multipart/alternative;
	boundary=Apple-Mail-81FED3A1-70AE-4E4A-810C-536D1E947454
Content-Transfer-Encoding: 7bit


--Apple-Mail-81FED3A1-70AE-4E4A-810C-536D1E947454
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Samuel,

thanks for preparing this draft. I=E2=80=98ve got one question: how would on=
e use it for non-reputation? I assume non-reputation would require not only t=
o sign the request body but also (at least) data about the target of the req=
uest, typically a URL + HTTP method. Would one need to include (replicate) t=
his data in the JSON object?

kind regards,
Torsten.

> Am 06.09.2018 um 22:20 schrieb Samuel Erdtman :
>=20
> Hi,
>=20
> A new version has been submitted. It would awesome if we could get some co=
mments on the draft and thoughts about a potential future adoption.
>=20
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>=20
> Changes includes the change of canonicalization method and some minor clar=
ifications.
>=20
> Best regards
> //Samuel
>=20
>=20
>=20
>> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman  wrote:=

>> Then I=E2=80=99ll post an update within a ~week.
>>=20
>> There is one thing that could make implementing even simpler (from my exp=
erience). That is how to handle multiple signatures. Today the specification=
 supports sharing of headers between signatures. If signatures instead are c=
ompletely independent and put in an array at the top level cleartext_signatu=
re attribute one could just do a minor change to existing implementations to=
 support cleartext signatures.
>>=20
>>> On Wed, 5 Sep 2018 at 15:54, Dave Tonge  wr=
ote:
>>> Hi Samuel,
>>>=20
>>> Thanks for the reply, I would definitely be interested in an updated dra=
ft.
>>> Both the signing spec and the canonicalization spec seem a lot simpler t=
han JSON-LD.
>>> It wouldn't be hard to add cleartext-jws signatures to existing JSON API=
s
>>>=20
>>> Thanks
>>>=20
>>> Dave
>>>=20
>>>> On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman  wrote:
>>>> Hi
>>>>=20
>>>> As one of the authors of draft-erdtman-jose-cleartext-jws I definitely t=
hink this is the way to go. The initial use case was to sign transaction req=
uests and responses, and as was mentioned in previous emails it is very much=
 desirable to not obfuscate the payload with base64 encoding.
>>>>=20
>>>> 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 si=
nce it has been hard to find a home for the work (an interested WG) it has n=
ot be top of my proirity list.=20
>>>>=20
>>>> 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 serial=
ization to canonicalization based on draft-rundgren-json-canonicalization-sc=
heme. 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 s=
upport ES6 compatible serialization. draft-rundgren-json-canonicalization-sc=
heme has the additional benefit that non-intrusive modifications such as att=
ribute reordering would not make ruin this signature which was the case with=
 ES6 serialization (and we could avoid some minor ES6 quirks).=20
>>>>=20
>>>> Implementations for the draft-rundgren-json-canonicalization-scheme can=
onicalization schema is available in JavaScript, .NET, Java , and Python. An=
ders is currently putting a lot of effort into the canonicalization to make s=
ure it is stable, and it has been reviewed by several people knowledgeable i=
n JSON.
>>>>=20
>>>> When it comes to draft-erdtman-jose-cleartext-jws implementations, I ha=
ve done one in JavaScript (I modified an existing JOSE implementation in a f=
ew hours) and Anders has done a Java implementation (at least). The examples=
 in the specification was created and validated with different implementatio=
ns.
>>>>=20
>>>> I know canonicalization is a scary thing if you have worked with canoni=
calization of XML, but I can tell you canonicalization of JSON is not even c=
lose to that complex.
>>>>=20
>>>> Best regards=20
>>>> //Samuel Erdtman
>>>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-81FED3A1-70AE-4E4A-810C-536D1E947454
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Samuel,

thanks for preparing this draft. I=E2=80=98ve got one question: how=
 would one use it for non-reputation? I assume non-reputation would require n=
ot only to sign the request body but also (at least) data about the target o=
f the request, typically a URL + HTTP method. Would one need to include (rep=
licate) this data in the JSON object?

kind regards,=

Torsten.

Am 06.09.2018 um 22:20 schrieb Samuel Erdt=
man <samuel@erdtman.se>:
<=
br>
Hi,

A new version has been submitted. It would a=
wesome if we could get some comments on the draft and thoughts about a poten=
tial future adoption.


Changes incl=
udes the change of canonicalization method and some minor clarifications.

Best regards
//Samuel


On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman <samuel@erdtman=
.se> wrote:
Then I=E2=80=99ll=
 post an update within a ~week.

There is one thing that could make im=
plementing even simpler (from my experience). That is how to handle multiple=
 signatures. Today the specification supports sharing of headers between sig=
natures. If signatures instead are completely independent and put in an arra=
y at the top level cleartext_signature attribute one could just do a minor c=
hange to existing implementations to support cleartext signatures.

On Wed, 5 Sep 2018 at 15:54, Dave Tonge <dave.tonge@momentumft.co.uk> wrote=
:
<=
div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",sa=
ns-serif">Hi Samuel,

Thanks for the repl=
y, I would definitely be interested in an updated draft.
Bot=
h the signing spec and the canonicalization spec seem a lot simpler than JSON-LD.
It would=
n't be hard to add cleartext-jws signatures to existing JSON APIs

Thanks

Dave

<=
div dir=3D"ltr">On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman <samuel@erdtman.se> wrote:<=
br>
<=
div dir=3D"ltr">
Hi

As one of the authors of draft-erdtman-jose-cleartext-jws I defi=
nitely think this is the way to go. The initial use case was to sign transac=
tion requests and responses, and as was mentioned in previous emails it is v=
ery much desirable to not obfuscate the payload with base64 encoding.
<=
div>
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 e=
arlier 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. 

Wi=
th the potential update we (I and the co authors) intended to do some cleanu=
p and one significant change. We think we should move from ES6 serialization=
 to canonicalization based on draft-rundgren-js=
on-canonicalization-scheme. After a lot of research and emails we h=
ave come to the conclusion that it would be easier to get buy in for this me=
thod than to get languages to support ES6 compatible serialization. draft-ru=
ndgren-json-canonicalization-scheme has the additional benefit that non=
-intrusive modifications such as attribute reordering would not make ruin th=
is signature which was the case with ES6 serialization (and we could avoid s=
ome minor ES6 quirks). 

Implementations for the=
 draft-rundgren-json-canonicalization-scheme canonicalization sche=
ma is available in JavaScript, .NET, Java , and Pyth=
on. Anders is currently putting a lot of effort into the canonicalizatio=
n to make sure it is stable, and it has been reviewed by several people know=
ledgeable in JSON.

When it comes to draft-erdtm=
an-jose-cleartext-jws implementations, I have done one in JavaScript (I=
 modified an existing JOSE implementation in a few hours) and Anders has don=
e a Java implementation (at least). The examples in the specification was cr=
eated and validated with different implementations.

=

I know canonicalization is a scary thing if you have worked with canoni=
calization of XML, but I can tell you canonicalization of JSON is not even c=
lose to that complex.

Best regards 
/=
/Samuel Erdtman








____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-81FED3A1-70AE-4E4A-810C-536D1E947454--

--Apple-Mail-3355EEEE-CF28-443E-BD3C-12188916799D
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow
ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p
Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp
vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048
LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp
WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC
AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK
6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF
BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx
AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f
BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu
dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC
hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w
IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6
7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ
koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6
xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM
5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe
Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDkwOTEyMzY0OFow
IwYJKoZIhvcNAQkEMRYEFMvzk5lKWFO9BHhb8/2XiC6M0kY4MIG+BgkrBgEEAYI3EAQxgbAwga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh
bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID
lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk
MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQBKNm2tuBQQyS2EptC7
qiJA/anYyp7FLlzraFrdVKfEf+CaB+Ma8WeRqGZ397ugI0p4J9f3xPCP/IEOrpxz9ZI6vfaXfH9N
dKvcYxVHKXYajsfEhfN8FaaLwezZzKR9rfevHVFHjFnAaO5Dbk3rLzSbA0SlWZUpHdD5o9llyylj
PCLhtFxAN6NjhAuvYcs2F0so1+ACsVG5ujV3bL0SOJ9Wcg0jpJDTOcKn1WeGHpapbKedEb0RAZcI
XrbNmsk3vyKzrM3dLj9hC0JT4wGe/MaA4HCjwTO6Ub2q/w4KvZ6dku35QKYLeU2loSJKDWQ86lug
xP5oqxBYBTTWES04joWnAAAAAAAA
--Apple-Mail-3355EEEE-CF28-443E-BD3C-12188916799D--


From nobody Sun Sep  9 13:05:07 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 D33C7130DEA for ; Sun,  9 Sep 2018 13:05:05 -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 s1LMigmADl5F for ; Sun,  9 Sep 2018 13:05:02 -0700 (PDT)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 CD1D2128D68 for ; Sun,  9 Sep 2018 13:05:02 -0700 (PDT)
Received: by mail-pf1-x441.google.com with SMTP id u24-v6so9363650pfn.13 for ; Sun, 09 Sep 2018 13:05:02 -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=fND0G/fBCNiUsz9nOA8/HaTA3lZqdZMv+BBITeM2vio=; b=BkJaRFJfpu5Xir3x0w3xlOjT2qFdLi9MEfGyufCphUZVkpaWiv3TknPkrfn3+fGKNn YOpRLtNIFBYACRYkppSIr9D+X665vo5cdEcP7lDYkGtkwITSEOn/wQFsfArCJ5Rk4Vk9 lP8yYTx+arVvTvP7axt0imbxM+WqoU9gwSkcHJnWHeI3REnbeaDNhCDFIszJCOx6rZAF UmIHv4cZwsyA9b+IKdKyVAqLQP9PAlSgOXhz99/0dyS8HQ0Ndo5vxNt2fe/38uK3Zjng HVzlTSxtvoaSKjS4fkdc8uOwfQAkxNRDZmpN2wpPePlFizIQNLFeYrfyLpFzKgm2AtHI QG7w==
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=fND0G/fBCNiUsz9nOA8/HaTA3lZqdZMv+BBITeM2vio=; b=GI0whch6tN1RT0FaHRxzNEfc9b8hGGDz1uvVFtjveCceSFtXbSK8omnhoaWOSVJMFg UdZMGaEzaicXtcY2EzNV+ypaLK6Ajkats2zeEB+pEuykB2yJHc7sQM7fNBLlslOkdN6a iPBlwihjDZKVf2SvIC1P+LCBqkNV6Fjhu2DgXWfbFCvHTtrk2w8Pn6L4Crxl3DZRNb17 HS09uHVSU93KqT71amyFZDY8LsWAjGmQql4KMUNoWrzx9guuVIlvL05MdEc/zqVJCQxG vVyVAzrohHT+yojELBix59uJkA77qhE2QYOTvWsvV4m34dkU9sDweMyGimeegLBXciJ9 VoQg==
X-Gm-Message-State: APzg51B96G4Fzgj5UDPmf/SKQQHkKbD/zLuteKFUY3IPLMYXZ7aoAcYO pggcLvEBm7Du95SHPxlmsWsv6O00TXZc1n1puEqwsg==
X-Google-Smtp-Source: ANB0VdZH+8uqftc9kZ/VOK5pWD28KIw7+xW5C9RnIgtTN5Fv+DKQqUb/+foNTI1Cgg8MO5vQdBGS/T6RiY1fL3YD7Pk=
X-Received: by 2002:a63:d518:: with SMTP id c24-v6mr18298089pgg.357.1536523501699;  Sun, 09 Sep 2018 13:05:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:a109:0:0:0:0 with HTTP; Sun, 9 Sep 2018 13:05:00 -0700 (PDT)
In-Reply-To: <51806D1E-29AA-412D-9D42-8B7411E21115@lodderstedt.net>
References:  <20180831144510.GO15624@kduck.kaduk.org>  <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com>    <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>      <51806D1E-29AA-412D-9D42-8B7411E21115@lodderstedt.net>
From: Samuel Erdtman 
Date: Sun, 9 Sep 2018 22:05:00 +0200
Message-ID: 
To: Torsten Lodderstedt 
Cc: Dave Tonge , Daniel Lindau ,  oauth , Anders Rundgren 
Content-Type: multipart/alternative; boundary="000000000000823581057575c1df"
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: Sun, 09 Sep 2018 20:05:06 -0000

--000000000000823581057575c1df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for asking Torsten,

If method or URL contains additional information not contained in the
request body then it would have to be duplicated into the request to be
signed. This may also aplie to headers.

I do not necessarily think it would be bad to duplicate this information
into the request. To support the non-repudiation use-case I expect the
request to be archived and then all this information must be stored. If we
had a schema that could sign method, URL, headers, and body independently
we would still need to collect them when archiving the full request. If we
instead duplicate this information in the request JSON it would be ready
for archiving and the information-format could be in the most appropriate
format for the application context.

With that said draft-erdtman-jose-cleartext-jws does not dictate a solution=
.

Best regards
//Samuel

On Sun, Sep 9, 2018 at 2:36 PM, Torsten Lodderstedt  wrote:

> Hi Samuel,
>
> thanks for preparing this draft. I=E2=80=98ve got one question: how would=
 one use
> it for non-reputation? I assume non-reputation would require not only to
> sign the request body but also (at least) data about the target of the
> request, typically a URL + HTTP method. Would one need to include
> (replicate) this data in the JSON object?
>
> kind regards,
> Torsten.
>
> Am 06.09.2018 um 22:20 schrieb Samuel Erdtman :
>
> Hi,
>
> A new version has been submitted. It would awesome if we could get some
> comments on the draft and thoughts about a potential future adoption.
>
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>
> Changes includes the change of canonicalization method and some minor
> clarifications.
>
> Best regards
> //Samuel
>
>
>
> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman  wrote:
>
>> 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 signatu=
res
>> instead are completely independent and put in an array at the top level
>> cleartext_signature attribute one could just do a minor change to existi=
ng
>> 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
>>> 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 AP=
Is
>>>
>>> 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 transact=
ion
>>>> 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 b=
e
>>>> more than willing to post an update. I was supposed to do so earlier b=
ut
>>>> 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 som=
e
>>>> 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-canonicaliza=
tion-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 implementatio=
n 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 i=
s not
>>>> even close to that complex.
>>>>
>>>> Best regards
>>>> //Samuel Erdtman
>>>>
>>>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--000000000000823581057575c1df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you for asking Torsten,

If m=
ethod or URL contains additional information not contained in the request b=
ody then it would have to be duplicated into the request to be signed. This=
 may also aplie to headers.

I do not necessarily think it would be b=
ad to duplicate this information into the request. To support the non-repud=
iation use-case I expect the request to be archived and then all this infor=
mation must be stored. If we had a schema that could sign method, URL, head=
ers, and body independently we would still need to collect them when archiv=
ing the full request. If we instead duplicate this information in the reque=
st JSON it would be ready for archiving and the information-format could be=
 in the most appropriate format for the application context.

With th=
at said draft-erdtman-jose-cleartext-jws does not dictate a solution.
Best regards
//Samuel

On Sun, Sep 9, 2018 at 2:36 PM, Torsten Loddersted=
t <torsten@lodderstedt.net> wrote:
Hi Samuel,
thanks for preparing this draft. I=E2=80=98ve got one question:=
 how would one use it for non-reputation? I assume non-reputation would req=
uire not only to sign the request body but also (at least) data about the t=
arget of the request, typically a URL + HTTP method. Would one need to incl=
ude (replicate) this data in the JSON object?

kind=
 regards,
Torsten.

Am 06.09.=
2018 um 22:20 schrieb Samuel Erdtman <samuel@erdtman.se>:

Hi,

<=
/div>
A new version has been submitted. It would awesome if we could ge=
t some comments on the draft and thoughts about a potential future adoption=
.


C=
hanges includes the change of canonicalization method and some minor clarif=
ications.

Best regards
//Samuel
<=
/div>


<=
br>
On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtma=
n <samuel@erdtman.se> wrote:
Then I=E2=80=99ll post an update within a ~week.

There is one thi=
ng 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 indepe=
ndent and put in an array at the top level cleartext_signature attribute on=
e could just do a minor change to existing implementations to support clear=
text signatures.

On=
 Wed, 5 Sep 2018 at 15:54, Dave Tonge <dave.tonge@momentumft.co.uk> wrote:<=
br>
<=
div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s=
ans-serif">Hi Samuel,

Thanks for the=
 reply, I would definitely be interested in an updated draft.
Both the signing spec and the=C2=A0canonicalization 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 <samuel@e=
rdtman.se> wrote:
Hi

As one of the authors of draft-erdtman=
-jose-cleartext-jws I definitely think this is the way to go. The init=
ial use case was to sign transaction requests and responses, and as was men=
tioned in previous emails it is very much desirable to not obfuscate the pa=
yload 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 f=
ind a home for the work (an interested WG) it has not be top of my proirity=
 list. 


Implementations for the=C2=A0draft-rundgren-json=
-canonicalization-scheme canonicalization schema is available in JavaScr=
ipt, .NET, Java , and Python. Anders is=
 currently putting a lot of effort into the canonicalization to make sure i=
t is stable, and it has been reviewed by several people knowledgeable in JS=
ON.

When it comes to draft-erdtman-jose-cleart=
ext-jws implementations, I have done one in JavaScript (I modified an =
existing JOSE implementation in a few hours) and Anders has done a Java imp=
lementation (at least). The examples in the specification was created and v=
alidated with different implementations.

I kno=
w canonicalization is a scary thing if you have worked with canonicalizatio=
n of XML, but I can tell you canonicalization of JSON is not even close to =
that complex.

Best regards 
//Samuel=
 Erdtman








<=
div>_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail=
man/listinfo/oauth



--000000000000823581057575c1df--


From nobody Sun Sep  9 20:02:41 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 A743A130E1C for ; Sun,  9 Sep 2018 20:02:40 -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 9eIZUV3jdPcv for ; Sun,  9 Sep 2018 20:02:39 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 8208912D7F8 for ; Sun,  9 Sep 2018 20:02:38 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id p10-v6so16582857ljg.2 for ; Sun, 09 Sep 2018 20:02:38 -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=EirFHlHSJP60DBbyLTqkAeIbejlGjLMecG987s2EJYw=; b=PeUt32M4juKWy9ImB3z84WGo4eF8GKjpgXXtBcPBRJSABJvir2MAz3LO9X3V3m+ezz zFWVcXn9RYlWiVnypqvIgVwIIW+yQBWPmEWCjcvHaJCJs/efgsUgkyZce0H+dxpNwhPv smTuLyw99dl8oqBNVcnZHrxMDXh+dV+UqQi2A=
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=EirFHlHSJP60DBbyLTqkAeIbejlGjLMecG987s2EJYw=; b=YNi0IxjdPbdKi/WZE/OP2ASpzpxcOJwoR+Bce4DUfD3W1CjRgTd+KBc+W7HCxC2zrQ 63X2JUFM9Bs4g66M+Jhwwp6MuOVJPcjQ3dnyqnmS8rEajI5DsI2oG1vd6du7OE5Vh2pO 7Qtr2Ha43QTnUxROha74MQVLFmArf0bm9SjKkQzXKE3c1NVXwpLOo+PuOvkzTEkBvTRi FvV7i2adD+Q/xTxSvcnYzuGrUL40HrCx8pgDVT9Pl6ejj6RqAyDkd8t41asHYZC3UZ7v WMHmghyIDlp26A9zPLmnvSPI8n18mFpGcfo0rAz6Circhp3+J12FQzuOyHV/7IPiXuwd ClOA==
X-Gm-Message-State: APzg51DOlxqztSuhyY3MNV7EbGI98op/c/Sp9XCGDlFtTv6Be3KaBo+F jvdmjcfqggsI5na29o1wM89kkes1AFqchRV2KpUO3A==
X-Google-Smtp-Source: ANB0VdZJVSv0iiUG3P4IUwtTPAqPJh0U5pl2IDurJ+UUpis5aD6QeWMV1yYiqhpIhueI2XEWRnMIv81XcVYfVSgbvtM=
X-Received: by 2002:a2e:5c07:: with SMTP id q7-v6mr10692799ljb.119.1536548556557;  Sun, 09 Sep 2018 20:02:36 -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>      <51806D1E-29AA-412D-9D42-8B7411E21115@lodderstedt.net> 
In-Reply-To: 
From: Dave Tonge 
Date: Mon, 10 Sep 2018 05:02:25 +0200
Message-ID: 
To: Samuel Erdtman 
Cc: Torsten Lodderstedt , Daniel Lindau , oauth ,  Anders Rundgren 
Content-Type: multipart/alternative; boundary="000000000000e4e24b05757b9679"
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: Mon, 10 Sep 2018 03:02:41 -0000

--000000000000e4e24b05757b9679
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

H Torsten

I agree that use use of draft-erdtman-jose-cleartext-jws doesn't support
non-repudiation for JSON HTTP requests or responses alone.
There was a reference made earlier in the email chain to ACME which
requires `url` to be added to the JWT payload, and mention was made that
some header params (e.g. time) would need to be repeated.

However, despite the title of this thread, the main business need that I've
come across is the requirement for non-repudiation for business actions
that are often communicated in JSON via HTTP - rather than just the raw
JSON HTTP requests and responses themselves. As a way of example, consider
a payment initiation request made to a bank - I believe it would be more
important to have in such a payload,  persistent identifiers of the bank
and the originating party, rather than relying solely on recording the
`host` (HTTP/1.1) or `:authority` (HTTP/2) header fields to represent the
bank. First of all the headers change between HTTP/1.1 and HTTP/2, but also
that value is not guaranteed to be persistent, e.g. it could be `
rs2-west-03-api.bank123.com`.

My suggestion would be that for many applications, requiring `iss`, `aud`
and `iat` in the payload would be sufficient. The path and the method may
not be required.

Best Regards

Dave

On Sun, 9 Sep 2018 at 22:05, Samuel Erdtman  wrote:

> Thank you for asking Torsten,
>
> If method or URL contains additional information not contained in the
> request body then it would have to be duplicated into the request to be
> signed. This may also aplie to headers.
>
> I do not necessarily think it would be bad to duplicate this information
> into the request. To support the non-repudiation use-case I expect the
> request to be archived and then all this information must be stored. If w=
e
> had a schema that could sign method, URL, headers, and body independently
> we would still need to collect them when archiving the full request. If w=
e
> instead duplicate this information in the request JSON it would be ready
> for archiving and the information-format could be in the most appropriate
> format for the application context.
>
> With that said draft-erdtman-jose-cleartext-jws does not dictate a
> solution.
>
> Best regards
> //Samuel
>
> On Sun, Sep 9, 2018 at 2:36 PM, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi Samuel,
>>
>> thanks for preparing this draft. I=E2=80=98ve got one question: how woul=
d one use
>> it for non-reputation? I assume non-reputation would require not only to
>> sign the request body but also (at least) data about the target of the
>> request, typically a URL + HTTP method. Would one need to include
>> (replicate) this data in the JSON object?
>>
>> kind regards,
>> Torsten.
>>
>>
>>

--000000000000e4e24b05757b9679
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


H Torsten

I agree that use use of=C2=A0draft-erdtman-jose-clear=
text-jws does=
n't support non-repudiation for JSON HTTP requests or responses alone.=
=C2=A0
There was a refe=
rence made earlier in the email chain to ACME which requires `url` to be ad=
ded to the JWT payload, and mention was made that some header params (e.g. =
time) would need to be repeated.

However, despite the t=
itle of this thread, the main business need that I've come across is th=
e requirement for non-repudiation for business actions that are often commu=
nicated in JSON via HTTP - rather than just the raw JSON HTTP requests and =
responses themselves. As a way of example, consider a payment initiation re=
quest made to a bank - I believe it would be more important to have in such=
 a payload,=C2=A0 persistent identifiers of the bank and the originating pa=
rty, rather than relying solely on recording the `host` (HTTP/1.1) or `:aut=
hority` (HTTP/2) header fields to represent the bank. First of all the head=
ers change between HTTP/1.1 and HTTP/2, but also that value is not guarante=
ed to be persistent, e.g. it could be `rs2-west-03-api.bank123.com`.=C2=A0

My s=
uggestion would be that for many applications, requiring `iss`, `aud` and `=
iat` in the payload would be sufficient. The path and the method may not be=
 required.=C2=A0

Best Regards

Dave<=
/div>
On Sun, 9 Sep 2018 at =
22:05, Samuel Erdtman <samuel@erdtm=
an.se> wrote:
Thank you for asking Torsten,

If method or URL c=
ontains additional information not contained in the request body then it wo=
uld have to be duplicated into the request to be signed. This may also apli=
e to headers.

I do not necessarily think it would be bad to duplicat=
e this information into the request. To support the non-repudiation use-cas=
e I expect the request to be archived and then all this information must be=
 stored. If we had a schema that could sign method, URL, headers, and body =
independently we would still need to collect them when archiving the full r=
equest. If we instead duplicate this information in the request JSON it wou=
ld be ready for archiving and the information-format could be in the most a=
ppropriate format for the application context.

With that said draft-=
erdtman-jose-cleartext-jws does not dictate a solution.

Best regards=

//Samuel

On Sun, Sep 9, 2018 at 2:36 PM, Torsten Lodderstedt <tors=
ten@lodderstedt.net> wrote:
Hi Samuel,

than=
ks for preparing this draft. I=E2=80=98ve got one question: how would one u=
se it for non-reputation? I assume non-reputation would require not only to=
 sign the request body but also (at least) data about the target of the req=
uest, typically a URL + HTTP method. Would one need to include (replicate) =
this data in the JSON object?

kind regards,
<=
div>Torsten.




--000000000000e4e24b05757b9679--


From nobody Mon Sep 10 02:11:46 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 DEBD3130DBE for ; Mon, 10 Sep 2018 02:11:44 -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 2dKVbr7UDMwK for ; Mon, 10 Sep 2018 02:11:42 -0700 (PDT)
Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) (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 C4B351274D0 for ; Mon, 10 Sep 2018 02:11:42 -0700 (PDT)
Received: from [192.168.0.105] ([78.130.190.73]) by :SMTPAUTH: with ESMTPSA id zIEOfZUT93zNZzIEOf1HxG; Mon, 10 Sep 2018 02:11:42 -0700
To: Samuel Erdtman , Dave Tonge 
Cc: Daniel Lindau , oauth , Anders Rundgren 
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==
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <8405cde0-be4d-534a-4e34-ca15bc52abaf@connect2id.com>
Date: Mon, 10 Sep 2018 12:11:39 +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="------------ms080505070100070907000805"
X-CMAE-Envelope: MS4wfOSafeuK/jyG0T7vmEUq7WtgdstYvh4vbbZ0Ll6gQ1NvlKB4JBYODATaGJOMgKjBlyGigCCpaJOUpkn2KgtkIafRhEvnW7J1oIPqzKYdKcixLJ8vtGJt 05zcsfowTfZ8RS4TcrSO56UdtIHzAxucR1+KXJC2Ewwn4c4IQqpivG+WhT/g0iswi71rd+pGquw50sqijsNfPTpcwKwnxCmZBsxQbIQfwL52p4vT3xd/z4jd AZoIrc5MHgPs/jDb/wpf4jjoe6SpnN4Tgdpn/eOx0qRjlgVY7hbU7Bv1uG3iSEFHau1+yc0tUXejQ3p5/i9WxA==
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: Mon, 10 Sep 2018 09:11:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms080505070100070907000805
Content-Type: multipart/alternative;
 boundary="------------00BB8F8D96BCBECA05616DE3"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------00BB8F8D96BCBECA05616DE3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Samuel,

Thanks for the quick update. Factoring out the c14n to a separate
independent spec resulted in a much clearer draft. I don't see anything
missing in terms of spec have it implemented.

Can you suggest a Java library that can handle the c14n
(rundgren-json-canonicalization-scheme)? We already have the JOSE
infrastructure, and I was wondering how we could plug in the c14n.

Vladimir

On 06/09/18 23:20, Samuel Erdtman wrote:
> Hi,
>
> A new version has been submitted. It would awesome if we could get some=

> comments on the draft and thoughts about a potential future adoption.
>
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>
> Changes includes the change of canonicalization method and some minor
> clarifications.
>
> Best regards
> //Samuel
>
>
>
> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman  wrot=
e:
>
>> 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 signa=
tures
>> instead are completely independent and put in an array at the top leve=
l
>> cleartext_signature attribute one could just do a minor change to exis=
ting
>> 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
>>> draft.
>>> Both the signing spec and the canonicalization spec seem a lot simple=
r
>>> 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 definite=
ly
>>>> think this is the way to go. The initial use case was to sign transa=
ction
>>>> requests and responses, and as was mentioned in previous emails it i=
s 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 s=
ome
>>>> 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 th=
at it
>>>> would be easier to get buy in for this method than to get languages =
to
>>>> support ES6 compatible serialization. draft-rundgren-json-canonicali=
zation-scheme
>>>> has the additional benefit that non-intrusive modifications such as
>>>> attribute reordering would not make ruin this signature which was th=
e 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 canonicalizatio=
n 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 implementat=
ion in
>>>> a few hours) and Anders has done a Java implementation (at least). T=
he
>>>> examples in the specification was created and validated with differe=
nt
>>>> 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
>>>>
>>>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------00BB8F8D96BCBECA05616DE3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Samuel,

    
Thanks for the quick update. Factoring out the c14n to a separate
      independent spec resulted in a much clearer draft. I don't see
      anything missing in terms of spec have it implemented.

    

    
Can you suggest a Java library that can handle the c14n
      (rundgren-json-canonicalization-scheme)? We already have the JOSE
      infrastructure, and I was wondering how we could plug in the c14n.<=
br>
    

    
Vladimir

    

    
On 06/09/18 23:20, Samuel Erdtman
      wrote:

    

    

      
Hi,

A new version has been submitted. It would awesome if we could get some
comments on the draft and thoughts about a potential future adoption.

https://tools.ietf.org/html/draft-erdt=
man-jose-cleartext-jws-01

Changes includes the change of canonicalization method and some minor
clarifications.

Best regards
//Samuel



On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman <samuel@erdtman.se> =
wrote:



      

        
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 signatur=
es
instead are completely independent and put in an array at the top level
cleartext_signature attribute one could just do a minor change to existin=
g
implementations to support cleartext signatures.

On Wed, 5 Sep 2018 at 15:54, Dave Tonge <dave.tonge@momentumft.c=
o.uk>
wrote:



        

          
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 <samuel@erdtman.se> wro=
te:



          

            
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 ver=
y
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
<https://tools.ietf.org/=
html/draft-rundgren-json-canonicalization-scheme-01>.
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-canonicalizatio=
n-scheme
has the additional benefit that non-intrusive modifications such as
attribute reordering would not make ruin this signature which was the cas=
e
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
<https://www.npmjs.com/package/canonicalize>, .NE=
T
<https://github.com/cyberpho=
ne/json-canonicalization/tree/master/dotnet>,
Java
<https://sea=
rch.maven.org/artifact/io.github.erdtman/java-json-canonicalization/1.1/j=
ar>,
and Python
<https://github.com/cyberph=
one/json-canonicalization/tree/master/python3>.
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 i=
n
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 n=
ot
even close to that complex.

Best regards
//Samuel Erdtman




          

        

      

      

      

      

      

      
_______________________________________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


    

    

  


--------------00BB8F8D96BCBECA05616DE3--

--------------ms080505070100070907000805
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
CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODA5MTAwOTExMzlaMC8GCSqGSIb3DQEJ
BDEiBCAngH/8NWXW/wPLSRZPckeZKzVHTVG+RF68Iw55s+d2nDBsBgkqhkiG9w0BCQ8xXzBd
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEEAYI3EAQx
gbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD
T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
9DW+rlLUzYs+I90AKROPBDCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA9DW+rlLUzYs+I90AKROPBDANBgkq
hkiG9w0BAQEFAASCAQAcgBlreuDZ8nBfZcwYPkDS8q/QI5skd9e0w6iOCq0KSfzNzoJOg4/A
mHjghCRHO41FE8+o8UPx8v0TRHFw7YHfyaxUU6FKbzHf/ka5k8rq/FT5FzjthibOKy7oI8lQ
O4jA9tX7dWRC5wxqn3rX4+HqHyrv9jwwDE08HkMeSgMaOIO5gwdf2LTwEiOohvLZu0yLjlCB
Czainv9LwUQvDEN942yjoCbgiodob8Z3OoRjDzcRrjd89dJTUkPwoDyJFMrOSmqSwkX8F3cm
z/Ec5t9v6D4tBNvZ8RV3dyM4BIVYqe7+GFUWnxZIJ5rCbqZx6VKTNv8Lh47CS/xtAfCkSFh7
AAAAAAAA
--------------ms080505070100070907000805--


From nobody Mon Sep 10 11:17:02 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 2E0AB130F18 for ; Mon, 10 Sep 2018 11:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pCiGQEK3rSnt for ; Mon, 10 Sep 2018 11:16:58 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 9ED691294D0 for ; Mon, 10 Sep 2018 11:16:58 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id e14-v6so30806672itf.1 for ; Mon, 10 Sep 2018 11:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=UnwYV2vbWS5LtzZecffkY1SElzogDy0S2jHfLXiYf5Y=; b=FNSe36hQfPgKVTKGeUy/wi2pEdMBYb4vluuyocSWy1kxYWqD7B02Ol9aBWWrK7U1d4 a2E3gnCzEXQm4/Faa4hw+3wSF6XZckHdJqwuIBo96sRnNz3sXVhuwrwqNStH2IYtkBSy yPkAUggThSBFxvRi5jA3Q+Tj/Ig7ZVXf7I7/5/FXjiRfL7mqifjWMjmbhnRLb/4bYy4t 2mj3suvlhhKLib5Go0Y66dmoRvN6dmje9FoLy+lyGgMPSOzUBiY/GTQ19WO6AwJOGyab egYxSCZqLd1D7u2i91hUxiWk5BL7C08u3e+JcgLMrYULOxX53JwjzkwoTkTlTNQFWBj9 Gbew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UnwYV2vbWS5LtzZecffkY1SElzogDy0S2jHfLXiYf5Y=; b=BbRQbZLCO4tKGZulV2onVSg5SiOKiCtgFtfpN/BCgUb34QHYqB0iFdLPrLIJW2Np4q xD501BMyIHpl1WJ17BW/XczhM6VMoyNG5bJAuo818rqN0QhVNPEivnGNb29xVTY045Uw c++hiG3PjrEfSgxKg7GtSctL2srYIvugwaHZopnSLWM8SLG5rH8Jr47YWIFZv64twex6 nqiXAN+pQvPq9GUxd2UIv+EtlbSeTg78JJjfCZ7ISJvA8Re3j+yAwEkmH/hEYIMupTG9 Dcf2sDjKSV++H2oBK+UwgBrtxnn0RIh4OlUSjzINrQWrfLt8ue6vo3REjt15KzO56bU6 QCcA==
X-Gm-Message-State: APzg51DcniDffrhfxZvKxbEAdVrM7ZvzOMlRS0G7AmQQh9zyP/Qj4kOe 4+WmNCQUBQeJooLMs+F+NWp9bd5Phu309HLah1eTsxvDkD4=
X-Google-Smtp-Source: ANB0VdYjoGAIG0y6qMhvxZNeqZi5zBYUJJxD+99hzQXF4q6cNTMJadU4rnRLfGo068PKgYHRkdBOYTatHcKps01RUr0=
X-Received: by 2002:a24:338e:: with SMTP id k136-v6mr3523900itk.109.1536603417678;  Mon, 10 Sep 2018 11:16:57 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Mon, 10 Sep 2018 14:17:51 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000df186c0575885c34"
Archived-At: 
Subject: [OAUTH-WG] OAuth WG - Important Dates
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: Mon, 10 Sep 2018 18:17:00 -0000

--000000000000df186c0575885c34
Content-Type: text/plain; charset="UTF-8"

All,

The following is a subset of the important date for IETF103:

Important Dates
IETF 103 : 2018-11-03, Bangkok, TH
2018-09-17 (Monday): Early Bird registration and payment cut-off at UTC
23:59.
2018-09-21 (Friday): Cut-off date for requests to schedule Working Group
Meetings at UTC 23:59.
2018-10-05 (Friday): Preliminary Agenda published for comment.


*Notice that the cut-off for early bird registration is a week from now.
(Thanks to Brian for pointing this out)*

The cut-off date for scheduling a WG meeting is less than two weeks from
now.
So, please let us know as soon as possible if you are planning on
presenting and which topics you planning on discussing,
to help us plan and request enough time to cover these topics.

Regards,
 Rifaat & Hannes

--000000000000df186c0575885c34
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,<=
/font>

The following is a subset o=
f the important date for IETF103:

Important Dates
IETF 103 : 2018-11-03, Bangkok, TH
2018-09-17 (Mo=
nday): Early Bird registration and payment cut-off at UTC 23:59.
2018-09-21=
 (Friday): Cut-off date for requests to schedule Working Group Meetings at =
UTC 23:59.
2018-10-05 (Friday): Preliminary Agenda published for comment.

Notice that the cut-off for early bird registration is a week from now=
. (Thanks to Brian for pointing this out)

The cut-off date for scheduling a WG meeting is less than two week=
s from now.
So, please=
 let us know as soon as possible if you are planning on presenting and whic=
h topics you planning on discussing,=C2=A0
to help us plan and request enough time to cover these=
 topics.

Regards,
=C2=A0Rifaat & Hannes
=



--000000000000df186c0575885c34--


From nobody Mon Sep 10 12:35:41 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 9AB42130F56 for ; Mon, 10 Sep 2018 12:35:38 -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 8XYeQzucrZlq for ; Mon, 10 Sep 2018 12:35:35 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 99C5D1200D7 for ; Mon, 10 Sep 2018 12:35:35 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id s17-v6so10189167plp.7 for ; Mon, 10 Sep 2018 12:35:35 -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=QM44O3wUZCBM0DuuRm8KbL7Ayxx3Dw8Mmr69EcsSFJk=; b=AV7z+mbv4lMT5Elu5l6io1ZL+OxioHF98qVS9qQKL490uw6jSouscJKa4w2f1eguuL r+gCoCcc84RhUfaXCPPoHG/qheFBTM3XDUxq7zukpKxYDIbKp/9gSw6t8ZMrnXE+IY1H uqgRelm48J74OvjSm1gYexCUW1GJTA+oOFfUpKQuEoBRob9AXm+YXTC0QRUn4+YbaKEo vtZc4UD2aIcuyi8jjiSVFLtsqrcxcJf0n10L8MgWe1e0viI1kwyHN9MRPRa1ZQ8PY9tw /1EeYFVRKvwFg06dQMy7gPCwehaZ68s1EqUDH/enRfhEbJsNdEcA1qHMYJERszhPzNPd aX7w==
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=QM44O3wUZCBM0DuuRm8KbL7Ayxx3Dw8Mmr69EcsSFJk=; b=V1fZG1CZhtG8wSjvtnNrGqIvMk179N8Dc6U9Gw0UOpJ+7nAhsKqTxDH2qugA9nQ0Dx 0SU1LGNbNr4ceNAmYE2yAZmhGdLX5NIRNRlYNB7bddFQisRolFpW96nTgpaxUw6ZyOn2 zDWGd5nRAR/sgneBAMj3nqC3N/ohqb/dXPUFFIyTs/tBMN4UqcoTijhzJbSScpPDYJOU LYPEFyanlyY/1WRdJ82eEWed8QcqUxlGYCtTeadPebVQN3ciIeqsJ9wBU2BmqlvkJpuP /GheQcasTFtq9/jTEc5vRJgtsq0Gb3Zbko9OpxWI/D2SoQPTF76Rlol+GdwzUqi1cU2T qbIA==
X-Gm-Message-State: APzg51C7TVXwmogV9RG0l3U0CmvTHkitHudXK9G3QuSLcKPoFE0yQiE3 qvaFY0c+DoqlXcSfndns96XXA7ac2S1mmvG2Nx1HDg==
X-Google-Smtp-Source: ANB0VdZo0DvljSQOtNsIsIdXcMa/x+KpkgfspC822CJ9KmjoNvsGQxUespbnfGCbUhEBTmWW8oKhTpprQ0Ny5NjfmwY=
X-Received: by 2002:a17:902:9307:: with SMTP id bc7-v6mr23145054plb.225.1536608134903;  Mon, 10 Sep 2018 12:35:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:a109:0:0:0:0 with HTTP; Mon, 10 Sep 2018 12:35:34 -0700 (PDT)
In-Reply-To: <8405cde0-be4d-534a-4e34-ca15bc52abaf@connect2id.com>
References:  <20180831144510.GO15624@kduck.kaduk.org>  <0e692780-dc2e-5721-3f56-128db7cca5f4@aol.com>    <50430748-d182-2f1e-ccfc-9c9c30441688@aol.com>      <8405cde0-be4d-534a-4e34-ca15bc52abaf@connect2id.com>
From: Samuel Erdtman 
Date: Mon, 10 Sep 2018 21:35:34 +0200
Message-ID: 
To: Vladimir Dzhuvinov 
Cc: Dave Tonge , Daniel Lindau ,  oauth , Anders Rundgren 
Content-Type: multipart/alternative; boundary="0000000000000a54c605758976bf"
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: Mon, 10 Sep 2018 19:35:39 -0000

--0000000000000a54c605758976bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Vladimir

I have published an implementation created by Anders. You can find it here
https://github.com/erdtman/java-json-canonicalization

I have tested to add support for this in a JavaScript JOSE implementation
(node-jose), it was super easy (just hours of work).

Best regards

On Mon, Sep 10, 2018 at 11:11 AM, Vladimir Dzhuvinov <
vladimir@connect2id.com> wrote:

> Hi Samuel,
>
> Thanks for the quick update. Factoring out the c14n to a separate
> independent spec resulted in a much clearer draft. I don't see anything
> missing in terms of spec have it implemented.
>
> Can you suggest a Java library that can handle the c14n (rundgren-json-ca=
nonicalization-scheme)?
> We already have the JOSE infrastructure, and I was wondering how we could
> plug in the c14n.
>
> Vladimir
> On 06/09/18 23:20, Samuel Erdtman wrote:
>
> Hi,
>
> A new version has been submitted. It would awesome if we could get some
> comments on the draft and thoughts about a potential future adoption.
> https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>
> Changes includes the change of canonicalization method and some minor
> clarifications.
>
> Best regards
> //Samuel
>
>
>
> On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman   wrote:
>
>
> 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 signatur=
es
> instead are completely independent and put in an array at the top level
> cleartext_signature attribute one could just do a minor change to existin=
g
> 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
> 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 ver=
y
> 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-canonicalizatio=
n-scheme
> has the additional benefit that non-intrusive modifications such as
> attribute reordering would not make ruin this signature which was the cas=
e
> 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 i=
n
> 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 n=
ot
> even close to that complex.
>
> Best regards
> //Samuel Erdtman
>
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>

--0000000000000a54c605758976bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Vladimir

I have published an implementation created by Anders.=
 You can find it here https://github.com/erdtman/java-json-canonicalization

I have tested to add support for this in a JavaScript =
JOSE implementation (node-jose), it was super easy (just hours of work).

Best regards

On Mon, Sep 10, 2018 at 1=
1:11 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> =
wrote:

 =20
   =20
 =20
  

    
Hi Samuel,

    
Thanks for the quick update. Factoring out the c14n to a separate
      independent spec resulted in a much clearer draft. I don't see
      anything missing in terms of spec have it implemented.

    

    
Can you suggest a Java library that can handle the c14n
      (rundgren-json-canonicalization-scheme)? We already have the JOS=
E
      infrastructure, and I was wondering how we could plug in the c14n.
    

    
Vladimir

    

    
On 06/09/18 23:20,=
 Samuel Erdtman
      wrote:

    

    

      
Hi,

A new version has been submitted. It would awesome if we could get some
comments on the draft and thoughts about a potential future adoption.

ht=
tps://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01

Changes includes the change of canonicalization method and some minor
clarifications.

Best regards
//Samuel



On Wed, Sep 5, 2018 at 4:01 PM, Samuel Erdtman <samuel@erdtman.se> wrote:



      

        
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 <dave.tonge@momentumft.co.uk>
wrote:



        

          
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 AP=
Is

Thanks

Dave

On Tue, 4 Sep 2018 at 23:33, Samuel Erdtman <samuel@erdtman.se> 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

<https://tools.ietf.org/html/draft-rundgren-=
json-canonicalization-scheme-01>.
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-canonicaliza=
tion-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
<ht=
tps://www.npmjs.com/package/canonicalize>, .NET
<https://github.com/cyberphone/json-canonicalization/tree=
/master/dotnet>,
Java
<https://search.maven.org/artifact/io.github.e=
rdtman/java-json-canonicalization/1.1/jar>,
and Python
<https://github.com/cyberphone/json-canonicalization/tre=
e/master/python3>.
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




          

        

      

      

      

      

      

      
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m=
ailman/listinfo/oauth


    

    

  






--0000000000000a54c605758976bf--


From nobody Mon Sep 10 14:11:52 2018
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6821B130FB5; Mon, 10 Sep 2018 14:11:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: oauth@ietf.org
Message-ID: <153661390437.16125.2137201864131792291@ietfa.amsl.com>
Date: Mon, 10 Sep 2018 14:11:44 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Sep 2018 21:11:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Token Exchange
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-15.txt
	Pages           : 34
	Date            : 2018-09-10

Abstract:
   This specification defines a protocol for an HTTP- and JSON- based
   Security Token Service (STS) by defining how to request and obtain
   security tokens from OAuth 2.0 authorization servers, including
   security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-15


Please note that it may take a couple of minutes from the time of submission
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/


From nobody Thu Sep 13 11:42:56 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 221E01293FB for ; Thu, 13 Sep 2018 11:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 hKQuffRpW_K2 for ; Thu, 13 Sep 2018 11:42:50 -0700 (PDT)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.100]) (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 BD886130E4C for ; Thu, 13 Sep 2018 11:42:50 -0700 (PDT)
Received: from [84.158.238.150] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g0WZk-0005rj-1u; Thu, 13 Sep 2018 20:42:48 +0200
From: Torsten Lodderstedt 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_BB95396C-B2C5-494A-A16B-080622F5E7C9"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 13 Sep 2018 20:42:46 +0200
In-Reply-To: 
Cc: oauth 
To: Rifaat Shekh-Yusef , Hannes Tschofenig 
References: 
X-Mailer: Apple Mail (2.3445.9.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG - Important Dates
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: Thu, 13 Sep 2018 18:42:54 -0000

--Apple-Mail=_BB95396C-B2C5-494A-A16B-080622F5E7C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi chairs,=20

I would like to present two drafts in Bangkok:

- draft-ietf-oauth-security-topics=20
- draft-ietf-oauth-jwt-introspection-response

I would also like to present to the group a new work item being prepared =
by the OpenID Foundation FAPI WG:=20
- JWT Secured Authorization Response Mode for OAuth 2.0 =
(https://openid.net//specs/openid-financial-api-jarm-wd-01.html) mirrors =
JAR for authorization responses. This might be interesting to the WG.

best regards,
Torsten.=20

> Am 10.09.2018 um 20:17 schrieb Rifaat Shekh-Yusef =
:
>=20
> All,
>=20
> The following is a subset of the important date for IETF103:
>=20
> Important Dates
> IETF 103 : 2018-11-03, Bangkok, TH
> 2018-09-17 (Monday): Early Bird registration and payment cut-off at =
UTC 23:59.
> 2018-09-21 (Friday): Cut-off date for requests to schedule Working =
Group Meetings at UTC 23:59.
> 2018-10-05 (Friday): Preliminary Agenda published for comment.
>=20
> Notice that the cut-off for early bird registration is a week from =
now.. (Thanks to Brian for pointing this out)
>=20
> The cut-off date for scheduling a WG meeting is less than two weeks =
from now.
> So, please let us know as soon as possible if you are planning on =
presenting and which topics you planning on discussing,=20
> to help us plan and request enough time to cover these topics.
>=20
> Regards,
>  Rifaat & Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_BB95396C-B2C5-494A-A16B-080622F5E7C9
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow
ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p
Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp
vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048
LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp
WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC
AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK
6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF
BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx
AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f
BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu
dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC
hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w
IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6
7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ
koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6
xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM
5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe
Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW
MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE
AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y
ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0
Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9
Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC
A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+
KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y
pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC
AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC
r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR
BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j
b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG
CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy
dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC
AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE
7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk
SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr
jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5
aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F
29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP
Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj
7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9
cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6
EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE
AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR
AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTgwOTEzMTg0MjQ2WjAjBgkqhkiG9w0BCQQxFgQUOc5ZI6V7nHZZ
o92bYY+4mBPd5Tcwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB
IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB
lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV
MA0GCSqGSIb3DQEBAQUABIIBAHH2hqBymcKaPHyNVcK/EgI2KXHP3UDTGEkwXg2U/7KHblkSBpiw
w6HHoCQgl394V+cT6r8jSUWPkJD1iJHw0P+7Bstu4GV2aKYB/5W1tBfKJaXSD4ka0XHfgVuqALOM
UAMYuOC0hhNat1WeASDk6oJlUQcxyNELonoyTcCaHtd7AxQHgQr5/ZylvkmWElrBt0eZnTrvYgom
WdoQ5YaoD8sAw+88cfTv5J80b8cXi3OADCq3GlXyJQm+2YqDfQvb0F9iAhiQdd82aZT71VtL7PaV
o+4+NrRlBnXmM4FIPX2k0Vo5SVVC2KTizYfubg8fUT80vD9SKLMMGUPrFuCjSicAAAAAAAA=
--Apple-Mail=_BB95396C-B2C5-494A-A16B-080622F5E7C9--


From nobody Mon Sep 17 06:45:52 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 A5680130E6E for ; Mon, 17 Sep 2018 06:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 nHfEbXg2TO8o for ; Mon, 17 Sep 2018 06:45:49 -0700 (PDT)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 17702130E6B for ; Mon, 17 Sep 2018 06:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1537191948; bh=IiQUy1HRYWBy3IrQJOffuVXwC2e8u8ef3cTcK+E93sc=; h=To:From:Subject:Date:From:Subject; b=czxyYbBo8paATQ4Pg+7q+gGUtAeQLGKW8CFvGdU0HuoO6PDfq+qPnPjMyqgABzvNTtH/1o5HRl8px6MPQtv4EF0IaBYEFkAtKKzCjod5Qs8bTx0YzBLnqAgYyd0/+JhUTzn2gBzbw/5m9kJRS5oQwBd3AwaWWvB6XYAumAYlKf2CQ/LFIe3Bv2EJg2gPbFLi17VpFjonbI1L+bcktlrOV9SKOLA+vx6BTTGYbQ9KcxSFYSgUk5J+3ZMmvWURcPmzczRTDGmze+jmpsT5d6uqQix+yGX6LSvTtGEvZb9m9TdEZLj8CTmXxYQHhmDteUet37KCreFrN78JLKlCwihltw==
X-YMail-OSG: lMyJwqYVM1kRVOo.P.Aw2lF2SnJRyDhq70_z0QbGCVc8fPwvuZXOklF4f_Xt38L JGC8J2iFx3I0dWhqoB29yY_vLKW42cAGjocwQMWoEODjqja8dNj1uHIOiPSscgvOh4HPZ_O_8iwD z40vFUr14w2VHliDEMCrRGexG3ZsGnY9xWeuE6RUeQnxj6Flf7e.HAtSIxhHOOMENbhHJQTm9IRU 0gdHHg99D5_rIMlsC5S2veegXBRKuy_4QQ6wyh3db8DJts2WIjwzfdEZp9Hfl_lu__5fTNH6KpaW twMn_Ih9UNZ5LrSI.ykXv7Je9Wbxkaxeci4DlUfGOqz74vTNtAugYSyKyr2jxVJR8eFaDq5NY9Kd jsbNsincHJd4bb_TYu3QwnrfKI81RYXk8G0zU4SiMyEZ0si7iqZ2KE4Vm224wFb9FoKNu0pdxyqd VCvYYW5vNOERcUKm0mtWOoxBmSIm2KXGXVh2dM2Mji4zNrAiRln4i9pfScL0E99x63d5xSiZl5II yKJRhdUMqHTFKIenh4XFSaa9DS6w5UGIQJl5bOE3ZihBtsDn8mJ3GQacFOo1oUU4PbDF5ofk1EUA M5kwScdJAVeIdgNDxmLI45GNfxRPtCYntj1y3tfK0j3sBVuaClxD6cXvJaeXShXf_RGQNlBPoChu Tzac5vyrnPKxWMHnAKX2oUixhuvanRjMIrkmTotJ9OAkaybw8cCG8._zNgLKt362KPXLuSl.EEpn Ex7fE._dBW8LwmBmtOqbmfw64_wSzxkMD2DJ7BpAIZvKwknjPEGpaYd1xb9a9Y4HnrVzz9Meu58S nWCYyqHDj7IIb8EDiGGrS_7wMf.9ROSlHHA21t.86LzhfgtDZa04VKDZXhqf0C4LCEQJVwAK5OgL nDWCG2egydePCm2DSdZ9.UUXaH6hemCc.OIGlZAt7oaaC8eZkYl71g_xSRkdfQBVGdyjwk3YYCoi d.I9t5yK_oPjiTKTi8IC_xQUtmh2YLOVF.aUJG9n_sEIHyr.x_lxbeKjpQeZ3uRA_.zI-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 17 Sep 2018 13:45:48 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d3c7d9150fe329074ac364259e0bb25f for ; Mon, 17 Sep 2018 13:45:45 +0000 (UTC)
To: "oauth@ietf.org" 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <3a2a08f0-28bf-fe53-d571-025dcb196c2f@aol.com>
Date: Mon, 17 Sep 2018 09:45:44 -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
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [OAUTH-WG] Inconsistent error responses between 6749 and 6750
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: Mon, 17 Sep 2018 13:45:51 -0000

Hi,

It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the 
HTTP status code that should be returned when a requested scope is 
"invalid".

For example, if a call is make to the /token endpoint to obtain a new 
access_token and the scopes requested are outside those issued to the 
refresh_token, RFC 6749 says the HTTP status code returned should be 400 
(Bad Request).

However, if an access token is presented to an OAuth2 protected resource 
and the access token does not contain the necessary scope, RFC 6750 says 
the HTTP status code returned should be 403 (Forbidden).

Does anyone remember if this is intentional? The two cases here are 
pretty equivalent semantic-wise.

Thanks,
George


From nobody Mon Sep 17 07:23:05 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 C1FC112D7F8 for ; Mon, 17 Sep 2018 07:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vxSlzmW4Y2w2 for ; Mon, 17 Sep 2018 07:23:02 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 C51C3129385 for ; Mon, 17 Sep 2018 07:23:01 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id k12-v6so19052275oiw.8 for ; Mon, 17 Sep 2018 07:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cgKuONG/siGrAolhSXr/aJZdw19kOfZfKqBffE9G5Xg=; b=HpV8kycpxIQ3idCqi3u4qTViL0Gpl4SA84crqbv5McbB2JsJrZqNfcHSmYFiz8jXB8 oC8wWSdNAQAs5WbIDMX3/YLu5PKj96grr6VKNGp8/fL2I+O9cv322Qk2pAqrNzkJu7QA 7t6mSyYe6fl4HIAwYr46DS0uA4t04Z7ANYnHxFVaZdAKg5DS5lrF2raaUEI480+W2j/E Scyr6oyyiZCx3hw8ABSoi1M6AlbE2j5EwvOQDca7OOW9fv6F372F/bvGKshNhdQXd/MG 9l8T2g57z2GBw3wvoXX63jAmFSb2zIDBQP6ATC488bbfbHcZoT8URnYLpFLdc64EuV2W CVoQ==
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=cgKuONG/siGrAolhSXr/aJZdw19kOfZfKqBffE9G5Xg=; b=S2VhfGyBLMn2ZzLyiIFXvkOLTi7flQ9jY6Iobb7p2MLaFwQS3yW59A5C4E9Kdhssl6 5Ssf5pwsudMrv+/wclmqzZG0km1VJmnruCC9ToB1Azh0rpYaTkn5FFw0VkiG5SGGgT1x r/6IjEFiEy3fCS66vl2jv81s/5VzN4qCVxu6ZVp4P5lI2YQIWboUo2m0ZzCvNs5C7qNl 0U4M21KKey32C94hfMoQD7AaV03fMfizG7gc6S/JwUZxcu100o85XCqSCQSapfDU9ff6 nXSkXDUPZQsZmVL+FXGEqsXxOhsBoEJ5oGkqC6/RRHvacfW+EEPzq8ZI4v0fjdRrwTT+ VRng==
X-Gm-Message-State: APzg51Ckbh2s+l2P7mCjjuetf6SKIZIC06ezPsbY0mUKDtvlgdy35bkR Oyokz0F2E3DPiBvrPneHl8MjtvLiMdQRaqEVQkS/bg==
X-Google-Smtp-Source: ANB0Vdb6Atb4pGMuih0GIgt+he5NQYonZnW+lYg85kF0c3jX3hfVdfKCU7TuAy/3PCQZoxBrwNA6GUcFIMk6XIv2Ja8=
X-Received: by 2002:aca:7c2:: with SMTP id 185-v6mr18069359oih.31.1537194181087;  Mon, 17 Sep 2018 07:23:01 -0700 (PDT)
MIME-Version: 1.0
References: <3a2a08f0-28bf-fe53-d571-025dcb196c2f@aol.com>
In-Reply-To: <3a2a08f0-28bf-fe53-d571-025dcb196c2f@aol.com>
From: Thomas Broyer 
Date: Mon, 17 Sep 2018 16:22:49 +0200
Message-ID: 
To: George Fletcher 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000001d58ce057611e9c9"
Archived-At: 
Subject: Re: [OAUTH-WG] Inconsistent error responses between 6749 and 6750
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: Mon, 17 Sep 2018 14:23:04 -0000

--0000000000001d58ce057611e9c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 17, 2018 at 3:46 PM George Fletcher  wrote:

> Hi,
>
> It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the
> HTTP status code that should be returned when a requested scope is
> "invalid".
>
> For example, if a call is make to the /token endpoint to obtain a new
> access_token and the scopes requested are outside those issued to the
> refresh_token, RFC 6749 says the HTTP status code returned should be 400
> (Bad Request).
>
> However, if an access token is presented to an OAuth2 protected resource
> and the access token does not contain the necessary scope, RFC 6750 says
> the HTTP status code returned should be 403 (Forbidden).
>
> Does anyone remember if this is intentional? The two cases here are
> pretty equivalent semantic-wise.
>

How so=E2=80=BD

In the first case, you have a valid refresh_token and want to obtain an
access_token out of it. Assuming the client correctly authenticated, it is
authorized to make this request, but the request is then rejected due to
its payload/content. It could equally be a 422: the reason it's rejected is
not about authentication or authorization, but because it's a "bad
request", it's "semantically wrong".

In the second case, the token is used to authorize the request at the RS,
whatever the semantics of the request is (once authorized). If the token is
valid but doesn't authorize the request, then a 403 is appropriate.

--0000000000001d58ce057611e9c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon=
, Sep 17, 2018 at 3:46 PM George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:
=

Hi,



It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the 
HTTP status code that should be returned when a requested scope is 

"invalid".



For example, if a call is make to the /token endpoint to obtain a new 

access_token and the scopes requested are outside those issued to the 

refresh_token, RFC 6749 says the HTTP status code returned should be 400 
(Bad Request).



However, if an access token is presented to an OAuth2 protected resource 
and the access token does not contain the necessary scope, RFC 6750 says 
the HTTP status code returned should be 403 (Forbidden).



Does anyone remember if this is intentional? The two cases here are 

pretty equivalent semantic-wise.

How so=
=E2=80=BD

In the first case, you have a valid refr=
esh_token and want to obtain an access_token out of it. Assuming the client=
 correctly authenticated, it is authorized to make this request, but the re=
quest is then rejected due to its payload/content. It could equally be a 42=
2: the reason it's rejected is not about authentication or authorizatio=
n, but because it's a "bad request", it's "semantica=
lly wrong".

In the second case, the token is =
used to authorize the request at the RS, whatever the semantics of the requ=
est is (once authorized). If the token is valid but doesn't authorize t=
he request, then a 403 is appropriate.


--0000000000001d58ce057611e9c9--


From nobody Mon Sep 17 07:24:09 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 03EF0129385 for ; Mon, 17 Sep 2018 07:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wavestone.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 bgx9BDK_Tka7 for ; Mon, 17 Sep 2018 07:24:04 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0074.outbound.protection.outlook.com [104.47.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A904C12D7F8 for ; Mon, 17 Sep 2018 07:24:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wavestone.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pe41EfxNsdhe4p5MtDI1zNpzfpa01AfrzesaI1w1kuo=; b=Co3nD+sXyxsegKmeassca0hDzKeajDn/KvQxusoJjkwtzeV6xacxZ810B0UQtjF/yFSpRYSnPOD2kPUSZP6jQwDxGDTHihMZt1u8NGo9pKldQVAoEDmb/n26pjvsTJDf0ekDhIxmK3PRgOWySmDiI0GgEpuGGdpXqbZN8LhjHYE=
Received: from DB6PR0302MB2677.eurprd03.prod.outlook.com (10.171.74.10) by DB6PR0302MB2582.eurprd03.prod.outlook.com (10.171.73.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.18; Mon, 17 Sep 2018 14:24:00 +0000
Received: from DB6PR0302MB2677.eurprd03.prod.outlook.com ([fe80::4183:fc82:2e35:c9e7]) by DB6PR0302MB2677.eurprd03.prod.outlook.com ([fe80::4183:fc82:2e35:c9e7%4]) with mapi id 15.20.1143.017; Mon, 17 Sep 2018 14:24:00 +0000
From: LARMIGNAT Louis 
To: George Fletcher 
CC: "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Inconsistent error responses between 6749 and 6750
Thread-Index: AQHUTozNVACBHrc7NUGUjreTiDrDRqT0hAlg
Date: Mon, 17 Sep 2018 14:24:00 +0000
Message-ID: 
References: <3a2a08f0-28bf-fe53-d571-025dcb196c2f@aol.com>
In-Reply-To: <3a2a08f0-28bf-fe53-d571-025dcb196c2f@aol.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Louis.LARMIGNAT@wavestone.com; 
x-originating-ip: [165.225.76.207]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR0302MB2582; 6:GnSpkaaEvBL8XxJpkDtdXp5xU9IESCGi78O6WWuuD5BOLlvilI8tvSq5aiQhA3ZUplusF7DsETZLZfGSvFobpIlST3t6+g/Cby9tG51KZ83J0cYqbPPTQR6px+FHm/P1FBeHr5SPipjPfcvxTayGF3p/r8Vi5yuUEOKifovKIPegu0FJZMnIyDZALeL1+x7DHa1WXb52vEN8eU5Ui80kz5e10b7lPCRHHnmrDqsd5XljrBAoDXVNJQZ2XN8HC4ItrkpJV3pNzc/sbldgxd2ESPiqQ8Fgv+UPr7vDO6wVpXXBHXAN8z35O+DAbM9rW/Rn16uEy/2j5co2eDwanvfGyyINQmHvaTZ0pB1Hbts8xPjxf2cdluMBULUlWnhemsLzqgZ8PV7i3LxSkDzc6kM7rsRf0V3jExSMJHjHEm0tALhL+qpHZ3LvAgCcVLVrrzIwa32IzCrwbS05DAq6awBq1A==; 5:J7tEQfJvMO+EU8JLSYImcaX5c801jitmJ9K0TJRNVzvluTlQy8U3A2tBBZKIsxF8OYNb4VQjysoZU+XWFuPTCPcXQlyqBySPappDB2JjdJQ6u88u93SAK+U57DP5hCF8VXQBX9b5NI1cnacKSDvV/mgAGf/lPpLud/6OC7ZWJBs=; 7:z5MLy+U8rhgMIincJO6SWc8F93cJq8mDyNEzwLYfjenO3Y7VQScj4OJxf8Ko7/4erpahuejZs2cvUdsyawgsERwJJE4GW6RukIaP/gFbU2OSv7ePLtQf+DtdukPjXCxRtOBfoCIMpqVvauRTmATspueUa3zb2SGgDS8hPMHO924DcO6Qo8eEJwIRX371e6EFJZLqeAAaeJHhWbuhvc0KJU2r2F1klEJbLm12zI/t+Bh/AIfazN4rxKy+CQs2PlC6
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: d55effe4-4fd4-4f4c-61f7-08d61ca93667
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB6PR0302MB2582; 
x-ms-traffictypediagnostic: DB6PR0302MB2582:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(103651359005742);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699050); SRVR:DB6PR0302MB2582; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0302MB2582; 
x-forefront-prvs: 0798146F16
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(376002)(39850400004)(136003)(55784004)(189003)(199004)(26244003)(9686003)(6306002)(97736004)(66066001)(316002)(2906002)(33656002)(53936002)(6506007)(25786009)(68736007)(7696005)(105586002)(6116002)(3846002)(76176011)(81156014)(81166006)(8676002)(8936002)(74316002)(106356001)(102836004)(72206003)(26005)(99286004)(7736002)(2900100001)(478600001)(39060400002)(5250100002)(14454004)(446003)(5024004)(14444005)(186003)(486006)(5660300001)(476003)(229853002)(256004)(86362001)(6246003)(6436002)(4326008)(305945005)(966005)(55016002)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0302MB2582; H:DB6PR0302MB2677.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: wavestone.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ZdMMBvrzowMY6bXQ/fzclFeo+NxRfNIbagwb7i56BCeI99imQuoG6XFaVl1Ge5WGVPHEqQalsaKNLwXRdVSP9EcjTfHGax7oC+aX8IQT1XTcBJRiGHDpJzS3zKb5xbewL4geNAHcf5cRqZw3QeDZcu96o2I/3HojKhK7f7mx0gc+JDdLLeMNaUB14XKS3+eK+xWVczLhuPOmH/AlrPa/aHHo2HC47i1/0g5Hj4QqRp3sxulsW+XNFoifMB7axfLGe4R+xHME1u/THOFxWdnFxVSWCOOr7emssMgVAse1idJCSSTxvGt9tzn5PwkCdhPcUIEj7cNjq7nF912PrxXDq+6P5HGaX3jVDmWf/0Z8JGQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: wavestone.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d55effe4-4fd4-4f4c-61f7-08d61ca93667
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2018 14:24:00.6518 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5de96c96-c87c-4dce-aad9-f5c557b52ac1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0302MB2582
Archived-At: 
Subject: Re: [OAUTH-WG] Inconsistent error responses between 6749 and 6750
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: Mon, 17 Sep 2018 14:24:08 -0000

Hi Fletcher,

Actually we are not in the same case.
The /token endpoint is a protected ressource in regard to the client applic=
ation. The credentials are the client id and, in the case of confidential c=
lients, the client secret .
The OAuth 2.0 ressource is protected in regard to the user. The credential =
is the AT.

If your client id and your client secret are right, you are allowed to call=
 the /token endpoint. The content of the request is a different matter.

Regards,


-----Message d'origine-----
De : OAuth  De la part de George Fletcher
Envoy=E9 : lundi 17 septembre 2018 15:46
=C0 : oauth@ietf.org
Objet : [OAUTH-WG] Inconsistent error responses between 6749 and 6750

Hi,

It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the HT=
TP status code that should be returned when a requested scope is "invalid".

For example, if a call is make to the /token endpoint to obtain a new acces=
s_token and the scopes requested are outside those issued to the refresh_to=
ken, RFC 6749 says the HTTP status code returned should be 400 (Bad Request=
).

However, if an access token is presented to an OAuth2 protected resource an=
d the access token does not contain the necessary scope, RFC 6750 says the =
HTTP status code returned should be 403 (Forbidden).

Does anyone remember if this is intentional? The two cases here are pretty =
equivalent semantic-wise.

Thanks,
George

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
The information transmitted in the present email including the attachment i=
s intended only for the person to whom or entity to which it is addressed a=
nd may contain confidential and/or privileged material. Any review, retrans=
mission, dissemination or other use of, or taking of any action in reliance=
 upon this information by persons or entities other than the intended recip=
ient is prohibited. If you received this in error, please contact the sende=
r and delete all copies of the material.

Ce message et toutes les pi=E8ces qui y sont =E9ventuellement jointes sont =
confidentiels et transmis =E0 l'intention exclusive de son destinataire. To=
ute modification, =E9dition, utilisation ou diffusion par toute personne ou=
 entit=E9 autre que le destinataire est interdite. Si vous avez re=E7u ce m=
essage par erreur, nous vous remercions de nous en informer imm=E9diatement=
 et de le supprimer ainsi que les pi=E8ces qui y sont =E9ventuellement join=
tes.


From nobody Mon Sep 17 08:18:04 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 56679130E14 for ; Mon, 17 Sep 2018 08:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 pJvLQYHqZT67 for ; Mon, 17 Sep 2018 08:18:00 -0700 (PDT)
Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.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 5BA5F130934 for ; Mon, 17 Sep 2018 08:18:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1537197479; bh=7oQrh0gpjEkdwjCLhzvtFp9oo36djhCEtp4TBjE9cBU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=gTP4AgyYrcAygb4Nm11sFGcbHALLrY9MmpFUebUQaSXiHFKrkf74IFmhchpHCNUQur8u/qLuYrNaLjvrUgGM/CfX3ZuykLAIeb9mA+jWOch9AqhDo95/+TEIJ22lNDMKE9Q9DpsfOYuqz3mptFP5NDBBDI41D89oIlx2Lhz8Xf4xrnDrPKPtpmoyRMI/lD5ufH99lqKKHlxaXltmXVzHjoRZZUUrC5+KSuoR5FwcH0v44n4kmlQZbBefVtABc3HckyPZx8J861feiN+nDpUrBAcF+VcN8dUN/G3Kec4ZOZX8diZDIblrll6Ip3UTXPOewHz2CTYIO47jyq37nB7RYw==
X-YMail-OSG: 1CqK_oUVM1lNQ.8J7rlGjqqCGJNvbXy6ve0ym3SWFiGPw4Oel0Pj75KiMcdXiZh nz6qm7aO.DV2KERMJvypCejINWpfiEWurbB7AQE.fg1n0uHYi8bTw0OWqdBSm7bIPL0oxsNZkHvY OIRXsHy4SSOG0qquT_nRGdkSpW8AEY6zkK5XKIg6IXHX573OSXB0d4fn_nFcv_ntu8kzDtKNAykh kjF7Xk9ya_nP3Rzh6UeNc98f7fnRoA4_TyO0.B3LYzTGtE4G8PQbyLgqkK70l8XIxXRnsVfcsWfX JKQMnon_ZIjJivF2y5hle9X1LT_iLRQexUbDDrkCNjde0taYN_dH.Ja8XcZodmrlKckaN9aUBx4j AcZ3wkmcZVBSWFO3WeUtJbdVS30ZTxZdSeEtTN5oIQYecHkoVGii0Act0lptQyvxhJILjeh6iCse AeQNAvqRG.dSXVOXt1801SDEhMIPPZUNvcDXjucXb2SzrMCBjY_8ra1KfoHDHOIb0n6ew5q4Im5A qJE2V0RTUtE0cg7jhEToi8f.B_tpp5q5g5t0zu.fo7PwBC72JtNVvBV0gn_PAa5FX._8G.Dkuhkr eMV6P7yVGOkqsu813PzGdxK7U6lUvApt5WS9iVy4whgPG5VLUlszZZvf62rbUdzYXH_vCaGpPJ3X WenCAd9wxncSD_xTtXt9iD2lUDTKO7Bzy48V76tDZV5pvZo50GeLmn3Fk1Fl_voKKvd6vIx5uNAm eRp7msqF869Q42rBd9Begqcjf_u5nbcCl7mGM9MQZfC30pHTRn76zxHgCwlcrF4XRfvSEwRzv_AM U9ny0o41UrH0u2eFgDRv9b8GWB_GaHRBYQSeOF7CERRtiL3nEezdjBY0UM5tFO_UTFJnqjc0KZMD n19CYaCvx_wOt3eZuz2CkUeDfki62jrnrtqWmDWbWAs5cxGeRqeMUqX36lHCmAtHbrdnp0hs8UGn KcS7kt8q7gnWyX7SkYWV2Ajqf4m1UjvnIukN01eDxNYCH0iMoQyAdb4s3wJN9NIb8dDDtut5Jjg- -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Mon, 17 Sep 2018 15:17:59 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bb07bcb77d108e86493a50f0ff736457;  Mon, 17 Sep 2018 15:07:57 +0000 (UTC)
To: Thomas Broyer 
Cc: "oauth@ietf.org" 
References: <3a2a08f0-28bf-fe53-d571-025dcb196c2f@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: 
Date: Mon, 17 Sep 2018 11:07:56 -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="------------80E0A06DF3E8371B4C1DD0EF"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Inconsistent error responses between 6749 and 6750
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: Mon, 17 Sep 2018 15:18:02 -0000

This is a multi-part message in MIME format.
--------------80E0A06DF3E8371B4C1DD0EF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 9/17/18 10:22 AM, Thomas Broyer wrote:
>
>
> On Mon, Sep 17, 2018 at 3:46 PM George Fletcher 
> > 
> wrote:
>
>     Hi,
>
>     It appears that RFC 6749 and RFC 6750 are inconsistent in regards
>     to the
>     HTTP status code that should be returned when a requested scope is
>     "invalid".
>
>     For example, if a call is make to the /token endpoint to obtain a new
>     access_token and the scopes requested are outside those issued to the
>     refresh_token, RFC 6749 says the HTTP status code returned should
>     be 400
>     (Bad Request).
>
>     However, if an access token is presented to an OAuth2 protected
>     resource
>     and the access token does not contain the necessary scope, RFC
>     6750 says
>     the HTTP status code returned should be 403 (Forbidden).
>
>     Does anyone remember if this is intentional? The two cases here are
>     pretty equivalent semantic-wise.
>
>
> How so‽
>
> In the first case, you have a valid refresh_token and want to obtain 
> an access_token out of it. Assuming the client correctly 
> authenticated, it is authorized to make this request, but the request 
> is then rejected due to its payload/content. It could equally be a 
> 422: the reason it's rejected is not about authentication or 
> authorization, but because it's a "bad request", it's "semantically 
> wrong".
>
> In the second case, the token is used to authorize the request at the 
> RS, whatever the semantics of the request is (once authorized). If the 
> token is valid but doesn't authorize the request, then a 403 is 
> appropriate.
I see your point, but I guess I see it a little differently... in the 
first case, the requests fails because the request is not authorized 
based on the specified parameters. Because the requested scope is not 
authorized by the supplied refresh_token, the request is not really a 
"Bad Request" in the sense that incorrect parameters were supplied. All 
the parameters are correct and have valid values. However, the values 
supplied are not allowed by the Authorization Server. Basically the 
request fails the AS authorization policy. Maybe there is a fine-grain 
nuance in how authorization failures are returned:)

That said, the AS can legally return a 400 even if the client 
authentication credentials are invalid if the authentication credentials 
are specified as parameters rather than in the Authorization header. So 
in reality, the only time the /token endpoint MUST return anything other 
than a 400 is if the client credentials are both specified in the 
Authorization header AND invalid.

Thanks,
George

--------------80E0A06DF3E8371B4C1DD0EF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 9/17/18 10:22 AM, Thomas Broyer
      wrote:

    

    

      
      


        

        

          
On Mon, Sep 17, 2018 at 3:46 PM George Fletcher
            <gffletch=40aol.com@dmarc.ietf.org>
            wrote:

          

          
Hi,

            

            It appears that RFC 6749 and RFC 6750 are inconsistent in
            regards to the 

            HTTP status code that should be returned when a requested
            scope is 

            "invalid".

            

            For example, if a call is make to the /token endpoint to
            obtain a new 

            access_token and the scopes requested are outside those
            issued to the 

            refresh_token, RFC 6749 says the HTTP status code returned
            should be 400 

            (Bad Request).

            

            However, if an access token is presented to an OAuth2
            protected resource 

            and the access token does not contain the necessary scope,
            RFC 6750 says 

            the HTTP status code returned should be 403 (Forbidden).

            

            Does anyone remember if this is intentional? The two cases
            here are 

            pretty equivalent semantic-wise.

          

          


          

          
How so‽

          


          

          
In the first case, you have a valid refresh_token and
            want to obtain an access_token out of it. Assuming the
            client correctly authenticated, it is authorized to make
            this request, but the request is then rejected due to its
            payload/content. It could equally be a 422: the reason it's
            rejected is not about authentication or authorization, but
            because it's a "bad request", it's "semantically wrong".

          


          

          
In the second case, the token is used to authorize the
            request at the RS, whatever the semantics of the request is
            (once authorized). If the token is valid but doesn't
            authorize the request, then a 403 is appropriate.

        

      

    

    I see your point, but I guess I see it a little differently... in
    the first case, the requests fails because the request is not
    authorized based on the specified parameters. Because the requested
    scope is not authorized by the supplied refresh_token, the request
    is not really a "Bad Request" in the sense that incorrect 
    parameters were supplied. All the parameters are correct and have
    valid values. However, the values supplied are not allowed by the
    Authorization Server. Basically the request fails the AS
    authorization policy. Maybe there is a fine-grain nuance in how
    authorization failures are returned:)

    

    That said, the AS can legally return a 400 even if the client
    authentication credentials are invalid if the authentication
    credentials are specified as parameters rather than in the
    Authorization header. So in reality, the only time the /token
    endpoint MUST return anything other than a 400 is if the client
    credentials are both specified in the Authorization header AND
    invalid.

    

    Thanks,

    George

  


--------------80E0A06DF3E8371B4C1DD0EF--


From nobody Mon Sep 17 12:40:00 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 40C89130EAB for ; Mon, 17 Sep 2018 12:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tqpX7kGp782R for ; Mon, 17 Sep 2018 12:39:56 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 6DAD8130EAA for ; Mon, 17 Sep 2018 12:39:56 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id k12-v6so20036335oiw.8 for ; Mon, 17 Sep 2018 12:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=5dxzpSQFvCISeaDM8cpuMYfzhYdSu9Q9d8O+shKvcNU=; b=u88DnUolTPyap/QOURsx29JAvZrTxCfGvXz31nB6bwNvnkTsc/IHjntYvi94NwJgG5 7MPMe13/3XRHlcxRYWa6U2JyBKpEQoshRun0z1LV1Uu1VAttEL5ThcfiQdWD9s45XNAt HARimi9G6QnLx5P+bBn3i/MauG/4ZGcnZFYk9nsmgKz8n3Tcrw2KeDwJS9isOqHwjmg4 vsIfN0h372ouGXXrLf/IwM40qyvJiIts6pAQyG5TO8CwQblvVbXUXtGqVwdDW/vAi0Gi 3e0fMtUZLP+OJWNtRMv9PIYiMzcTIjVHYAZ3WBahPlWrN+b+zrdm9Kf3F3cRXThAvZtb cm6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5dxzpSQFvCISeaDM8cpuMYfzhYdSu9Q9d8O+shKvcNU=; b=uD14eE9fHd8mXSU0j+z4GjWa+rHNJkFkUIaoEP+u9Ay/5pIOEuHzQ+cuvW6OaSQsVi CcPD9wPhi9T6IGgAE4xkSje1gaHVNBmO/tMp37se0uXKlotyoaV6URAQvZ4263aTHvaf n+Srrq6recy6XxLgOi/VqBKWckq1eJlwJ5Kf3dfyvAYBioZPd2BWRzrdkRL83ub2EoYH H5EjoUT3usNi+oW4SR97ziZdZLDmD7kaS0YUGPp1rrO0BmqfztDywgeBd1FmD1EwzYMc zC5Arspts2BAybXsM5AMHOePmrUOBknrEgsu8un3Y9ZKejBnvkONmj21gOC2cC35BOmD rl5Q==
X-Gm-Message-State: APzg51CRQv1913Odg66mGYgUzIs7BhxCk5/UlR77jZ2RMPEsIqDdtffm 1dKY5jiGO6dkT0c1HS4gBONY6WIrd0JkOrWqCEscHf+w
X-Google-Smtp-Source: ANB0VdZ/p7wIR3fny55NeYGjT9p26n5lOlAmPCTqs7iQqTXAVb1cw5Lz/tjNvA9/geolc4A3VgO2Hrkdv6aztCOFETw=
X-Received: by 2002:aca:e250:: with SMTP id z77-v6mr120626oig.95.1537213195463;  Mon, 17 Sep 2018 12:39:55 -0700 (PDT)
MIME-Version: 1.0
From: Omer Levi Hevroni 
Date: Mon, 17 Sep 2018 22:39:44 +0300
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000075b63c0576165669"
Archived-At: 
Subject: [OAUTH-WG] Presenting Seamless Flow at IETF 103
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: Mon, 17 Sep 2018 19:39:58 -0000

--00000000000075b63c0576165669
Content-Type: text/plain; charset="UTF-8"

Hey
My name is Omer, and I want to ask a time to present a draft I'm working on
at IETF 103. This is a new oauth extension, that suppose to allows devices
to authenticate without any user interaction. There are many use cases,
especially in IoT world, where there are devices which need a strong
authentication solution - but does not have an option for any kind of user
interaction. This flow intends to allow them to achieve this.
The current version of the draft can be found here:
https://tools.ietf.org/html/draft-hevroni-oauth-seamless-flow-01. Feedback
on the draft is highly appreciated.

Thanks,
Omer

--00000000000075b63c0576165669
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey
My name is Omer, and I want to as=
k a time to present a draft I'm working on at IETF 103. This is a new o=
auth extension, that suppose to allows devices to authenticate without any =
user interaction. There are many use cases, especially in IoT world, where =
there are devices which need a strong authentication solution - but does no=
t have an option for any kind of user interaction. This flow intends to all=
ow them to achieve this.=C2=A0
The current version of the draft c=
an be found here:=C2=A0https://tools.ietf.org/html/draft-hevroni-oauth-se=
amless-flow-01. Feedback on the draft is highly appreciated.=C2=A0

Thanks,
Omer



--00000000000075b63c0576165669--


From nobody Mon Sep 17 18:29: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 9062C130E85 for ; Mon, 17 Sep 2018 18:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 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, SPF_PASS=-0.001, 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 ygLYF68bVtu2 for ; Mon, 17 Sep 2018 18:29:44 -0700 (PDT)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.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 83E08130E05 for ; Mon, 17 Sep 2018 18:29:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.53,387,1531749600";  d="scan'208,217";a="131529635"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 18 Sep 2018 11:29:37 +1000
Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 18 Sep 2018 11:29:37 +1000
Received: from wsapp6782.srv.dir.telstra.com (10.75.131.37) by wsmsg3757.srv.dir.telstra.com (172.49.40.85) with Microsoft SMTP Server (TLS) id 8.3.485.1; Tue, 18 Sep 2018 11:29:37 +1000
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp6782.srv.dir.telstra.com (10.75.131.37) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Sep 2018 11:29:35 +1000
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 18 Sep 2018 11:29:35 +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=XkKpII49DolQRzdyTcFRTYNf/h692Ok2/vufmX46GM0=; b=NN65cGhLw4bpsXTaL6a/sbQ6ULgUztvBdvp6Sh8ajTrT72frdTFb8bTfBL8x62rcivH8BHMQg91uZr/TMueC6ii1383juQo4MBGxYmVHz+/yOI1/9Hxcsmd7flUj82lpYpP0f7liMsvKS0xAYhB4lbUqEwIqYPvUA0aMNbh0Nj8=
Received: from MEAPR01MB3542.ausprd01.prod.outlook.com (52.134.216.9) by MEAPR01MB3078.ausprd01.prod.outlook.com (52.134.200.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.15; Tue, 18 Sep 2018 01:29:34 +0000
Received: from MEAPR01MB3542.ausprd01.prod.outlook.com ([fe80::f55b:7a8b:68ed:5b83]) by MEAPR01MB3542.ausprd01.prod.outlook.com ([fe80::f55b:7a8b:68ed:5b83%2]) with mapi id 15.20.1143.014; Tue, 18 Sep 2018 01:29:34 +0000
From: "Manger, James" 
To: Omer Levi Hevroni , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Presenting Seamless Flow at IETF 103
Thread-Index: AQHUTr5KQNSrG49g3k+c9huo1V6foKT1Gtdg
Date: Tue, 18 Sep 2018 01:29:34 +0000
Message-ID: 
References: 
In-Reply-To: 
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
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; 
x-originating-ip: [203.35.9.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MEAPR01MB3078; 6:4CwzOWmjynBiDwjDAEfEh5f1SeRzcQpPP3t5W/8eCB9dWwybnawPLz4yvxoX+4EGfPnCdKWsyTy9OmEoKkXD6Uq/+wOeGhMpAK3CCqWNeAO6M89jR6TlPb/bjd6l4sfwUteqEwqngVjLu/wv1t0qM94tkro69ldLTYKPq1EErhihcw/eu2qrlDxO949eloShmZJS67baOVQ5MYJCKw9X197A4ZPVsJXXeEffMTDR7xOWlxcYCNp8fCMjMlyI3XUw1ZZCydZ5q+UUS+TWqhG+7BgUspLlNAS6OjpMvhTgcfWHtU7XePz0geHXlSQ0gItBPZR8S8B0sAhmUh2CQhIqZkh6GbM9NRNvhQqYJPJCQFiKVD1y6YzS3m92XiBJ7Uz7JByzAojlgN1/XHhKppQ5K2lOrIamkGqtITHzEbu2624ey9izzlPl7QACzRuQJXg2CZFb20AThQeFUHPNt7cw5Q==; 5:wFDh0o0fAkK0EFEvzw3JC9aTRVVBk9flqb0gWTVcj2sari33RRM5VE6BYVuIjeENYAMrvt8gjZ9jXj2h48H28etEE7bcmR0pF+bEPyxSdH10B5E97S9+l/xKly2V/NpnASttNg2otfAHgU1H8L/+Vrhi5+HI3HhWL+90JPPXomw=; 7:peNRSSGJJPy6pYYyT5VhMW7A+WCmttdlUylZ8UCFAEW5atTqcEr2DbaG9iYQ35ZcMlkAFRxEnK+NsfKtUngQqSVEWj2tWcZtwzmMlKRmJ237PBph6DCw2m4JBsnA8J8RpVmLgo2m6wCa9mpKJBiVzooTaNATXiFYSJsP3xrJfChy1D+Lf5GVQpz7EEfGgQAvK3Y3Yc+DMRmn/3exbJmMsU63aF1aMQlRMgnKLK22erLtmZncb6J1lgfgZgcFZhPY
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 603ae083-18d7-43f1-6d86-08d61d0630c3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MEAPR01MB3078; 
x-ms-traffictypediagnostic: MEAPR01MB3078:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699050); SRVR:MEAPR01MB3078; BCL:0; PCL:0; RULEID:; SRVR:MEAPR01MB3078; 
x-forefront-prvs: 0799B1B2D7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39860400002)(136003)(366004)(189003)(199004)(97736004)(66066001)(606006)(2906002)(86362001)(6116002)(6246003)(33656002)(2900100001)(3846002)(790700001)(25786009)(256004)(5250100002)(229853002)(2501003)(39060400002)(14444005)(236005)(55016002)(74316002)(105586002)(5660300001)(81156014)(72206003)(555904003)(316002)(7696005)(8936002)(478600001)(99286004)(7736002)(76176011)(8676002)(68736007)(9686003)(54896002)(53936002)(486006)(446003)(53546011)(102836004)(110136005)(476003)(6436002)(6306002)(81166006)(966005)(11346002)(14454004)(551544002)(186003)(26005)(6506007)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:MEAPR01MB3078; H:MEAPR01MB3542.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: XSFDeFeR6+0K6J5MwDNMt0Zr8b9kyDPnmCezqTXu0/ZqKxSn8sKkdIaP7jpuoTGuw5m6SrTzvtuJFIFWDqIiY4WppaoSYnnk2i0Tr3JewOCqgwY+mqRc2clqXJjOB1X4+P8+Hyt4ekb2ExQyDRGqnXja0IqgIKVTaTkWuEZj8ilHGeYwGJu955sCGmG3ExI9yy+WQ+dw6bk2hBXAUlljlBJoSrIjz/kMJLu1plrGH6IEt9pyqEFNULRG7T5TTfY/6lVVbUQ6JmfdCOnOyeVt5dqArfQV6FABdTL/WgynXG+M9llTJSHgk5zrkwcLnjtPKl27EtTAfcjkiTUIoxTTDVFaVLvsOq7OfwE6o2e/GDI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MEAPR01MB35421E299BCFE78D19951749E51D0MEAPR01MB3542ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 603ae083-18d7-43f1-6d86-08d61d0630c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2018 01:29:34.4046 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB3078
X-OriginatorOrg: team.telstra.com
Archived-At: 
Subject: Re: [OAUTH-WG] Presenting Seamless Flow at IETF 103
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, 18 Sep 2018 01:29:47 -0000

--_000_MEAPR01MB35421E299BCFE78D19951749E51D0MEAPR01MB3542ausp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q29tbWVudHMgb24gZHJhZnQtaGV2cm9uaS1vYXV0aC1zZWFtbGVzcy1mbG93LTAxOg0KDQpUaGlz
IGRyYWZ0IHNlZW1zIHRvIGJlIGFib3V0IG1ha2luZyBjcnlwdG8gc2lnbmF0dXJlcyBzdGF0ZWZ1
bCBzbyB5b3UgaGF2ZSBhIGJldHRlciBjaGFuY2Ugb2YgZGV0ZWN0aW5nIGEgY2xvbmVkIGtleSBh
cyBpdHMgc3RhdGUgd2lsbCBkaXZlcmdlIGZyb20gdGhlIG9yaWdpbmFsLg0KVGhlIGxpbmsgdG8g
YSBzZWFtbGVzcyBPQXV0aCBmbG93IHNlZW1zIHRhbmdlbnRpYWwuDQoNCkEgbW9yZSBjb21tb24g
d2F5IHRvIG1ha2Ugc2lnbmF0dXJlcyBzdGF0ZWZ1bCBpcyB0byBhZGQgYSBjb3VudGVyLiBBIGNv
dW50ZXIgaXMgbW9yZSBwcmVkaWN0YWJsZSB0byBhbiBhdHRhY2tlciwgYnV0IGl0IGFsc28gYWxs
b3dzIHNvbWUgcmVjb3ZlcnkgZnJvbSBhbiBvY2Nhc2lvbmFsIG91dGFnZSB0aGF0IGxvc2VzIG9u
ZSBzaWduYXR1cmUgKGVnIGFjY2VwdCBvbmx5IHRoZSB2ZXJ5IG5leHQgY291bnRlciB2YWx1ZSwg
b3IgYmUgYSBiaXQgbGVuaWVudCBhbmQgYWNjZXB0IGEgY291bnRlciB2YWx1ZSBhcyBsb25nIGFz
IGl0IGRvZXNu4oCZdCByZXBlYXQgb3IgZ28gYmFja3dhcmQpLg0KDQpBbiBhdHRhY2tlciB3aG8g
Y2xvbmVzIGEga2V5IGNhbiBmb3JnZSBhbnkgbnVtYmVyIG9mIHNpZ25hdHVyZXMgd2hlbmV2ZXIg
dGhleSBzZWUgMSBzaWduYXR1cmUgZnJvbSB0aGUgb3JpZ2luYWwgdXNlcjoganVzdCByZS11c2Ug
dGhlIHNhbWUg4oCcbmV4dOKAnSB2YWx1ZSAob3Igc2VuZCBhIGJ1bmNoIG9mIHNpZ25hdHVyZSB3
aGVyZSB0aGUgbGFzdCBvbmUgcmUtdXNlcyB0aGUgb3JpZ2luYWwg4oCcbmV4dOKAnSB2YWx1ZSku
DQoNCg0KDQoqIOKAnEVhY2ggb2YgdGhvc2UgbnVtYmVycyBjYW4gaG9sZCBzaWduZWQgaW50LCB1
cCB0byA2NCBieXRlcyBsZW5ndGjigJ0NCjY0IGJ5dGVzIG9yIDY0IGJpdHM/DQpJZiB5b3UgYXJl
IHVzaW5nIGludGVnZXJzIGluIEpTT04geW91IGJldHRlciBzdGljayB0byA1My1iaXRzLCB3aGlj
aCB0aGUgbGltaXQgZm9yIGV4YWN0IGludGVnZXJzIGluIGEgNjQtYml0IGZsb2F0IFtSRkM3NDkz
IEktSlNPTjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQ5MyNzZWN0aW9uLTIuMj5d
Lg0KQnV0IGluIHRoaXMgc2l0dWF0aW9uIHlvdSBzaG91bGQganVzdCB1c2Ugc3RyaW5ncy4gQWxs
IHlvdSBhcmUgdXNpbmcgaXMgcmFuZG9tbHkgY2hvc2VuIHByZXZpb3VzIGFuZCBuZXh0IHZhbHVl
cyB0aGF0IHlvdSBjYW4gZG8gZXF1YWxpdHkgbWF0Y2hpbmcgb24uDQoNCg0KKiDigJxjbGllbnQt
aWTigJ0NCllvdSBhbHJlYWR5IGhhdmUgYSBrZXktaWQgZm9yIHRoZSBKV1Mgc2lnbmluZyBrZXkg
c28gSeKAmW0gbm90IHN1cmUgd2hhdCBleHRyYSBhIGNsaWVudC1pZCBqdXN0IGZvciB0aGUgcHJl
di9uZXh0IHN0YXRlIGFkZHMuDQoNCiog4oCccHJldmlvdXPigJ0sIOKAnG5leHTigJ0sIOKAnGN1
cnJlbnTigJ0sIOKAnG5ld+KAnQ0KSSB0aGluayA0IGxhYmVscyBhcmUgdXNlZCBmb3IgMiBxdWFu
dGl0aWVzLg0KDQoNCiogUkZDMjI4OSBBIE9uZS1UaW1lIFBhc3N3b3JkIFN5c3RlbTxodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjI4OT4NCkFyZSB5b3UgYWN0dWFsbHkgdXNpbmcgdGhl
IHJlZmVyZW5jZWQgUkZDMjI4OSAodGhhdCBzZWVtcyB0byB1c2UgSChIKEgoSCjigKZIKHBhc3N3
b3JkICsgY2hhbGxlbmdlICsgc3R1ZmYp4oCmKSkpKSk/DQpJIGRvbuKAmXQgdGhpbmsgc28uIEkg
dGhpbmsgeW91IGFyZSB1c2luZyBub3JtYWwgY3J5cHRvIHNpZ25pbmcga2V5cywgcGx1cyBhIHJh
bmRvbSBub25jZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPbWVyIExldmkgSGV2cm9uaQ0KU2Vu
dDogVHVlc2RheSwgMTggU2VwdGVtYmVyIDIwMTggNTo0MCBBTQ0KVG86IG9hdXRoQGlldGYub3Jn
DQpTdWJqZWN0OiBbT0FVVEgtV0ddIFByZXNlbnRpbmcgU2VhbWxlc3MgRmxvdyBhdCBJRVRGIDEw
Mw0KDQpIZXkNCk15IG5hbWUgaXMgT21lciwgYW5kIEkgd2FudCB0byBhc2sgYSB0aW1lIHRvIHBy
ZXNlbnQgYSBkcmFmdCBJJ20gd29ya2luZyBvbiBhdCBJRVRGIDEwMy4gVGhpcyBpcyBhIG5ldyBv
YXV0aCBleHRlbnNpb24sIHRoYXQgc3VwcG9zZSB0byBhbGxvd3MgZGV2aWNlcyB0byBhdXRoZW50
aWNhdGUgd2l0aG91dCBhbnkgdXNlciBpbnRlcmFjdGlvbi4gVGhlcmUgYXJlIG1hbnkgdXNlIGNh
c2VzLCBlc3BlY2lhbGx5IGluIElvVCB3b3JsZCwgd2hlcmUgdGhlcmUgYXJlIGRldmljZXMgd2hp
Y2ggbmVlZCBhIHN0cm9uZyBhdXRoZW50aWNhdGlvbiBzb2x1dGlvbiAtIGJ1dCBkb2VzIG5vdCBo
YXZlIGFuIG9wdGlvbiBmb3IgYW55IGtpbmQgb2YgdXNlciBpbnRlcmFjdGlvbi4gVGhpcyBmbG93
IGludGVuZHMgdG8gYWxsb3cgdGhlbSB0byBhY2hpZXZlIHRoaXMuDQpUaGUgY3VycmVudCB2ZXJz
aW9uIG9mIHRoZSBkcmFmdCBjYW4gYmUgZm91bmQgaGVyZTogaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWhldnJvbmktb2F1dGgtc2VhbWxlc3MtZmxvdy0wMS4gRmVlZGJhY2sgb24g
dGhlIGRyYWZ0IGlzIGhpZ2hseSBhcHByZWNpYXRlZC4NCg0KVGhhbmtzLA0KT21lcg0KDQo=

--_000_MEAPR01MB35421E299BCFE78D19951749E51D0MEAPR01MB3542ausp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z
dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUFVO30NCnNwYW4uZ3JleQ0K
CXttc28tc3R5bGUtbmFtZTpncmV5O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m
YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w
cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Db21tZW50cyBvbiBkcmFmdC1oZXZyb25p
LW9hdXRoLXNlYW1sZXNzLWZsb3ctMDE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj5UaGlzIGRyYWZ0IHNlZW1zIHRvIGJlIGFib3V0IG1ha2luZyBjcnlwdG8gc2lnbmF0
dXJlcyBzdGF0ZWZ1bCBzbyB5b3UgaGF2ZSBhIGJldHRlciBjaGFuY2Ugb2YgZGV0ZWN0aW5nIGEg
Y2xvbmVkIGtleSBhcyBpdHMgc3RhdGUgd2lsbA0KIGRpdmVyZ2UgZnJvbSB0aGUgb3JpZ2luYWwu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBsaW5rIHRv
IGEgc2VhbWxlc3MgT0F1dGggZmxvdyBzZWVtcyB0YW5nZW50aWFsLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QSBtb3JlIGNvbW1vbiB3YXkgdG8gbWFrZSBzaWduYXR1
cmVzIHN0YXRlZnVsIGlzIHRvIGFkZCBhIGNvdW50ZXIuIEEgY291bnRlciBpcyBtb3JlIHByZWRp
Y3RhYmxlIHRvIGFuIGF0dGFja2VyLCBidXQgaXQgYWxzbyBhbGxvd3MNCiBzb21lIHJlY292ZXJ5
IGZyb20gYW4gb2NjYXNpb25hbCBvdXRhZ2UgdGhhdCBsb3NlcyBvbmUgc2lnbmF0dXJlIChlZyBh
Y2NlcHQgb25seSB0aGUgdmVyeSBuZXh0IGNvdW50ZXIgdmFsdWUsIG9yIGJlIGEgYml0IGxlbmll
bnQgYW5kIGFjY2VwdCBhIGNvdW50ZXIgdmFsdWUgYXMgbG9uZyBhcyBpdCBkb2VzbuKAmXQgcmVw
ZWF0IG9yIGdvIGJhY2t3YXJkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPkFuIGF0dGFja2VyIHdobyBjbG9uZXMgYSBrZXkgY2FuIGZvcmdlIGFueSBudW1iZXIgb2Yg
c2lnbmF0dXJlcyB3aGVuZXZlciB0aGV5IHNlZSAxIHNpZ25hdHVyZSBmcm9tIHRoZSBvcmlnaW5h
bCB1c2VyOiBqdXN0IHJlLXVzZSB0aGUNCiBzYW1lIOKAnG5leHTigJ0gdmFsdWUgKG9yIHNlbmQg
YSBidW5jaCBvZiBzaWduYXR1cmUgd2hlcmUgdGhlIGxhc3Qgb25lIHJlLXVzZXMgdGhlIG9yaWdp
bmFsIOKAnG5leHTigJ0gdmFsdWUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1
YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+KiDigJw8L3NwYW4+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5FYWNoIG9mIHRob3NlIG51bWJlcnMgY2FuIGhvbGQgc2ln
bmVkIGludCwgdXAgdG8gNjQgYnl0ZXMgbGVuZ3RoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igJ08L3NwYW4+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj42NCBieXRlcyBvciA2NCBiaXRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj5JZiB5b3UgYXJlIHVzaW5nIGludGVnZXJzIGluIEpTT04geW91IGJl
dHRlciBzdGljayB0byA1My1iaXRzLCB3aGljaCB0aGUgbGltaXQgZm9yIGV4YWN0IGludGVnZXJz
IGluIGEgNjQtYml0IGZsb2F0IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
cmZjNzQ5MyNzZWN0aW9uLTIuMiI+UkZDNzQ5Mw0KIEktSlNPTjwvYT5dLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CdXQgaW4gdGhpcyBzaXR1YXRpb24geW91
IHNob3VsZCBqdXN0IHVzZSBzdHJpbmdzLiBBbGwgeW91IGFyZSB1c2luZyBpcyByYW5kb21seSBj
aG9zZW4gcHJldmlvdXMgYW5kIG5leHQgdmFsdWVzIHRoYXQgeW91IGNhbiBkbyBlcXVhbGl0eQ0K
IG1hdGNoaW5nIG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4qIOKAnDwvc3Bhbj48c3BhbiBz
dHlsZT0iY29sb3I6YmxhY2siPmNsaWVudC1pZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+4oCdPC9zcGFuPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+WW91IGFscmVhZHkgaGF2ZSBhIGtleS1pZCBmb3IgdGhlIEpXUyBzaWduaW5nIGtleSBz
byBJ4oCZbSBub3Qgc3VyZSB3aGF0IGV4dHJhIGEgY2xpZW50LWlkIGp1c3QgZm9yIHRoZSBwcmV2
L25leHQgc3RhdGUgYWRkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
Piog4oCccHJldmlvdXPigJ0sIOKAnG5leHTigJ0sIOKAnGN1cnJlbnTigJ0sIOKAnG5ld+KAnTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIDQgbGFi
ZWxzIGFyZSB1c2VkIGZvciAyIHF1YW50aXRpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiog
PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIyODkiPlJGQzIyODkgPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tQVUiPkEgT25lLVRpbWUgUGFzc3dvcmQgU3lz
dGVtPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcmUgeW91IGFjdHVhbGx5IHVz
aW5nIHRoZSByZWZlcmVuY2VkIFJGQzIyODkgKHRoYXQgc2VlbXMgdG8gdXNlIEgoSChIKEgo4oCm
SChwYXNzd29yZCAmIzQzOyBjaGFsbGVuZ2UgJiM0Mzsgc3R1ZmYp4oCmKSkpKSk/PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgZG9u4oCZdCB0aGluayBzby4g
SSB0aGluayB5b3UgYXJlIHVzaW5nIG5vcm1hbCBjcnlwdG8gc2lnbmluZyBrZXlzLCBwbHVzIGEg
cmFuZG9tIG5vbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmFtZXMgTWFu
Z2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5PbWVyIExldmkgSGV2cm9uaTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCAx
OCBTZXB0ZW1iZXIgMjAxOCA1OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBvYXV0aEBpZXRmLm9yZzxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFByZXNlbnRpbmcgU2VhbWxlc3MgRmxvdyBh
dCBJRVRGIDEwMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
ZXk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBuYW1lIGlz
IE9tZXIsIGFuZCBJIHdhbnQgdG8gYXNrIGEgdGltZSB0byBwcmVzZW50IGEgZHJhZnQgSSdtIHdv
cmtpbmcgb24gYXQgSUVURiAxMDMuIFRoaXMgaXMgYSBuZXcgb2F1dGggZXh0ZW5zaW9uLCB0aGF0
IHN1cHBvc2UgdG8gYWxsb3dzIGRldmljZXMgdG8gYXV0aGVudGljYXRlIHdpdGhvdXQgYW55IHVz
ZXIgaW50ZXJhY3Rpb24uIFRoZXJlIGFyZSBtYW55IHVzZSBjYXNlcywgZXNwZWNpYWxseSBpbg0K
IElvVCB3b3JsZCwgd2hlcmUgdGhlcmUgYXJlIGRldmljZXMgd2hpY2ggbmVlZCBhIHN0cm9uZyBh
dXRoZW50aWNhdGlvbiBzb2x1dGlvbiAtIGJ1dCBkb2VzIG5vdCBoYXZlIGFuIG9wdGlvbiBmb3Ig
YW55IGtpbmQgb2YgdXNlciBpbnRlcmFjdGlvbi4gVGhpcyBmbG93IGludGVuZHMgdG8gYWxsb3cg
dGhlbSB0byBhY2hpZXZlIHRoaXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBj
YW4gYmUgZm91bmQgaGVyZTombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaGV2cm9uaS1vYXV0aC1zZWFtbGVzcy1mbG93LTAxIj5odHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaGV2cm9uaS1vYXV0aC1zZWFtbGVzcy1mbG93LTAxPC9hPi4gRmVl
ZGJhY2sgb24gdGhlIGRyYWZ0IGlzIGhpZ2hseSBhcHByZWNpYXRlZC4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T21lcjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_MEAPR01MB35421E299BCFE78D19951749E51D0MEAPR01MB3542ausp_--


From nobody Wed Sep 19 01:51:10 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 27C21130E58 for ; Wed, 19 Sep 2018 01:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 abwsWF3_bbkA for ; Wed, 19 Sep 2018 01:51:05 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 35568130FCA for ; Wed, 19 Sep 2018 01:51:00 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id f14-v6so7207114ita.4 for ; Wed, 19 Sep 2018 01:51:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=e3WAv5MDjsigqvivTUI/lUcXLnnRXIJ8AKmFZEl0mA4=; b=UmNx18ew21051LFPmq+U/E6pMbK8B35gXw1eOpaZmS0tWuT6X7JAL0wLmIVYfJBo3y chR1wLotRCue3EywlupAP1jYDy5yAzTDTOy8aN671FZvYdSkKXzew2sN81HV2JJx9Pzi LL1EVG4V+97UyZfKfe1b7K6CWKfydZLnYgmrY3sNTWhyFBQGeoJK+iawz1oupHAJLeiP gmS2CfbwBnCVNdg2pDqZm5muxZ+CBD5v7MwV14ArDijw5O/YrD3pdQ1EtVIBiX7cEmZd /6nypo9JIhg3/sjLr4d8jYlUxeg/UuWcvQg5ZuT7FKYS7+zBlqwiLWS+3N+JlwrmMEBI 0rgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e3WAv5MDjsigqvivTUI/lUcXLnnRXIJ8AKmFZEl0mA4=; b=cwGBeg+lBM6IFP1J08yGUEYIWDzOqfpRSQh8mZ1sK+8CFZZI+Nx73y2O83JlTBPqOw SOb1IcKrJBZsBuN4XxzMrL74ZRnfOKf88taUTouVv37HZqSe/1lmSiNTmrcHj0rsWz2h IglSRSJFEqucf4Moot6ZkvHNzX7GiawKSqKRQRR0iqdOoHOYXbVdc/WYrhVdA4thsAuH Q3ylRlaOCNEAAEipuAj1X135930Qt5tpxx9WHt7uhB5AjywHhfYAIM2sGcPIeaJunsIq WzkVU+C71Q6cDgjjT5HxDToWqdMRl3uitGTy+iah+WqZZjwzMNbB7g3lxNQcA52YYl5R TtNA==
X-Gm-Message-State: APzg51AyzH2SpLbgAuNIxOUX7zwX3DFi+npd4oB+T5tkmb5jx3pRvFtq UD8Vut9uBh1x0uyZdPhZk4h1XfmlBhAHHsoiYTq8bs4+IBM=
X-Google-Smtp-Source: ANB0VdaZElqsvXR2eNTDGOsWR0zS2N8hnZtvXKXj2paVQ1NAgLutFf86kLpItuDGxeLKWXUsAvn5soe+ci+9lS3Rapw=
X-Received: by 2002:a24:2ed4:: with SMTP id i203-v6mr19476763ita.114.1537347059097;  Wed, 19 Sep 2018 01:50:59 -0700 (PDT)
MIME-Version: 1.0
From: Rifaat Shekh-Yusef 
Date: Wed, 19 Sep 2018 04:50:48 -0400
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="0000000000005aa64f0576358151"
Archived-At: 
Subject: [OAUTH-WG] OAuth WG meeting in Bangkok
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, 19 Sep 2018 08:51:08 -0000

--0000000000005aa64f0576358151
Content-Type: text/plain; charset="UTF-8"

All,

So far we received requests for time-slots for the following topics:
- draft-ietf-oauth-security-topics
- draft-ietf-oauth-jwt-introspection-response
- openid-financial-api-jarm-wd
- draft-hevroni-oauth-seamless-flow

The deadline for scheduling a WG meeting is this coming Friday.
Any other requests?

Regards,
 Rifaat & Hannes

--0000000000005aa64f0576358151
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

So far we receive=
d requests for time-slots for the following topics:
- draft-=
ietf-oauth-security-topics=C2=A0
- draft-ietf-oauth-jwt-introspec=
tion-response
- openid-financial-api-jarm-wd
- draft-he=
vroni-oauth-seamless-flow

The deadline for s=
cheduling a WG meeting is this coming Friday.
Any other requests?=


Regards,
=C2=A0Rifaat & Hannes




--0000000000005aa64f0576358151--


From nobody Wed Sep 19 05:43:20 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 38B01130FCE for ; Wed, 19 Sep 2018 05:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 kcm805kV8e9X for ; Wed, 19 Sep 2018 05:43:17 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 1CA05130FD0 for ; Wed, 19 Sep 2018 05:43:17 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id h23-v6so7480035ita.5 for ; Wed, 19 Sep 2018 05:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x2S2NTnKfZvYgS83EOT8wtD5zmALxczTZMGKEUxaYkA=; b=VgUO3a9Z3Wxl2YJTjYCdCnnW/DfF5QDz0aIcxQ1DosE1qQbkQMcpiYWp/u1h99zAzn e7xNVNOu4VsMJ8pr7w7AFFfbyvYl8WcoJD2vujJQOqWeR2ouBJL0O3RoqxRk4E+WxhJB cY7Honn/FNLsM2yH1dD8Y+lS7HztamhplClvE=
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=x2S2NTnKfZvYgS83EOT8wtD5zmALxczTZMGKEUxaYkA=; b=sKZgPC7DIMNK9dtT3kcNTsWd1Py749ON3DmeKO4dXu+GbPIx/V12c2iHLF3pQfz4oj nAc3Se7bUfP0XqvxLmT6peO9BlA1IOWliXcWbGSZXLbp0NN3KrH3VaYp5H2hOB5NzkcM 6bJeEKSVDGAe6myzzMQSSP5q41vNaQRehV3PYQrQERfwceAB3vWwSEyCRuGRgJoJ1W+y bJmKqtkEaBJpG6q4k0nlBwFT5TBF31ZpHU9RdCEpGK5oXC4sgnoZ34cL0B8cVhuJC+f0 rhXF7l62jmr+qmcsXIJlWywxA34OIAMyWRUwNSF2G26U6gZOiYky3U5tH4TNnm5PMoOB e6rg==
X-Gm-Message-State: APzg51Aop5agER9HrxVcLsYmkpUOd626Xo1SmuDetisl8KQCVyT0p6u7 MMaVNCfCfgsN9sQYH1gNtbsmGV8iuuIJJ6nrxzN92yj9WkgTNe71jw1wqETE+KvfmAd0pYXXJV+ 3ysZvgyZ22nizrA==
X-Google-Smtp-Source: ANB0VdaioTWo8VDYDbLN4jOEzHiqzPzpgUIiKQ7x3ki2zbGbI0qrdPM3rmOA5nIoZq7wNwf05bvDAveQZ0VOvN5NPgY=
X-Received: by 2002:a24:b101:: with SMTP id o1-v6mr20168676itf.121.1537360996202;  Wed, 19 Sep 2018 05:43:16 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Brian Campbell 
Date: Wed, 19 Sep 2018 06:42:49 -0600
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000122fb2057638c055"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG meeting in Bangkok
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, 19 Sep 2018 12:43:19 -0000

--000000000000122fb2057638c055
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Apologies Rifaat (& Hannes), I hadn't yet gotten around to responding to
the initial request. But I would like to request time to present on the
following drafts in Bangkok:

https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/

Also I'd like to provisionally as for a bit of time on
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ and/or
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ to
provide a brief update on any relevant happenings as these two make their
way through IESG processing.

Thanks,


On Wed, Sep 19, 2018 at 2:51 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> So far we received requests for time-slots for the following topics:
> - draft-ietf-oauth-security-topics
> - draft-ietf-oauth-jwt-introspection-response
> - openid-financial-api-jarm-wd
> - draft-hevroni-oauth-seamless-flow
>
> The deadline for scheduling a WG meeting is this coming Friday.
> Any other requests?
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000122fb2057638c055
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ap=
ologies Rifaat (& Hannes), I hadn't yet gotten around to responding=
 to the initial request. But I would like to request time to present on the=
 following drafts in Bangkok:


Also I'd like to=
 provisionally as for a bit of time on https://datatracker.ietf.org/doc/draft-ietf=
-oauth-mtls/ and/or https://datatracker.ietf.org/doc/draft-ietf-oaut=
h-token-exchange/ to provide a brief update on any relevant happenings =
as these two make their way through IESG processing. 

Thanks,=C2=A0 


=

On Wed, Sep 19, 2018 at 2:51 AM=
 Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

So far =
we received requests for time-slots for the following topics:
- draft-ietf-oauth-security-topics=C2=A0
- draft-ietf-oauth-jwt=
-introspection-response
- openid-financial-api-jarm-wd
=
- draft-hevroni-oauth-seamless-flow

The dead=
line for scheduling a WG meeting is this coming Friday.
Any other=
 requests?

Regards,
=C2=A0Rifaat & H=
annes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000122fb2057638c055--


From nobody Wed Sep 19 06:31:51 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 69BA9130FF1 for ; Wed, 19 Sep 2018 06:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jk0E-Pn49jtb for ; Wed, 19 Sep 2018 06:31:48 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 58DF613106C for ; Wed, 19 Sep 2018 06:31:48 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id q5-v6so4482749iop.3 for ; Wed, 19 Sep 2018 06:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eQ7Bc20oradwmuWBRvs/xpEfKKpupT0YkDb8QrLna1g=; b=KPOoHrBBMXPlmeKgYykawnOuZm2sXgOkJSEPHIUF/AqiesgKYxjx1yDMe19fdTppL4 JiyntO/4HyFePf31smvUvTqHBDcNJTjagtORH+af2QjriRZN2Q+QFR0tO0yIOQsiWcA2 sjS5vETGDtN2xx5kyddi7SOdIGUO0kc9OX4JCy0d6uxiloNsNsPlF1vQNMNy+dgx+Zxm Cop62JCOtCWdgSafgPCmGVGpgQpnKxPvsCMIXdOUweXg7g6KVvv9Pf2eAGHm1qmQA/zA UNKrZdzshnJ8RS6jKuoWXOqvdAWKtFAGmqP1lZzrISF7foiTcWcXaGVSUgccQva0ru+n XEBA==
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=eQ7Bc20oradwmuWBRvs/xpEfKKpupT0YkDb8QrLna1g=; b=YssrK53bdy8uD7orP4KH+9LYOR32pReZgcYkz9ZkbQMUVTy1YXqdBOFzmVSm49wkW0 yt6Eyf5oDB4IRLd511b7xdARGJHglNFotC65yktl5p0D2wA6DzNWIfuZtwTEqGZ0o6cc VkqjoXxXtKwVXm99ypf5kWklTvmELkCUsqO2UBzwgBLb6jN3aCbMJvtjv/FcrcVXE0je GntcMi26fWTmJpwnnytAYif0NggEShYnK0xKb/BTzxiGOiPNYKQFQ8Y7Lk/5limOW7Ra JAVIUXwgtl3g3OR7occYqrT27K1taSqI/ZfTe4r1K2NTZG6wMn2ZbEIlxDdmKS/3CYVI PhPw==
X-Gm-Message-State: APzg51CqjA3bYXeoTk3vFz8HrHfZiOTTDy/zI5hLuIk3jYKHVHTjIhXq WUm8Fo+TAfqbSofQKfeSwFXU7lPB1ePWcBBSTCg=
X-Google-Smtp-Source: ANB0VdapVxNk604u1yGa4v+SOzEvMtGJ/EVarp7ts8Xu6LWw6MuXq9dM+VQHhO8qniOm5l5bR/k+yFm/bNFTSOtUIUU=
X-Received: by 2002:a6b:2353:: with SMTP id j80-v6mr27015784ioj.99.1537363907721;  Wed, 19 Sep 2018 06:31:47 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Wed, 19 Sep 2018 09:32:45 -0400
Message-ID: 
To: Brian Campbell 
Cc: oauth 
Content-Type: multipart/alternative; boundary="0000000000009c4b320576396d0a"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth WG meeting in Bangkok
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, 19 Sep 2018 13:31:50 -0000

--0000000000009c4b320576396d0a
Content-Type: text/plain; charset="UTF-8"

Noted. Thanks!

On Wed, Sep 19, 2018 at 8:43 AM Brian Campbell 
wrote:

> Apologies Rifaat (& Hannes), I hadn't yet gotten around to responding to
> the initial request. But I would like to request time to present on the
> following drafts in Bangkok:
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/
>
> Also I'd like to provisionally as for a bit of time on
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ and/or
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ to
> provide a brief update on any relevant happenings as these two make their
> way through IESG processing.
>
> Thanks,
>
>
> On Wed, Sep 19, 2018 at 2:51 AM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> So far we received requests for time-slots for the following topics:
>> - draft-ietf-oauth-security-topics
>> - draft-ietf-oauth-jwt-introspection-response
>> - openid-financial-api-jarm-wd
>> - draft-hevroni-oauth-seamless-flow
>>
>> The deadline for scheduling a WG meeting is this coming Friday.
>> Any other requests?
>>
>> Regards,
>>  Rifaat & Hannes
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

--0000000000009c4b320576396d0a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Noted. Thanks!

On Wed, Sep 19, 2018 at 8:43 AM Brian Campbell <bcampbell@pingidentity.com> wrot=
e:
Apologies Rifaat (& Hannes), I=
 hadn't yet gotten around to responding to the initial request. But I w=
ould like to request time to present on the following drafts in Bangkok:

https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/

Also I'd like to provisionally as for a bit of t=
ime on https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ and/or https://datatracker.ietf.org/doc/draft-ietf-=
oauth-token-exchange/ to provide a brief update on any relevant happeni=
ngs as these two make their way through IESG processing. 
Thanks,=C2=A0 

=

On Wed, Sep 19, 2018 at 2:5=
1 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
All,

So =
far we received requests for time-slots for the following topics:
- draft-ietf-oauth-security-topics=C2=A0
- draft-ietf-oauth=
-jwt-introspection-response
- openid-financial-api-jarm-wd
<=
div>- draft-hevroni-oauth-seamless-flow

The =
deadline for scheduling a WG meeting is this coming Friday.
Any o=
ther requests?

Regards,
=C2=A0Rifaat &am=
p; Hannes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.


--0000000000009c4b320576396d0a--


From nobody Thu Sep 20 05:49:29 2018
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3CA130F33; Thu, 20 Sep 2018 05:49:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: rifaat.ietf@gmail.com, ekr@rtfm.com, oauth-chairs@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153744776042.1931.3484531210664734089.idtracker@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 05:49:20 -0700
Archived-At: 
Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 103
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Sep 2018 12:49:28 -0000

A new meeting session request has just been submitted by Rifaat Shekh-Yusef, a Chair of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Rifaat Shekh-Yusef

Number of Sessions: 2
Length of Session(s):  1.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: secevent teep suit core tls ace tokbind saag




People who must be present:
  Eric Rescorla
  Hannes Tschofenig

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Thu Sep 20 09:47:03 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 71191130E69 for ; Thu, 20 Sep 2018 09:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Z2iaZl3RiWmr for ; Thu, 20 Sep 2018 09:46:58 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 298FF130E3D for ; Thu, 20 Sep 2018 09:46:58 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id l202-v6so8973516oig.7 for ; Thu, 20 Sep 2018 09:46:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GukHsR2vrC6Y+VH1z/PyIczArUTKhF4Vy8plu0GRLdM=; b=e8r4meRmS9tmqps9duewDVJlxa11EcNBqtD2EwL57bvCTXm5MbIbL1BfZRJOhz/cE7 K+11tqldJZzW+S/+dug7PtrZ7VsVhbt1XdQH2nCzdE4g1Fe1XHqjojoXH0Y4ahSURowN 7MmVY0kStaZMyluu8QYArFTZPNpHY0+R75JVWr403Po9JPjkZpe+TFkj3xLy9bk2c3ys Mw2D3P0m1XdCSQh1HpnFl7vhEaAIZS8Jm/H3H6qj+qYRtHjKDBOZ+JcD2mjmkLb4cpWH YXIagsshI69sxTqMIUo7DJg1dTckFqTSlyDLt5LYFQuRy1Oq6pFaIj0zlUxR1p5cFuHl tzKg==
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=GukHsR2vrC6Y+VH1z/PyIczArUTKhF4Vy8plu0GRLdM=; b=RV87Xtw/qKHXC2+yi9ZP4dTFPntuHRsA9G5yep4hogH9GdT1QNewiJHmFI5S5P3DjQ fMhwrbY4B29fxbFnrsgK1AXk6l7At9Ei6n3TLLEH9l1zRsvMpR95GAjv0IiyJd7mfeMk BwdO8DPFwvK4zuU0b+IwixRQZtiP7qmcRPiD/INbACrTVTew1hyZAH2UJz0vkOFKY1AD Qqk8Di4F5AC3CQJMgkSyftNcx3NA9+cvaTfYfPuSNBXPh5N+AUpaMh1KfJ9jKQExu8dj Wd7e7miBfUF6/jisOrz7FtgZCmeI9JsuWNKL6d5h8iHePzuqmtuEORta2D5yWK42RFlx Y99A==
X-Gm-Message-State: APzg51D0yDteBYZn4ai0qrRodLq8Il3gRXt1FU/SGCKzyWHOpI1XGnUA zzFSiKuYHthlfLdDAxQn1bI2M5JE78gCq+eeOJN+wozs
X-Google-Smtp-Source: ANB0Vdb7vzXKDPqDp66ajUCS3NWf7jHw3uS+nj5lqELFLfemxHlDLl4znCWs5G39k1P3ypeIZdMvtSUmrbYkyk4Bzpw=
X-Received: by 2002:aca:e250:: with SMTP id z77-v6mr2133596oig.95.1537462017348;  Thu, 20 Sep 2018 09:46:57 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Omer Levi Hevroni 
Date: Thu, 20 Sep 2018 19:46:45 +0300
Message-ID: 
To: James.H.Manger@team.telstra.com
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000665b7d05765045a3"
Archived-At: 
Subject: Re: [OAUTH-WG] Presenting Seamless Flow at IETF 103
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: Thu, 20 Sep 2018 16:47:01 -0000

--000000000000665b7d05765045a3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey James,
Thanks for the feedback!
Your counter suggestion is what called usually "Counter-based OTP". It
might not be clear from the draft, but using a counter can result in
devices that are locked-out. As you mentioned, this can be solved by a more
lenient server - but this also weakens the protocol. And as lenient as the
server can be, devices can still get out of sync. This draft aims to
propose an alternative OTP solution that is tolerant to out of sync devices
and allows a mechanism to unlock devices. Does this answer your question?
Should I clarify this in the draft?

64 bits/bytes - my mistake. I was referring to unsigned long, which is 4
bytes. I filed an issue
 - will fix later.
Client Id - This is the identifier of the device using this app, not the
key. Also, client id is a well-known term in OAuth and I preferred to use
it for clarification.
Previous/Next/Current/New - noted, will fix - I filled an issue
. Thanks!
One Time Password (or OTP) - I used it as a reference for the general idea
of OTP, not the specific algorithm
Seamless flow - name is temporary, and I'm open for suggestion. It comes to
clarify that it's a flow that allows "silent" login, without any
interaction. This is why I choose "seamless". Does this makes sense?

On Tue, Sep 18, 2018 at 4:29 AM Manger, James <
James.H.Manger@team.telstra.com> wrote:

> Comments on draft-hevroni-oauth-seamless-flow-01:
>
>
>
> This draft seems to be about making crypto signatures stateful so you hav=
e
> a better chance of detecting a cloned key as its state will diverge from
> the original.
>
> The link to a seamless OAuth flow seems tangential.
>
>
>
> A more common way to make signatures stateful is to add a counter. A
> counter is more predictable to an attacker, but it also allows some
> recovery from an occasional outage that loses one signature (eg accept on=
ly
> the very next counter value, or be a bit lenient and accept a counter val=
ue
> as long as it doesn=E2=80=99t repeat or go backward).
>
>
>
> An attacker who clones a key can forge any number of signatures whenever
> they see 1 signature from the original user: just re-use the same =E2=80=
=9Cnext=E2=80=9D
> value (or send a bunch of signature where the last one re-uses the origin=
al
> =E2=80=9Cnext=E2=80=9D value).
>
>
>
>
>
> * =E2=80=9CEach of those numbers can hold signed int, up to 64 bytes leng=
th=E2=80=9D
>
> 64 bytes or 64 bits?
>
> If you are using integers in JSON you better stick to 53-bits, which the
> limit for exact integers in a 64-bit float [RFC7493 I-JSON
> ].
>
> But in this situation you should just use strings. All you are using is
> randomly chosen previous and next values that you can do equality matchin=
g
> on.
>
>
>
> * =E2=80=9Cclient-id=E2=80=9D
>
> You already have a key-id for the JWS signing key so I=E2=80=99m not sure=
 what
> extra a client-id just for the prev/next state adds.
>
>
>
> * =E2=80=9Cprevious=E2=80=9D, =E2=80=9Cnext=E2=80=9D, =E2=80=9Ccurrent=E2=
=80=9D, =E2=80=9Cnew=E2=80=9D
>
> I think 4 labels are used for 2 quantities.
>
>
>
> * RFC2289 A One-Time Password System 
>
> Are you actually using the referenced RFC2289 (that seems to use
> H(H(H(H(=E2=80=A6H(password + challenge + stuff)=E2=80=A6)))))?
>
> I don=E2=80=99t think so. I think you are using normal crypto signing key=
s, plus a
> random nonce.
>
>
>
> --
>
> James Manger
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Omer Levi
> Hevroni
> *Sent:* Tuesday, 18 September 2018 5:40 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Presenting Seamless Flow at IETF 103
>
>
>
> Hey
>
> My name is Omer, and I want to ask a time to present a draft I'm working
> on at IETF 103. This is a new oauth extension, that suppose to allows
> devices to authenticate without any user interaction. There are many use
> cases, especially in IoT world, where there are devices which need a stro=
ng
> authentication solution - but does not have an option for any kind of use=
r
> interaction. This flow intends to allow them to achieve this.
>
> The current version of the draft can be found here:
> https://tools.ietf.org/html/draft-hevroni-oauth-seamless-flow-01.
> Feedback on the draft is highly appreciated.
>
>
>
> Thanks,
>
> Omer
>
>
>

--000000000000665b7d05765045a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey James,
Thanks for the =
feedback!=C2=A0
Your counter suggestion is what called usuall=
y "Counter-based OTP". It might not be clear from the draft, but =
using a counter can result in devices that are locked-out. As you mentioned=
, this can be solved by a more lenient server - but this also weakens the p=
rotocol. And as lenient as the server can be, devices can still get out of =
sync. This draft aims to propose an alternative OTP solution that is tolera=
nt to out of sync devices and allows a mechanism to unlock devices. Does th=
is answer your question? Should I clarify this in the draft?

=

64 bits/bytes - my mistake. I was referring to unsigned long, wh=
ich is 4 bytes. I filed an issue - will fix later.
Client Id - This i=
s the identifier of the device using this app, not the key. Also, client id=
 is a well-known term in OAuth and I preferred to use it for clarification.=

Previous/Next/Current/New - noted, will fix - I filled an issue. Tha=
nks!
One Time Password=C2=A0(or OTP) - I used it as a reference f=
or the general idea of OTP, not the specific algorithm
Seamless f=
low - name is temporary, and I'm open for suggestion. It comes to clari=
fy that it's a flow that allows "silent" login, without any i=
nteraction. This is why I choose "seamless". Does this makes sens=
e?

On Tue,=
 Sep 18, 2018 at 4:29 AM Manger, James <James.H.Manger@team.telstra.com> wrote:
=












Comments on draft-hevroni-oauth-seaml=
ess-flow-01:


=C2=A0


This draft seems to be about making c=
rypto signatures stateful so you have a better chance of detecting a cloned=
 key as its state will
 diverge from the original.


The link to a seamless OAuth flow see=
ms tangential.


=C2=A0


A more common way to make signatures =
stateful is to add a counter. A counter is more predictable to an attacker,=
 but it also allows
 some recovery from an occasional outage that loses one signature (eg accep=
t only the very next counter value, or be a bit lenient and accept a counte=
r value as long as it doesn=E2=80=99t repeat or go backward).=



=C2=A0


An attacker who clones a key can forg=
e any number of signatures whenever they see 1 signature from the original =
user: just re-use the
 same =E2=80=9Cnext=E2=80=9D value (or send a bunch of signature where the =
last one re-uses the original =E2=80=9Cnext=E2=80=9D value).<=
/span>


=C2=A0


=C2=A0


* =E2=80=9CEach of t=
hose numbers can hold signed int, up to 64 bytes length=E2=80=9D


64 bytes or 64 bits?


If you are using integers in JSON you=
 better stick to 53-bits, which the limit for exact integers in a 64-bit fl=
oat [RFC7493
 I-JSON].


But in this situation you should just=
 use strings. All you are using is randomly chosen previous and next values=
 that you can do equality
 matching on.


=C2=A0


* =E2=80=9Cclient-id=
=E2=80=9D


You already have a key-id for the JWS=
 signing key so I=E2=80=99m not sure what extra a client-id just for the pr=
ev/next state adds.


=C2=A0


* =E2=80=9Cprevious=E2=80=9D, =E2=80=
=9Cnext=E2=80=9D, =E2=80=9Ccurrent=E2=80=9D, =E2=80=9Cnew=E2=80=9D


I think 4 labels are used for 2 quant=
ities.


=C2=A0


* RFC2289 A One-Time Password System


Are you actually using the referenced=
 RFC2289 (that seems to use H(H(H(H(=E2=80=A6H(password + challenge + stuff=
)=E2=80=A6)))))?


I don=E2=80=99t think so. I think you=
 are using normal crypto signing keys, plus a random nonce.


=C2=A0


--


James Manger


=C2=A0


From: =
OAuth [mailto:o=
auth-bounces@ietf.org]
On Behalf Of Omer Levi Hevroni

Sent: Tuesday, 18 September 2018 5:40 AM

To: oauth@ietf.o=
rg

Subject: [OAUTH-WG] Presenting Seamless Flow at IETF 103


=C2=A0






Hey




My name is Omer, and I want to ask a time to present=
 a draft I'm working on at IETF 103. This is a new oauth extension, tha=
t suppose to allows devices to authenticate without any user interaction. T=
here are many use cases, especially in
 IoT world, where there are devices which need a strong authentication solu=
tion - but does not have an option for any kind of user interaction. This f=
low intends to allow them to achieve this.=C2=A0






The current version of the draft can be found here:=
=C2=A0https://tools.ietf.org/html/draft-hevroni-oauth-s=
eamless-flow-01. Feedback on the draft is highly appreciated.=C2=A0<=
/u>






=C2=A0






Thanks,






Omer






=C2=A0















--000000000000665b7d05765045a3--


From nobody Sat Sep 22 11:47:11 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 CE67F12D7F8 for ; Sat, 22 Sep 2018 11:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=Hn5Od0Ul; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UvogunH+
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 6uhO4zycPiCh for ; Sat, 22 Sep 2018 11:47:07 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0968130DE8 for ; Sat, 22 Sep 2018 11:47:04 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 12A0621B7C for ; Sat, 22 Sep 2018 14:47:03 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 22 Sep 2018 14:47:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=x6g26M+nPIPKoPf+LxxAhcz0+SdKd+LIqHKo9UlD1ss=; b=Hn5Od 0UlVNYk/oiXuIUQECjUBil2PLt+fvepKO/1xwW4fPjJKpSicit14mvlM/4RgYXz+ 1XUM8s4nJo9Xw4fy9XICqZgbDBw9/6rpMlHw3y6Cu5TEVRVKNKQgt2mg0zke6faN JY/13izMwGcEmAwKSwCE2mgbdCtmLss0+VjMz4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=x6g26M+nPIPKoPf+LxxAhcz0+SdKd +LIqHKo9UlD1ss=; b=UvogunH+8aaFnc9xJVESTnKaGE8Uc+xfQL9tvXN1b/Iry 9lKxJNG8b7h/u1Ylxmn7yYxa066I4c6x3LmYyEbJYxTVELAByHVWOGajIBaRjl5f bti/rFPlM4TZE9ZdH713NPDvqxUnLD7zaPqL1RpwGC81LeBGiDefi45JH13/OIpe rljRP2Xpc5LMZq2XVaLBSpoW1kNjl102U8T3pxmyMUm7fx5KcRbZGgcDbHqEzv2Q iU87VAGnFVMjiRdi/X2mGSFsPuS7VW/FP4X6IDIBl+iYYrwlKwVzWz0ZkjcWT4Uv BXkGhEyXXUj+VlickfeOggXm+4Ege1MNxc51+BMog==
X-ME-Proxy:      
X-ME-Sender: 
Received: from [192.168.0.24] (cpebc4dfba11313-cmbc4dfba11310.cpe.net.cable.rogers.com [99.245.72.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 5F758102DD for ; Sat, 22 Sep 2018 14:47:02 -0400 (EDT)
To: OAuth@ietf.org
From: Evert Pot 
Openpgp: preference=signencrypt
Autocrypt: addr=me@evertpot.com; keydata= xsFNBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABzRtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT7CwZQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFc7BTQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAcLBfAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA
Message-ID: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com>
Date: Sat, 22 Sep 2018 14:47:01 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: [OAUTH-WG] Link header for 401 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: Sat, 22 Sep 2018 18:47:10 -0000

Dear list,

Apologies if this has been brought up before. I searched the archives
but didn't find anything related.
I am working on a web application + api that uses OAuth2 implicit flow
and Bearer tokens.

It occurred to that when the API responds with a 401 request, a useful
addition would be that the api also informs the user of the OAuth2
authentication endpoint to redirect the user to.

It makes sense to me to do this via a HTTP Link header. A response could
look as follows:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
Link:  rel=3D"oauth2-authenticate"=


The reason I'm emailing is because I wanted to gauge whether this is
interesting, or if there are problems with this approach.

If it is interesting, I would like to take a stab at writing an IETF
draft for this.

Cheers,
Evert




From nobody Sat Sep 22 12:54:38 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 D14E4130E45 for ; Sat, 22 Sep 2018 12:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 juomvt1SLbtg for ; Sat, 22 Sep 2018 12:54:34 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 54115130E13 for ; Sat, 22 Sep 2018 12:54:34 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8MJp62i081643; Sat, 22 Sep 2018 19:54:28 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=iVBigZq5GsojnHV7f4pJN9S2zxUSrkpQ82613qLWNsE=; b=JnajWsLV+lLL6vpIOxP+HH4n/a4UOAwgKeKbmUFvt5mH0J94kArkQV45BF+u9Roum0wY 26E8ZERFsO1eRKkiU4C5mHd0Ma6X/iavWpVcxUq5S9fJVvzYH0jmDgDniAlWagGrL+WZ ukcoWoBFbP20hIsjYkTFd9g3jBY1njTqTgjkCc/rutSo5+UjZQ2WUDrJyN/xcnRAg4te MwIprgTpn5AcTEXaLUiM+LPIUrjHrqRRBgBAfVJ8O4FXqFTWBZ0470P17KRXJzCYcy9E zujCtsUd1Bt/cnQGpzbI0+B6l/UlETy52iWZaf2m8U9szLeByMG1LLZWcU8kqGCC+zAN JQ== 
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2mndpp185u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Sep 2018 19:54:28 +0000
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w8MJsMdn005868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 22 Sep 2018 19:54:22 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8MJsMEj011060; Sat, 22 Sep 2018 19:54:22 GMT
Received: from [IPv6:2605:8d80:441:958a:5439:764d:1bb4:90e5] (/72.143.223.21) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Sep 2018 12:54:21 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Phil Hunt 
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com>
Date: Sat, 22 Sep 2018 12:54:14 -0700
Cc: OAuth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F53036A-1903-4B37-8148-C832B6B4CE3A@oracle.com>
References: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com>
To: Evert Pot 
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9024 signatures=668707
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809220210
Archived-At: 
Subject: Re: [OAUTH-WG] Link header for 401 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: Sat, 22 Sep 2018 19:54:37 -0000

Evert,

See step =E2=80=9CB=E2=80=9D in sec 4.2 of RFC6749. The AS worries about  au=
thenticating the user.=20

Phil

> On Sep 22, 2018, at 11:47 AM, Evert Pot  wrote:
>=20
> Dear list,
>=20
> Apologies if this has been brought up before. I searched the archives
> but didn't find anything related.
> I am working on a web application + api that uses OAuth2 implicit flow
> and Bearer tokens.
>=20
> It occurred to that when the API responds with a 401 request, a useful
> addition would be that the api also informs the user of the OAuth2
> authentication endpoint to redirect the user to.
>=20
> It makes sense to me to do this via a HTTP Link header. A response could
> look as follows:
>=20
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Bearer
> Link:  rel=3D"oauth2-authenticate"
>=20
> The reason I'm emailing is because I wanted to gauge whether this is
> interesting, or if there are problems with this approach.
>=20
> If it is interesting, I would like to take a stab at writing an IETF
> draft for this.
>=20
> Cheers,
> Evert
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sat Sep 22 19:06:35 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 7363F128BAC for ; Sat, 22 Sep 2018 19:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=J1ohn9RK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kIj3RQAm
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 nWnSjo4hHQ6v for ; Sat, 22 Sep 2018 19:06:32 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA941293FB for ; Sat, 22 Sep 2018 19:06:32 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D151620D9E; Sat, 22 Sep 2018 22:06:31 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 22 Sep 2018 22:06:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=PtyMu4gtQmNBFnm6i/RSfL0nF4 KWXHzgfjen/mectLM=; b=J1ohn9RKHxEIv5xd0iI3xepeQ8OLuup/ezCOsPsLqQ trhj7Sukl/zs4mkiKRHXmLdj5yVb9QYiRRtm0onOI247gzVTNtl0V2R7pdP1C4tG M9GVO6rPqZNT1kzEHt74SSnNLCV1BmoEJPiN3Xe13jY/3/1qj8g3ci16cR+T4Lkc M=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PtyMu4 gtQmNBFnm6i/RSfL0nF4KWXHzgfjen/mectLM=; b=kIj3RQAm145zvuik3YJfly hjmew3dV1Bc7T1m70/ad0h9TgOjU19QCM3oeQO54neM7hCoRjqYw2TJ1LVzGeuVO w+2J6VESqLQNbMZlbDn1GbDEIkWT+l+W3jUOd0O30Iis1eksX1TU+JrTFM1+d+Q+ OStFSEZFuUABwBuwFbn7JPc+BoAgSKfSy87LVLHsDxLnkHlZwVr3AouUfIMcVgUg 7J07F64HjFc8wBMHymYBw8QlDTVeLANmh4I8i6Sm9bocUudKWaI1QbL9Enz4MPxm Ds9d8l5NaePa4d5hXxIqs4RgaaZsIgL6CXTGz77pxY80Hgo3gsYikQlZ7DrjzoUA ==
X-ME-Proxy:      
X-ME-Sender: 
Received: from [192.168.0.24] (cpebc4dfba11313-cmbc4dfba11310.cpe.net.cable.rogers.com [99.245.72.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 156E2102A0; Sat, 22 Sep 2018 22:06:30 -0400 (EDT)
To: Phil Hunt 
Cc: OAuth@ietf.org
References: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com> <6F53036A-1903-4B37-8148-C832B6B4CE3A@oracle.com>
From: Evert Pot 
Openpgp: preference=signencrypt
Autocrypt: addr=me@evertpot.com; keydata= xsFNBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABzRtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT7CwZQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFc7BTQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAcLBfAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA
Message-ID: <993e5da1-5d14-07ab-4ed9-1a573992ff38@evertpot.com>
Date: Sat, 22 Sep 2018 22:06:27 -0400
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: <6F53036A-1903-4B37-8148-C832B6B4CE3A@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Link header for 401 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: Sun, 23 Sep 2018 02:06:34 -0000

Hi Phil,

I'm a little confused by this answer. The flow I'm interested in
supporting is a client connecting to a server and being able to
transparently discover an OAuth2 endpoint to obtain a Bearer token.
A feature like this might allow a generic client to access a service
without relying on out-of-band knowledge of which authorization server
belongs to which client resource.



On 09/22/2018 03:54 PM, Phil Hunt wrote:
> Evert,
>
> See step “B” in sec 4.2 of RFC6749. The AS worries about  authenticating the user. 
>
> Phil
>
>> On Sep 22, 2018, at 11:47 AM, Evert Pot  wrote:
>>
>> Dear list,
>>
>> Apologies if this has been brought up before. I searched the archives
>> but didn't find anything related.
>> I am working on a web application + api that uses OAuth2 implicit flow
>> and Bearer tokens.
>>
>> It occurred to that when the API responds with a 401 request, a useful
>> addition would be that the api also informs the user of the OAuth2
>> authentication endpoint to redirect the user to.
>>
>> It makes sense to me to do this via a HTTP Link header. A response could
>> look as follows:
>>
>> HTTP/1.1 401 Unauthorized
>> WWW-Authenticate: Bearer
>> Link:  rel="oauth2-authenticate"
>>
>> The reason I'm emailing is because I wanted to gauge whether this is
>> interesting, or if there are problems with this approach.
>>
>> If it is interesting, I would like to take a stab at writing an IETF
>> draft for this.
>>
>> Cheers,
>> Evert
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


From nobody Sat Sep 22 22:31: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 0D64A130E7E for ; Sat, 22 Sep 2018 22:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 XL5wtUo4y7B3 for ; Sat, 22 Sep 2018 22:31:21 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 E8652130E7A for ; Sat, 22 Sep 2018 22:31:20 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id a17-v6so1921739wrs.12 for ; Sat, 22 Sep 2018 22:31:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ueNmNtGZPVC4iJAPLs5LjmNhMGkK5f+NZskIqxY2Yrc=; b=OZQTwniSnGHo43t4nZ5fxm88we2WJpKdUMRSfw9r5erCFhxalnBc4ZKBHFjbJ9ryN5 3Y8l3HM/Ui8UhHJgVgGVhqld/T1DtsE9qYK7RLYsRWqbTWmTs+f/tqBAnZPXn5ZI7TzG RHJTpPw9nwx3/78ONAF/roIscINRxYxmaBNv4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ueNmNtGZPVC4iJAPLs5LjmNhMGkK5f+NZskIqxY2Yrc=; b=MwfnmzgBlXdBGr93Lw562ff6Er4eEmMYsnnA+uJiSKKPtzG6ExrHjQWgdGlRl06TG7 5sYkX8S7fSpZ4xIK1VVo8WbJsBYOdemgK06NToJgEPyGhC36vJNUtUTK9epCZ3KHcwiP JKGkTdU+K5XQrPxFU7lPL373Cf0EgYkGCCtlpCKcuwRTSruIP60rvHQKPSPMVsDFZVVU f3FwWsI545a4mr0GpEczl+UbIppNXBQpsYN/Sq03oWEK0By4MlK/8lZFl28ifTKgAmYh uu+Pen/Sutavxfkt7s2p+Pxyh4HytrbwDviexh5dGdebF8u5qNs5mPSeEScltzfJFPms Rvnw==
X-Gm-Message-State: ABuFfogCvtq5Kml7pySKJSRIZHQTl5oEwRLa8rhZkPHfwVbWXeldz5Bl mg+pa6cDLFoTv7ASgktqUQB9kbsKHxfFrDGn30zYUcETi8s9aCAj6fYQHC1DWga9vjU78cuykjJ WMmt95Bd2loPipU0sjmK/z/SZKgQ+uQgdaOVw5bpppg3cv2CwBCLSFJ/Kmi/HWQQ=
X-Google-Smtp-Source: ACcGV62iD4m1zeeQeDqUrZMfGl32RxVVte69lPot6qJPx/DmLlw12cyNMqwyw7LsSiKceIzwhr7lmw==
X-Received: by 2002:a5d:43c4:: with SMTP id v4-v6mr3387239wrr.156.1537680678869;  Sat, 22 Sep 2018 22:31:18 -0700 (PDT)
Received: from ?IPv6:2a01:4c8:80f:86b3:198c:b7a0:687f:6ffb? ([2a01:4c8:80f:86b3:198c:b7a0:687f:6ffb]) by smtp.gmail.com with ESMTPSA id x65-v6sm11639526wmg.39.2018.09.22.22.31.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Sep 2018 22:31:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-55772D1F-974C-4E29-9319-C4DCD481B312
Mime-Version: 1.0 (1.0)
From: Neil Madden 
X-Mailer: iPhone Mail (16A366)
In-Reply-To: <993e5da1-5d14-07ab-4ed9-1a573992ff38@evertpot.com>
Date: Sun, 23 Sep 2018 06:31:17 +0100
Cc: Phil Hunt , OAuth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <507CB64A-8287-4A7D-9C10-67C367C134B0@forgerock.com>
References: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com> <6F53036A-1903-4B37-8148-C832B6B4CE3A@oracle.com> <993e5da1-5d14-07ab-4ed9-1a573992ff38@evertpot.com>
To: Evert Pot 
Archived-At: 
Subject: Re: [OAUTH-WG] Link header for 401 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: Sun, 23 Sep 2018 05:31:24 -0000

--Apple-Mail-55772D1F-974C-4E29-9319-C4DCD481B312
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

UMA uses an as_uri property on the WWW-Authenticate header for this:

https://docs.kantarainitiative.org/uma/rec-uma-core.html#permission-success-=
to-client

Neil

> On 23 Sep 2018, at 03:06, Evert Pot  wrote:
>=20
> Hi Phil,
>=20
> I'm a little confused by this answer. The flow I'm interested in
> supporting is a client connecting to a server and being able to
> transparently discover an OAuth2 endpoint to obtain a Bearer token.
> A feature like this might allow a generic client to access a service
> without relying on out-of-band knowledge of which authorization server
> belongs to which client resource.
>=20
>=20
>=20
>> On 09/22/2018 03:54 PM, Phil Hunt wrote:
>> Evert,
>>=20
>> See step =E2=80=9CB=E2=80=9D in sec 4.2 of RFC6749. The AS worries about =
 authenticating the user.=20
>>=20
>> Phil
>>=20
>>> On Sep 22, 2018, at 11:47 AM, Evert Pot  wrote:
>>>=20
>>> Dear list,
>>>=20
>>> Apologies if this has been brought up before. I searched the archives
>>> but didn't find anything related.
>>> I am working on a web application + api that uses OAuth2 implicit flow
>>> and Bearer tokens.
>>>=20
>>> It occurred to that when the API responds with a 401 request, a useful
>>> addition would be that the api also informs the user of the OAuth2
>>> authentication endpoint to redirect the user to.
>>>=20
>>> It makes sense to me to do this via a HTTP Link header. A response could=

>>> look as follows:
>>>=20
>>> HTTP/1.1 401 Unauthorized
>>> WWW-Authenticate: Bearer
>>> Link:  rel=3D"oauth2-authenticate=
"
>>>=20
>>> The reason I'm emailing is because I wanted to gauge whether this is
>>> interesting, or if there are problems with this approach.
>>>=20
>>> If it is interesting, I would like to take a stab at writing an IETF
>>> draft for this.
>>>=20
>>> Cheers,
>>> Evert
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-55772D1F-974C-4E29-9319-C4DCD481B312
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


UMA=
 uses an as_uri property on the WWW-Authenticate header for this:

https://docs.kan=
tarainitiative.org/uma/rec-uma-core.html#permission-success-to-client

Neil
On 23 Sep 2018, at 03:06, Evert Pot <me@evertpot.com> wrote:

Hi Phil,

I'm a little conf=
used by this answer. The flow I'm interested in
supporting i=
s a client connecting to a server and being able to
transpar=
ently discover an OAuth2 endpoint to obtain a Bearer token.
=
A feature like this might allow a generic client to access a service<=
br>without relying on out-of-band knowledge of which authorization ser=
ver
belongs to which client resource.



On 09/22/2018 03:54 PM, Phil Hu=
nt wrote:
Evert,

See step =E2=80=9CB=E2=80=9D in sec 4.2 of RFC6749. The AS=
 worries about  authenticating the user. 

=
Phil
On S=
ep 22, 2018, at 11:47 AM, Evert Pot <m=
e@evertpot.com> wrote:

Dear list=
,

Apologies if this has been brought up b=
efore. I searched the archives
but didn't find anything re=
lated.
I am working on a web application + api that uses O=
Auth2 implicit flow
and Bearer tokens.
<=
/span>
It occurred to that when the API responds with a 401 reque=
st, a useful
<=
blockquote type=3D"cite">addition would be that the api also informs t=
he user of the OAuth2
authentication endpoint to redirect t=
he user to.

It makes sense to me to do t=
his via a HTTP Link header. A response could
look as follo=
ws:

HTTP/1.1 401 Unauthorized
<=
/blockquote>
WWW-Authenticate: Bearer
Link: <https://auth.example.org/authenticate&=
gt; rel=3D"oauth2-authenticate"

The rea=
son I'm emailing is because I wanted to gauge whether this is
interesting, or if there are problems with this approach.

If it is interesting, I would like to take a stab at w=
riting an IETF
draft for this.
Cheers,
Evert



_____________________________________=
__________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin=
fo/oauth

____=
___________________________________________
OAuth mailing li=
st
OAuth@ietf.org
https://=
www.ietf.org/mailman/listinfo/oauth
=
=

--Apple-Mail-55772D1F-974C-4E29-9319-C4DCD481B312--


From nobody Mon Sep 24 05:51:16 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 C01E6130E86 for ; Mon, 24 Sep 2018 05:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 kRR_JI-HUG_k for ; Mon, 24 Sep 2018 05:51:13 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 4D3B9130E98 for ; Mon, 24 Sep 2018 05:51:13 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id e12-v6so17438992iok.12 for ; Mon, 24 Sep 2018 05:51:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Th/uyO46tTCAahfGghS/ufvLEwk/bjcphZgR1+YqE+g=; b=CCvUHe1buvSIDbhnrh0EjGzQFJnH5JUhmg9xLl7N93hA+InTenlahg1d5DZ/cJaO3T FSwIH6RyN42dyRBxL+pIr3mf4cxPmmz84G7ObL4fSCedSK3c8ME7XXdh0RWcZb7CEFqI M1yKVC494IpfCnHk5/Z2l4jTkJvGcu1OGkMLk=
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=Th/uyO46tTCAahfGghS/ufvLEwk/bjcphZgR1+YqE+g=; b=lyVt174Sz3TKCFh66Kk2z/wqEDpMrkJrN/nvea2uGC3w/n6HH0SD00M6hlbhv2jC41 toBRNCk+8XPvU/kEA8AJabVzQZQds6snsukCsJOvlSWAjQJa6uFCpoE3luwUF3Kr9JAP eritvemqrDhgp+AVgbOV5u8epns3JPaWznXxIE8R+LN1Q5c3YtipFldWG+q7K+d7EmHI Ct2eeVIee25pZ+69kKrK72TrRBQ+KBAUAsppjUk/uoc8RnrbC2nfZX/zCMGjIl+B3TkL 9iOGxueCNdug2YmE4ojBcvVAdMs3u4hF/CHjljMwChfazxPiZZnNkCTigNc4U+pisvW5 DfjQ==
X-Gm-Message-State: ABuFfoj0r7pR7uIAdRyTuJ1QFuGV3prFTTnQgC1zjNbIGDJsAD6T7ryP nGePt5P155/ViplzokAkVsBo40yRF45LKMIyAeA5jjW/EUahfV8E33+yPzh9Vie0tQx7D0FMFYJ 4f8rgMeHzrIDiQ7idjxs=
X-Google-Smtp-Source: ACcGV63ENgnbfjt6rOBpuhMpJCFSShEuitawLti/8Yi34N7BGffQjsK12Mh6gCshgkZ3NWMzcmqhSSTXycFyVLuoO44=
X-Received: by 2002:a6b:8f44:: with SMTP id r65-v6mr8063687iod.59.1537793472303;  Mon, 24 Sep 2018 05:51:12 -0700 (PDT)
MIME-Version: 1.0
References: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com>
In-Reply-To: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com>
From: Brian Campbell 
Date: Mon, 24 Sep 2018 06:50:45 -0600
Message-ID: 
To: me@evertpot.com
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000a8238f05769d7179"
Archived-At: 
Subject: Re: [OAUTH-WG] Link header for 401 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: Mon, 24 Sep 2018 12:51:16 -0000

--000000000000a8238f05769d7179
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Evert,

The working group recently adopted a draft called Distributed OAuth that
has more or less what you describe. Note that it's been adopted
https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM but
hasn't been published as a WG document yet so, for now, is found in this
individual draft
https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/

There are some security considerations that emerge with that kind approach
that need to be addressed. The aforementioned draft does attempt to address
them.

There's also been some discussion as to what the Link header should point
to (e.g. metadata document, issuer URL, authorization endpoint, token
endpoint). And even whether or not a Link header should be used vs. an
attribute on the WWW-Authenticate header. Most of those discussions should
be in the archives:
https://mailarchive.ietf.org/arch/browse/oauth/?q=3DDistributed+OAuth&gbt=
=3D1&index=3Dm1TUuh7Tcha9tuDrCraIrkjy73o

So I guess to answer your question, there is interest in it and there is
already some work in the form of a draft. Your input into developing that
document would be welcomed.





On Sat, Sep 22, 2018 at 12:47 PM Evert Pot  wrote:

> Dear list,
>
> Apologies if this has been brought up before. I searched the archives
> but didn't find anything related.
> I am working on a web application + api that uses OAuth2 implicit flow
> and Bearer tokens.
>
> It occurred to that when the API responds with a 401 request, a useful
> addition would be that the api also informs the user of the OAuth2
> authentication endpoint to redirect the user to.
>
> It makes sense to me to do this via a HTTP Link header. A response could
> look as follows:
>
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Bearer
> Link:  rel=3D"oauth2-authenticate"
>
> The reason I'm emailing is because I wanted to gauge whether this is
> interesting, or if there are problems with this approach.
>
> If it is interesting, I would like to take a stab at writing an IETF
> draft for this.
>
> Cheers,
> Evert
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--000000000000a8238f05769d7179
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Evert,

The work=
ing group recently adopted a draft called Distributed OAuth that has more o=
r less what you describe. Note that it's been adopted https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtd=
u5s07kLM but hasn't been published as a WG document yet so, for now=
, is found in this individual draft https://datatracker.=
ietf.org/doc/draft-hardt-oauth-distributed/

There are some security considerations that emerge with that kind approac=
h that need to be addressed. The aforementioned draft does attempt to addre=
ss them.

There's also been some discussion=
 as to what the Link header should point to (e.g. metadata document, issuer=
 URL, authorization endpoint, token endpoint). And even whether or not a Li=
nk header should be used vs. an attribute on the WWW-Authenticate header. M=
ost of those discussions should be in the archives: https://mailarchive.ietf.org/arch/brows=
e/oauth/?q=3DDistributed+OAuth&gbt=3D1&index=3Dm1TUuh7Tcha9tuDrCraI=
rkjy73o

So I guess to answer your question=
, there is interest in it and there is already some work in the form of a d=
raft. Your input into developing that document would be welcomed.




<=
/div>

On Sat, Se=
p 22, 2018 at 12:47 PM Evert Pot <me@evertpot.com> wrote:
Dear list,



Apologies if this has been brought up before. I searched the archives

but didn't find anything related.

I am working on a web application + api that uses OAuth2 implicit flow

and Bearer tokens.



It occurred to that when the API responds with a 401 request, a useful

addition would be that the api also informs the user of the OAuth2

authentication endpoint to redirect the user to.



It makes sense to me to do this via a HTTP Link header. A response could
look as follows:



HTTP/1.1 401 Unauthorized

WWW-Authenticate: Bearer

Link: <https://auth.example.org/authenticate> rel=3D&=
quot;oauth2-authenticate"



The reason I'm emailing is because I wanted to gauge whether this is
interesting, or if there are problems with this approach.



If it is interesting, I would like to take a stab at writing an IETF

draft for this.



Cheers,

Evert







_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






<=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub=
untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"=
>CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.
--000000000000a8238f05769d7179--


From nobody Mon Sep 24 05:52: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 515BC130EA3 for ; Mon, 24 Sep 2018 05:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, 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=armh.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 XBcxjS9P9YnC for ; Mon, 24 Sep 2018 05:52:39 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60056.outbound.protection.outlook.com [40.107.6.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71704130EC7 for ; Mon, 24 Sep 2018 05:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0njmD04EcIOSsUB7jspA+WpI0d5VENNB1imQzGclbRI=; b=AhvcjWAejGXpWi9d+QFiFyS7MLeESiPYheJCirp34rRNA0ZUSjvIj/owyx6fyAMUA0mP/krrED0DapJJiJE2CaJZ71I7w8H1eiHOFKzxxtpEAAcJrSbVNR66jKPIewJ855sIZQ8wJwZ7OmnklQ0IAc1tmabY1z/ZPx7e2MhBycA=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2032.eurprd08.prod.outlook.com (10.173.74.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.17; Mon, 24 Sep 2018 12:52:35 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::a94b:7baf:174a:14c1]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::a94b:7baf:174a:14c1%12]) with mapi id 15.20.1143.017; Mon, 24 Sep 2018 12:52:35 +0000
From: Hannes Tschofenig 
To: "OAuth@ietf.org" 
Thread-Topic: Cancelling today's OAuth Call
Thread-Index: AdRUBPkYqWn1cSEsR+S+Z01vreoLNw==
Date: Mon, 24 Sep 2018 12:52:35 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; 
x-originating-ip: [46.103.121.108]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2032; 6:9HBtllz4SZI1P8J6O8Yi1MaGpSI1kp4D59f1J7A5puH9PTpM2RU7J3FXTkQ1MVHh/xET5EU70VwyBPNXqRAx/P1lLf7otBxLULPniC6HxjNJp6n74ASrAWIo8+kgTTlAaUN6IJiMuvn5r63lbotI7hZ/s+Rax8+Vr9iTvkPaBERAgTQ6rpKNS4VMpKLDXZLzsc4VpxRCBh2MvSSGHml8802nFqy6mTQrvajXP2HJ0sbA5auy2W9MdZtMLzkFxxUHzm+XYLpTrPiC95Ezn1S1fiVo786CRpMcRV5bqMLfe+pEIyow4VvwgQlLgddBn8BMYTY7NwoBTb566Hg0yXcOXt/ZFgu+M51U5ZajTovRUkWEAal6debZ6aGRmRJfr5MDtHUh5RstxNQAs44JKeflE3ZHMFvaGrVab8kBzOlxaKqAge8kW/HGsP+5PDf3vrXEb59ulxSRKeSYJrI0ELpr9g==; 5:XOIp4MDuG2YQj5woJ8k3czFJ4wt3pgTcGFURvqlT5eJ0WFpVSvDHY8r5FMZ2/IRPivzygm+Ou9Xhg2myNoYo52q9iRaPavvJ7w2DR8YpjEJXitFBEWSwzNDWqiRsMtC7N8UCij+fc5n0lNc/L51ayrNW4XLoIAaoldGKsIaSJm4=; 7:jKyVbuJJQKaibkH/W3l7/ukQmrnXPFoFLzM4469HRGmzOKSgPjzE7+4mfSDbu4ZJPfFxutty7Lb3WEsIq6kQP1Kmz8aZqp9hBN5BDLsKvi8mE1jB1Ism+JNZRpei3MYq0vbOxWMrlejqh3f2SxxRqL+9e6dTc0gzkZe5V5YFylgBOViHzCI429z6pyfa/i+7d+yNVa0aHSXBy1l2YwpnjknHUI+EMIyzYygNKS3Ib8JWxQa+zT7bA8GxJTXHeTzm
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: daeffe47-010e-4702-eb34-08d6221c99bc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2032; 
x-ms-traffictypediagnostic: VI1PR0801MB2032:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231355)(944501410)(52105095)(6055026)(149066)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051); SRVR:VI1PR0801MB2032; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2032; 
x-forefront-prvs: 0805EC9467
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(136003)(366004)(396003)(53754006)(40434004)(189003)(199004)(71190400001)(186003)(5630700001)(72206003)(74316002)(53936002)(33656002)(8676002)(478600001)(81166006)(81156014)(6916009)(7736002)(5660300001)(68736007)(97736004)(2501003)(3846002)(6116002)(790700001)(39060400002)(14454004)(8936002)(3480700004)(2900100001)(66066001)(2351001)(9686003)(105586002)(2906002)(5640700003)(25786009)(4326008)(5250100002)(7696005)(86362001)(14444005)(5024004)(6506007)(256004)(54896002)(6306002)(106356001)(55016002)(26005)(71200400001)(6436002)(102836004)(316002)(476003)(99286004)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2032; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: n/D6yuYElVHcX0fEEV/FFyvbDNEAJeA+leUTqjVTPz+ISX4KnoHheBXsl7nqvgJKYdPR+HIZyC8pS9o9vGsOSaCvk/kBQz7qtRbeKahmLkbJk0d1xJO5aQ5zTn3gLo41Aj8PE1Qcr65ilvaWYWHC7p9jbTXvvPCRiwLDyNZ/RSX77nSN/BujUUT5CHBmCjSHvK7dg2BmlloHpT4vDHx3f3I6NC0sA4bjhhzh1doQKINjgPt6UIt7poOfj8nP9fOMpyEfsooGsK3NXcVbA0RHxDB/yzktKLob+OiPrDGGBPxy+tlTMoHP8LNcNyywa1lM+R8RbE6oc42lKzdAqCGz4fny/w76i7SZpysPE5Ps7YE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122809CC9E1DF4850EF9B0FA170VI1PR0801MB2112_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: daeffe47-010e-4702-eb34-08d6221c99bc
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2018 12:52:35.1416 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2032
Archived-At: 
Subject: [OAUTH-WG] Cancelling today's OAuth Call
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: Mon, 24 Sep 2018 12:52:41 -0000

--_000_VI1PR0801MB21122809CC9E1DF4850EF9B0FA170VI1PR0801MB2112_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Rifaat and I have a conflict today and cannot attend our OAuth Virtual Offi=
ce Hour call. Hence, we have to cancel it.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.

--_000_VI1PR0801MB21122809CC9E1DF4850EF9B0FA170VI1PR0801MB2112_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all, 


 


Rifaat and I have a conflict today and cannot attend=
 our OAuth Virtual Office Hour call. Hence, we have to cancel it.



 


Ciao

Hannes


 



IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose,
 or store or copy the information in any medium. Thank you.



--_000_VI1PR0801MB21122809CC9E1DF4850EF9B0FA170VI1PR0801MB2112_--


From nobody Mon Sep 24 07:09:55 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 97AEA130DE4 for ; Mon, 24 Sep 2018 07:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=Zc5FxckG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bbSKoeUP
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 NlNEGGIW1l60 for ; Mon, 24 Sep 2018 07:09:50 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A464130DC7 for ; Mon, 24 Sep 2018 07:09:50 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 529A6402; Mon, 24 Sep 2018 10:09:47 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 24 Sep 2018 10:09:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=2Rke+m87geCnQK2Ym0iPr2/4dngFbHN8NdmMl/4lzhU=; b=Zc5Fx ckGQyXfxkmuvnzjWKCW5778pVLB/A5zsdKXBw5yfxEZ5KTQ0lTO6sAz+JXyS6mRT D1fvONrD1d+q/4GSzSvgFPVhvcqAiEScvWTKYOpQ8GK3m0CrhITI0X4ZkHMvk+i7 MTLdmtDXllXsOS9YTEp279ckvo1ie4INUFM5/Q=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=2Rke+m87geCnQK2Ym0iPr2/4dngFb HN8NdmMl/4lzhU=; b=bbSKoeUPYJ484jazFaaJ5sqsKTeRJRS5ee3YIKa9012qJ njv6PgGu83PK4AJaeBXzDYFanEPgAISf4SvGDfryuzxj/K36Abl0WJ551eyvU6hb OedMJizsTcEgitGn0wQkQYredfQZGkTBAH6Y/6qGlxOEgDjMK/PCLi5EaDidM5UZ CdN/ARZVrtSs6pjYrQeKN2Z5H7jQyrkOuqTSvlDDEVJLcFPOk4b+CJw2SugRvkUH 8bcPf5POBLheGaNDdNWia5SGS438YKNviEQLUWPBCgMnBYHDrpmFVt9SFAXbsIoN fciK+slN2JI6nzUiXUPcYx6NvABShb9omn4qTQBHg==
X-ME-Proxy:      
X-ME-Sender: 
Received: from [192.168.0.24] (cpebc4dfba11313-cmbc4dfba11310.cpe.net.cable.rogers.com [99.245.72.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 36243E493A; Mon, 24 Sep 2018 10:09:46 -0400 (EDT)
To: Brian Campbell 
Cc: oauth 
References: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com> 
From: Evert Pot 
Openpgp: preference=signencrypt
Autocrypt: addr=me@evertpot.com; keydata= xsFNBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABzRtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT7CwZQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFc7BTQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAcLBfAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA
Message-ID: 
Date: Mon, 24 Sep 2018 10:09:45 -0400
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="------------A14FCECC7852194CBF34AB18"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Link header for 401 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: Mon, 24 Sep 2018 14:09:53 -0000

This is a multi-part message in MIME format.
--------------A14FCECC7852194CBF34AB18
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Brian,

This is *exactly* what I was looking for, thank you! I'll read the draft
and discussions and see if there's some way I can contribute.

Cheers,
Evert

On 09/24/2018 08:50 AM, Brian Campbell wrote:
> Hi Evert,
>
> The working group recently adopted a draft called Distributed OAuth
> that has more or less what you describe. Note that it's been adopted
> https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM=

> but hasn't been published as a WG document yet so, for now, is found
> in this individual draft
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>
> There are some security considerations that emerge with that kind
> approach that need to be addressed. The aforementioned draft does
> attempt to address them.
>
> There's also been some discussion as to what the Link header should
> point to (e.g. metadata document, issuer URL, authorization endpoint,
> token endpoint). And even whether or not a Link header should be used
> vs. an attribute on the WWW-Authenticate header. Most of those
> discussions should be in the archives:
> https://mailarchive.ietf.org/arch/browse/oauth/?q=3DDistributed+OAuth&g=
bt=3D1&index=3Dm1TUuh7Tcha9tuDrCraIrkjy73o
>
> So I guess to answer your question, there is interest in it and there
> is already some work in the form of a draft. Your input into
> developing that document would be welcomed.
>
>
>
>
>
> On Sat, Sep 22, 2018 at 12:47 PM Evert Pot  > wrote:
>
>     Dear list,
>
>     Apologies if this has been brought up before. I searched the archiv=
es
>     but didn't find anything related.
>     I am working on a web application + api that uses OAuth2 implicit f=
low
>     and Bearer tokens.
>
>     It occurred to that when the API responds with a 401 request, a use=
ful
>     addition would be that the api also informs the user of the OAuth2
>     authentication endpoint to redirect the user to.
>
>     It makes sense to me to do this via a HTTP Link header. A response
>     could
>     look as follows:
>
>     HTTP/1.1 401 Unauthorized
>     WWW-Authenticate: Bearer
>     Link: 
>     rel=3D"oauth2-authenticate"
>
>     The reason I'm emailing is because I wanted to gauge whether this i=
s
>     interesting, or if there are problems with this approach.
>
>     If it is interesting, I would like to take a stab at writing an IET=
F
>     draft for this.
>
>     Cheers,
>     Evert
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited.=C2=A0 If you have received this communication in error, ple=
ase
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./=20


--------------A14FCECC7852194CBF34AB18
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Brian,

    
This is *exactly* what I was looking for, thank you! I'll read
      the draft and discussions and see if there's some way I can
      contribute.

    
Cheers,

      Evert

    

    
On 09/24/2018 08:50 AM, Brian Campbell
      wrote:

    

    

      
      

        

          

            

              

                

                  
Hi Evert,

                  


                  

                  
The working group recently adopted a draft called
                    Distributed OAuth that has more or less what you
                    describe. Note that it's been adopted https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM
                    but hasn't been published as a WG document yet so,
                    for now, is found in this individual draft https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/

                    

                  


                  

                  
There are some security considerations that
                    emerge with that kind approach that need to be
                    addressed. The aforementioned draft does attempt to
                    address them.

                  

                  


                  

                  
There's also been some discussion as to what the
                    Link header should point to (e.g. metadata document,
                    issuer URL, authorization endpoint, token endpoint).
                    And even whether or not a Link header should be used
                    vs. an attribute on the WWW-Authenticate header.
                    Most of those discussions should be in the archives:
                    https://mailarchive.ietf.org/arch/browse/oauth/?q=Distributed+OAuth&gbt=1&index=m1TUuh7Tcha9tuDrCraIrkjy73o

                  

                  


                  

                  
So I guess to answer your question, there is
                    interest in it and there is already some work in the
                    form of a draft. Your input into developing that
                    document would be welcomed.

                  


                  

                  


                  

                  


                  

                  


                  

                

              

            

          

        

      

      

      

        
On Sat, Sep 22, 2018 at 12:47 PM Evert Pot <me@evertpot.com> wrote:

        

        
Dear list,

          

          Apologies if this has been brought up before. I searched the
          archives

          but didn't find anything related.

          I am working on a web application + api that uses OAuth2
          implicit flow

          and Bearer tokens.

          

          It occurred to that when the API responds with a 401 request,
          a useful

          addition would be that the api also informs the user of the
          OAuth2

          authentication endpoint to redirect the user to.

          

          It makes sense to me to do this via a HTTP Link header. A
          response could

          look as follows:

          

          HTTP/1.1 401 Unauthorized

          WWW-Authenticate: Bearer

          Link: <https://auth.example.org/authenticate>
          rel="oauth2-authenticate"

          

          The reason I'm emailing is because I wanted to gauge whether
          this is

          interesting, or if there are problems with this approach.

          

          If it is interesting, I would like to take a stab at writing
          an IETF

          draft for this.

          

          Cheers,

          Evert

          

          

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

          https://www.ietf.org/mailman/listinfo/oauth

        

      

      

      CONFIDENTIALITY
            NOTICE: This email may contain confidential and privileged
            material for the sole use of the intended recipient(s). Any
            review, use, distribution or disclosure by others is
            strictly prohibited.  If you have received this
            communication in error, please notify the sender immediately
            by e-mail and delete the message and any file attachments
            from your computer. Thank you.
    

    

  


--------------A14FCECC7852194CBF34AB18--


From nobody Mon Sep 24 08:29:46 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 3D152130DFD for ; Mon, 24 Sep 2018 08:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 do17D_PLxRpj for ; Mon, 24 Sep 2018 08:29:42 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 D54C6130DCF for ; Mon, 24 Sep 2018 08:29:41 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id o18-v6so10522862wmc.0 for ; Mon, 24 Sep 2018 08:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4eEZFfH63te1ISG4h3LZ3NA7jEchmupanO5SH9JfMlE=; b=GFRyRSQmFJNHCKOyflTtumjBNBwGuiV/kxrSNB8NWe90Pe0W/QWU1kz6jvnB37Z9lx 21JF3hjAM8ICYChabpLrjbNDEUci1b+Gl/dtcNwnTRtKysfqF1fWWypyxeCW+6EfPknP XJAOy1uVlFEXENljvUwsnFEABOzmJ3GvDobKM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4eEZFfH63te1ISG4h3LZ3NA7jEchmupanO5SH9JfMlE=; b=XcKDkOdfxXxC2LGGN+t4diS5TnsM57HYN4fQNtBYZRfQX9/USZqS8/kA0jjZ6It3yW GUoT3bt4oEriZMvmuYD/+yYeS1DMTcc/XxF0ahwxCbhANpfCwYkSaS+ZC8minixWq8zz q918/acLwjyRGP02MGa6WbcJxjQffU9EWKLNCpP6ybGyMsi4wDNaeue+9yDN07nGoBy6 zPSYyIZgQIs+bwqYIjGKrBfeRRyggNx0gNYklM63ENTSnDRPGeCVGStS7QbeCMV4RoCQ WdriPNEUVQRUR8jwdldYn7GGt5ND0gVxgDlCaqkUKpKmV0kpe6Jle4qniF+jAyvVFseF /IVw==
X-Gm-Message-State: APzg51Aln8ukecvXNjnRlQBq1vL6wFBOBpBAeutSwDu7wkdmdfKyDYCA h970fcQBShuWXfYXRs2b+fm3KPeIqDkr2ltAP3sTn6gkk+7T28S4by1L2+qOTN1rKrbEq9KEjhj iwxjsSDhTsxQ8MXmb8g+fS31wq6U7I769eCnxfP8kgJUG6ORv12cMJrw9mABItvA=
X-Google-Smtp-Source: ACcGV638qAmOJ8rry1t6X3o/2e2tClus98932U6fgJSJrfFfK84FizZ8nRWf5CPuUL6pBheTVqqCmw==
X-Received: by 2002:a1c:b404:: with SMTP id d4-v6mr7921230wmf.28.1537802979867;  Mon, 24 Sep 2018 08:29:39 -0700 (PDT)
Received: from [192.168.1.65] (41.167.189.80.dyn.plus.net. [80.189.167.41]) by smtp.gmail.com with ESMTPSA id p9-v6sm4610353wmc.37.2018.09.24.08.29.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Sep 2018 08:29:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-47BE1F79-66FC-4BB6-9F99-4D90EF7E324A
Mime-Version: 1.0 (1.0)
From: Neil Madden 
X-Mailer: iPhone Mail (16A366)
In-Reply-To: 
Date: Mon, 24 Sep 2018 16:29:37 +0100
Cc: me@evertpot.com, oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <165A8252-1EB7-48E5-A944-46B6E998DF14@forgerock.com>
References: <6eb51ac5-36b1-fdf3-2f28-99966b2b4652@evertpot.com> 
To: Brian Campbell 
Archived-At: 
Subject: Re: [OAUTH-WG] Link header for 401 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: Mon, 24 Sep 2018 15:29:45 -0000

--Apple-Mail-47BE1F79-66FC-4BB6-9F99-4D90EF7E324A
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I missed the Link aspects of that draft. I would prefer to use the WWW-Authe=
nticate header (as per UMA) for this rather than a Link header, for a number=
 of reasons:

1) It makes the authenticate challenge self-contained.=20

2) It allows more than one AS to be specified, by simply repeating the chall=
enge with different parameters. For instance, when changing AS provider I mi=
ght want to allow both for a short while: WWW-Authenticate: Bearer scope=3D=E2=
=80=9Ctest=E2=80=9D, as_uri=3D=E2=80=9Chttps://as1.test=E2=80=9D, Bearer sco=
pe=3D=E2=80=9Ctest=E2=80=9D, as_uri=3D=E2=80=9Chttps://as2.test=E2=80=9D. If=
 we consider OpenID Connect then it is very common to allow multiple AS.=20

3) It=E2=80=99s not clear to me what the Context-IRI of a Link header is on a=
 401 response. The spec (https://tools.ietf.org/html/rfc5988#section-5.2) sa=
ys that it is =E2=80=9Canonymous=E2=80=9D on a 404 response, and it seems pl=
ausible that the same would apply on a 401 response - a resource server whic=
h takes pains to avoid information leakage about available resources might w=
ell respond with a blanket 401 response and then only issue a 404 after succ=
essful authentication. Maybe that=E2=80=99s ok, but it just feels odd - the l=
ink relation doesn=E2=80=99t seem well defined in this case.=20

4) It allows a proxy to add its own AS uri as a Proxy-Authenticate header, i=
ndependently of the main resource server=E2=80=99s AS.=20

Cheers,

Neil

> On 24 Sep 2018, at 13:50, Brian Campbell  wrote:
>=20
> Hi Evert,
>=20
> The working group recently adopted a draft called Distributed OAuth that h=
as more or less what you describe. Note that it's been adopted https://maila=
rchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM but hasn't been p=
ublished as a WG document yet so, for now, is found in this individual draft=
 https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>=20
> There are some security considerations that emerge with that kind approach=
 that need to be addressed. The aforementioned draft does attempt to address=
 them.
>=20
> There's also been some discussion as to what the Link header should point t=
o (e.g. metadata document, issuer URL, authorization endpoint, token endpoin=
t). And even whether or not a Link header should be used vs. an attribute on=
 the WWW-Authenticate header. Most of those discussions should be in the arc=
hives: https://mailarchive.ietf.org/arch/browse/oauth/?q=3DDistributed+OAuth=
&gbt=3D1&index=3Dm1TUuh7Tcha9tuDrCraIrkjy73o
>=20
> So I guess to answer your question, there is interest in it and there is a=
lready some work in the form of a draft. Your input into developing that doc=
ument would be welcomed.
>=20
>=20
>=20
>=20
>=20
>> On Sat, Sep 22, 2018 at 12:47 PM Evert Pot  wrote:
>> Dear list,
>>=20
>> Apologies if this has been brought up before. I searched the archives
>> but didn't find anything related.
>> I am working on a web application + api that uses OAuth2 implicit flow
>> and Bearer tokens.
>>=20
>> It occurred to that when the API responds with a 401 request, a useful
>> addition would be that the api also informs the user of the OAuth2
>> authentication endpoint to redirect the user to.
>>=20
>> It makes sense to me to do this via a HTTP Link header. A response could
>> look as follows:
>>=20
>> HTTP/1.1 401 Unauthorized
>> WWW-Authenticate: Bearer
>> Link:  rel=3D"oauth2-authenticate"=

>>=20
>> The reason I'm emailing is because I wanted to gauge whether this is
>> interesting, or if there are problems with this approach.
>>=20
>> If it is interesting, I would like to take a stab at writing an IETF
>> draft for this.
>>=20
>> Cheers,
>> Evert
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
 material for the sole use of the intended recipient(s). Any review, use, di=
stribution or disclosure by others is strictly prohibited..  If you have rec=
eived this communication in error, please notify the sender immediately by e=
-mail and delete the message and any file attachments from your computer. Th=
ank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-47BE1F79-66FC-4BB6-9F99-4D90EF7E324A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I m=
issed the Link aspects of that draft. I would prefer to use the WWW-Authenti=
cate header (as per UMA) for this rather than a Link header, for a number of=
 reasons:

1) It makes the a=
uthenticate challenge self-contained. 

=

2) It allows more than one AS to be specified, by simply re=
peating the challenge with different parameters. For instance, when changing=
 AS provider I might want to allow both for a short while: WWW-Authenticate:=
 Bearer scope=3D=E2=80=9Ctest=E2=80=9D, as_uri=3D=E2=80=9Chttps://as1.test=E2=80=9D, Bearer scope=3D=E2=80=9Ctest=E2=80=
=9D, as_uri=3D=E2=80=9Chttps://as2.test=E2=80=
=9D. If we consider OpenID Connect then it is very common to allow multiple A=
S. 

3) It=E2=80=99s no=
t clear to me what the Context-IRI of a Link header is on a 401 response. Th=
e spec (https://=
tools.ietf.org/html/rfc5988#section-5.2) says that it is =E2=80=9Canonym=
ous=E2=80=9D on a 404 response, and it seems plausible that the same would a=
pply on a 401 response - a resource server which takes pains to avoid inform=
ation leakage about available resources might well respond with a blanket 40=
1 response and then only issue a 404 after successful authentication. Maybe t=
hat=E2=80=99s ok, but it just feels odd - the link relation doesn=E2=80=99t s=
eem well defined in this case. 

4) It allows a proxy to add its own AS uri as a Proxy-Authenticate=
 header, independently of the main resource server=E2=80=99s AS. 
=


Cheers,
Neil

On 24 Sep 2018, at 1=
3:50, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Hi Evert,

The working group recently adop=
ted a draft called Distributed OAuth that has more or less what you describe=
. Note that it's been adopted https://mailarchive.=
ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM but hasn't been publ=
ished as a WG document yet so, for now, is found in this individual draft https://datatracker.ietf.org/doc/draft-hardt-oauth-distribut=
ed/

There are some security considerations t=
hat emerge with that kind approach that need to be addressed. The aforementi=
oned draft does attempt to address them.

There'=
s also been some discussion as to what the Link header should point to (e.g.=
 metadata document, issuer URL, authorization endpoint, token endpoint). And=
 even whether or not a Link header should be used vs. an attribute on the WW=
W-Authenticate header. Most of those discussions should be in the archives: <=
a href=3D"https://mailarchive.ietf.org/arch/browse/oauth/?q=3DDistributed+OA=
uth&gbt=3D1&index=3Dm1TUuh7Tcha9tuDrCraIrkjy73o">https://mailarchive=
.ietf.org/arch/browse/oauth/?q=3DDistributed+OAuth&gbt=3D1&index=3Dm=
1TUuh7Tcha9tuDrCraIrkjy73o

So I guess to an=
swer your question, there is interest in it and there is already some work i=
n the form of a draft. Your input into developing that document would be wel=
comed.





On Sat, Sep 22, 2018 at 12:47 PM Evert Pot <me@evertpot.com> wrote:
Dear list,



Apologies if this has been brought up before. I searched the archives

but didn't find anything related.

I am working on a web application + api that uses OAuth2 implicit flow

and Bearer tokens.



It occurred to that when the API responds with a 401 request, a useful

addition would be that the api also informs the user of the OAuth2

authentication endpoint to redirect the user to.



It makes sense to me to do this via a HTTP Link header. A response could
=

look as follows:



HTTP/1.1 401 Unauthorized

WWW-Authenticate: Bearer

Link: <https://auth.example.org/authenticate> rel=3D"oa=
uth2-authenticate"



The reason I'm emailing is because I wanted to gauge whether this is

interesting, or if there are problems with this approach.



If it is interesting, I would like to take a stab at writing an IETF

draft for this.



Cheers,

Evert







_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






CONFIDENTIALITY NOTICE: This email may contain confidential and pr=
ivileged material for the sole use of the intended recipient(s). Any review,=
 use, distribution or disclosure by others is strictly prohibited..  If=
 you have received this communication in error, please notify the sender imm=
ediately by e-mail and delete the message and any file attachments from your=
 computer. Thank you.
______________________________________________=
_
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

--Apple-Mail-47BE1F79-66FC-4BB6-9F99-4D90EF7E324A--


From nobody Fri Sep 28 20:10: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 9B11F128B14 for ; Fri, 28 Sep 2018 20:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=ef88T7k4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sXNg4Gin
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 XZRQBsaFhVXY for ; Fri, 28 Sep 2018 20:10:55 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28C4127AC2 for ; Fri, 28 Sep 2018 20:10:54 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1501721E8D for ; Fri, 28 Sep 2018 23:10:53 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 28 Sep 2018 23:10:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=bTI3KC7azDUKft9whuS1FVqiqIebCBgS7JsoL1L80+A=; b=ef88T 7k4nPnn14L8FUasYxTKEYS7uekmkv2itm2PycqM0VsmImmXlYpMSO/yW2zQL4+9t Y1ANonLuKVPgBs92UAMTtvbfkGRrqtAOvv7oAYZl2xNiyFn/Rc8FvcYd7uCRctJ2 Wnlxfws8HPl+wVqCbYRnbsnPyVhlNyeYmyjedA=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=bTI3KC7azDUKft9whuS1FVqiqIebC BgS7JsoL1L80+A=; b=sXNg4GinkU3C08mL3y/NH/gTzqjHBUX0DO7WYxAwwGTG4 zubwo+f7uqv1zcHyzLRPkdgxlxoJpKKcg+4jUAxRsVbRHW3eQrBnf4t/XBjM9rUS Taiy4lVg53gMZpP75DsUOfCzRlV1kN72tXWhcQPBOJ66zm9JHjjVAFwIfSetM8M0 zVGs6COY3VmabXYbJ3mzvIqtUgJuukZznCftlORcT5ZEbxzIMcsEHYXx2+T2U4Oz JNIXSeEvzokRYhg4IFa2TiW9zIDd+3fkNmIOGdZSzpMJzUVgZNi6PFkyL6Uf6MKh VKbDCgRxnW5jFNs+cZCGOGowONfXidAifi/RZZVHA==
X-ME-Proxy:      
X-ME-Sender: 
Received: from [10.6.15.6] (ip-31-39-52-196.chicago.us.northamericancoax.com [196.52.39.31]) by mail.messagingengine.com (Postfix) with ESMTPA id 8CD47102D6 for ; Fri, 28 Sep 2018 23:10:52 -0400 (EDT)
To: oauth 
From: Evert Pot 
Openpgp: preference=signencrypt
Autocrypt: addr=me@evertpot.com; keydata= xsFNBFtJFSYBEADPmEBaJC5Ey79441MLntdIDOecV/Jvro+k0nPT4pnlxyJX5nDDN7NP2FcW Z+QyQJ5Ib1K2OP317EE1RZ0yQVXdlBcG4Hn5ggUJ21cq3HAvOAs3CNuJtTtTcQWa+mMxcie1 27qcsvu4HZOoaEWnZl7nkhXcyj6VoBCrjCpnHr8bMDdcvj2tf6gLhqL+P0WflVd/5i8Y/3t3 nyiU7kTt49+h5P2h40oLc8IyO1LMHYf8937k//zImnBxOW/0h0uWAXawv0FJAKV6BcKu+3z7 woO7niTmlOmwHz1bF9BywDZmWsPZU8Etmthej3SH01LB96hEexjygOjVVcEbZEPnQxoyg1PR 4FgkYj/JFp80I4bOI49ZrUcjdxzjRS6yIvr2WTdqpEHbRayiuAWxA8OIt2aFjb9rPahZTyUt bn9g8mWCkKUqoKMbMiEQvpB2pNsDF5A25Z62FkSwk96a0I2NXEF47Xf3wpvtrBDm5WuuADfX OfAGsFdTU0X52uRlbfOnO+yDGmJnReWqewf95I7ikygbegNIQh8P7NSKK5mdCE8o7DiUb3iD rriBrp6qQmzvF1TezLjoI8MWDfAYWrRsxA4mwAKHIZ0HGLUZTA3bw9+07FRpL4oOdJUMc9J6 m8mP+HWE+gQpS7cinv9HC0FUp0Dhp/0BZkwvsslQQ9FdQCsMiwARAQABzRtFdmVydCBQb3Qg PG1lQGV2ZXJ0cG90LmNvbT7CwZQEEwEIAD4WIQSkMuXfRzs70V6UIiq3UVOR0jM1HQUCW0kV JgIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC3UVOR0jM1HdAgEACmQtD4 GCyhdJ7EZd0PHlkHrjaCDnE7YRIZDT8977GxBxyQYeCdh7QoMhpW/fyFxBmL8AAlv9VgB/Jq 9Mb5/UbQdb8ZeRQ8qub/bn7X3pRzSp9qHZzT67Vd+qGHdlUegoLV4/rvhZHrV81dayHAZ8rf Mn3U4CkKFyan+ZK8Psou5TIP7L4fXz97P/K296p+Qp9vRvjCBiX+cls3xlSgHdOgIbuJCjp9 yMxnLw8kk3KUtb1epmqFzNOr01GGWcyksKoCyc8TtZWgJuT7yswapHn3tjCTvcVAqZiVr+RJ gFQhyr8S8P4NwK3Sgk0Ogz++mVjpa/2Rh1XSESeiRLG895ofNaS8hmrfOrxnTuejQ/YyeojK 7luEFYa/0OqK1pS9Z0wI42pdemFELGg704wyHQDEkYDLfoFXi+PHZI6EX6LGnvnvKBic4nHi DpYjdqR5cbjyAhJdIZRENpvmBaiRR4ZTAZXnQEX2Zq6tFAboNJJ6G5feNWyDPScgHO+ZNP71 28nIsEkSum3ymyRdhMkbeIEZ5BRv/RPhxSyt/40YBi3YIacSkO508L6ALcUCUN/bYRj2pDkN h7nsH2E11SeeqUXGQuMjvTmJL8go2ndods/gL0E2HBo4oExKvmdCJY1FZaI50d8KjUZJLWxH 4QDWD3QFaKkVQIv/5dFpq40TZjtbFc7BTQRbSRUmARAAuRzGx8azFVYPwszmYutW6rOnWOno 8+EcGL6Pmoe5/2czxxjqofp4Gsy41jbyKsSqyVjBHGzY0yOzZc7fmNb4m6ef8jFteWhRECmI 4vZl1/9/gekvxDEDqrvKH6RbN944MdS5qovINBbomxq7ND/Dl524sylq+51nmJSW0MqazwqL wHW46LC7bur3F/jzGsv3o5qtZK0PUQi/HSH68CT6NnIbyMdrcgvjNKm3hb2/9h9MASd1xv58 tLeIt1ndcgocZVgwAqExj7iGFXbU0N24kig3bV4i3zJtUW/OSRr8YUJEG8blCnn4cJrGcqz/ YjvOdXEWzpOmQ+eVg7CPFO+gwdG4WaS5DdAcE6F/ooXQT+dgQ5hU4vgKmvso+ckd/0kuMhMH 5x8G91YjqgucEhBA1h4npy/KJVuDj8/qpbgVxtyoYTYuIgA3avK7lxZNb9ZxH+oqYFhkDjHg T56aBU0BAl1CcH7pddh9TY38Joj69cNoImXSL0xUc6qQxd+aFcT2dpFRVkNvfz9DA2/Q8gTA J3U1s9w2wdkZzK0saFzuvuPCAQjytNfn5hIuRyr871XUD9JV/uxbEiJBIBJl7sXpMsjupYKs m5cWo4wtVsDPgt2EmmiZR2hCo43BUhznX7vfeGos4tX4XIAyTr9y/KZA/y1Qq16bZqI1MiHL /ueJLI8AEQEAAcLBfAQYAQgAJhYhBKQy5d9HOzvRXpQiKrdRU5HSMzUdBQJbSRUmAhsMBQkJ ZgGAAAoJELdRU5HSMzUd3jYP/2iaMvJx9AUZBbfn/qidsd3an4sVeNb0Pn3webhxYhVvx4lV oFwfnQzQ9c4c+LMQ3QS6avYxLaRGQEDssCgHp+M4bhfchAbKfkDp0Fsk3XrqT3dqc41ljP+d n7Ov2qjS2fYjMet3APJw0fLmb9Y6Z4qd3SfVB3HblH0Lw+XgZJna6fEwJIb2F2yn/vihmBCx A86o1PeXZLHsc+kI3jY17xuTwd954K006W0u7/aqyo6oDCZGUdbBk1hvLYdprdaLD26xA527 uBMSAnOraVwM00wiVbT8ETr3yn5aTcVqcCIc5PydppTtowvtisvOQH2Xe8ygkjivBbDC2aMa ZHTtj8OBVCQHotv0Iw7+aEx+7qswCEkOiIYbtxy/K1wpFrm9VyWNXDimhjekiqDsO9CHAMtF FpbC7yH3063XdmGtHKow2J6xSPDxegCL6xKcYy8Huu4OqMxByjhMjFryG5/nCNd377VRy4S9 N9KG0VJAX4d5WE2qxXIiF1QX8mhddIuyzF8Uluil/G94+RFnO0+9Rl3J6iNK3z/AvQTpjpDD hpZTmkXbReG5q0gl175BFhKR0I7NeEOktZh5BjqGjRYnI7r6LkpS2jhPEpNI2YE43SqYNqkJ ecxvs9rmd//9lA2rzvtXzd/rvO2rqZl5dqzLlnOraaEDpTbOcVeMbtbyKzPA
Message-ID: 
Date: Fri, 28 Sep 2018 23:10:51 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [OAUTH-WG] draft-hardt-oauth-distributed suggestions
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: Sat, 29 Sep 2018 03:10:58 -0000

I read the Distributed OAuth draft, and I have a few comments and questions:

The draft defines 2 new link relations. "resource_uri" and
"oauth_server_metadata_uri". However, the underscore is actually invalid[1].
On the IANA Links Relations registry[2], most existing link relations
use dashes, or occasionally camel-case as a separator. I would suggest
using dashes. I also don't think that the _uri postfix is needed, as the
implication of any link is that it points to a uri.

A second question I have is related to the resource_uri. The way I
expect this specification to be used, is that a client will attempt to
access a resource. When accessing it will be met with a 401
Unauthenticated along with meta-data that will help the client authenticate.

To me the implication of this is that the resource_uri is the uri that
the client tried to access. A more appropriate existing link relation
might therefore be the 'self'. However, why would a resource server ever
need to communicate what it's own url is? The explanation I can think of
is that this is a mechanism for a resource to suggest a different
resource to authenticate for.

I'm curious what the use-case for this is. Regardless, I feel that the
"resource_uri" name is going to be rejected on the basis that 'Resource
Uri' is a generic concept on the web, but this draft assigns a very
specific oauth2 meaning to it.

I also have a question:

One thing I've missed from using OAuth2-powered services over HTTP Basic
/ Digest, is the ability for a browser to handle login. The idea that a
browser can potentially do all the steps required, means that a user
could potentially hit a resource server directly and browse it
interactively without requiring a non-browser client. I think this
concept is really powerful, and Distributed OAuth is a good step in that
direction.

The piece that's missing though is that using the current OAuth2
framework, a generic client would still need to have a client_id.

I don't fully understand the security implications of this, but could
this specification potentially be expanded so that the WWW-Autenticate
challenge can optionally also include a client_id?

The way I see this work is that a browser could grab it and attempt
using it with the implicit flow.

I did some experimentation with this, and I believe that this feature
could actually be built as a web extension, but it will only work in
Firefox as Chrome does not give web extensions access to the
Authorization header.

If there is interest in this idea, I'm happy to help edit the current draft.

Evert

[1]: https://tools.ietf.org/html/rfc8288#section-3.3
[2]: https://www.iana.org/assignments/link-relations/link-relations.xhtml
[3]: