From nobody Tue Mar 1 00:39:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862C01B35BF for ; Tue, 1 Mar 2016 00:39:29 -0800 (PST) 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 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 R6OlYGYlfydy for ; Tue, 1 Mar 2016 00:39:27 -0800 (PST) Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5989B1B35BE for ; Tue, 1 Mar 2016 00:39:27 -0800 (PST) Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa08-05.prod.phx3.secureserver.net with id QYfR1s00115ZTut01YfRhe; Tue, 01 Mar 2016 01:39:26 -0700 To: oauth@ietf.org References: <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com> <17E6C845-D633-45F6-A123-515437583F02@oracle.com> <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com> <56CEC24C.8040709@connect2id.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <56D5553C.3070709@connect2id.com> Date: Tue, 1 Mar 2016 10:39:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090305020601000302080108" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 08:39:29 -0000 This is a cryptographically signed message in MIME format. --------------ms090305020601000302080108 Content-Type: multipart/alternative; boundary="------------010807070302090506040608" This is a multi-part message in MIME format. --------------010807070302090506040608 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/16 00:34, Brian Campbell wrote: > +1 for "OAuth 2.0 Authorization Server Discovery=94 from those two opti= ons. > > But what about "OAuth 2.0 Authorization Server Metadata=94? > > The document in its current scope (which I agree with, BTW) isn't reall= y > about discovery so much as about describing the metadata at some > well-known(ish) resource. This sounds even more precise. The updated draft no longer mentions how the client arrives at the AS metadata URL, just its format and parameters. So the discovery bit is essentially gone from it. Because if we take the OIDC definition of discovery, then "OpenID Provider Issuer discovery is the process of determining the location of the OpenID Provider." (from http://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery= ) So the draft has been reduced to mimicking sections 3 and 4 of OIDC Discovery: 3. OpenID Provider Metadata -> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadat= a 4. Obtaining OpenID Provider Configuration Information -> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig I would like to vote for "OAuth 2.0 Authorization Server Metadata=94 Cheers, Vladimir > On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones > wrote: > >> It=92s clear that people want us to move to the name =93OAuth 2.0 >> Authorization Server Discovery=94. The editors will plan to make that= >> change in the draft addressing Working Group Last Call comments. >> >> >> >> Thanks all, >> >> -- Mike >> >> >> >> *From:* Samuel Erdtman [mailto:samuel@erdtman.se] >> *Sent:* Saturday, February 27, 2016 6:47 AM >> *To:* Mike Jones >> *Cc:* Vladimir Dzhuvinov ; oauth@ietf.org >> >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location >> >> >> >> +1 for =93OAuth 2.0 Authorization Server Discovery=94 >> >> >> >> //Samuel >> >> >> >> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones >> wrote: >> >> Thanks for your thoughts, Vladimir. I=92m increasingly inclined to ac= cept >> your suggestion to change the title from =93OAuth 2.0 Discovery=94 to = =93OAuth >> 2.0 Authorization Server Discovery=94. While the abstract already mak= es it >> clear that the scope of the document is AS discovery, doing so in the = title >> seems like it could help clarify things, given that a lot of the discu= ssion >> seems to be about resource discovery, which is out of scope of the doc= ument. >> >> >> >> I=92m not saying that resource discovery isn=92t important =96 it is =96= but >> unlike authorization server discovery, where there=92s lots of existin= g >> practice, including using the existing data format for describing OAut= h >> implementations that aren=92t being used with OpenID Connect, there=92= s no >> existing practice to standardize for resource discovery. The time to >> create a standard for that seems to be after existing practice has >> emerged. It **might** or might not use new metadata values in the AS >> discovery document, but that=92s still to be determined. The one reas= on to >> leave the title as-is is that resource discovery might end up involvin= g >> extensions to this metadata format in some cases. >> >> >> >> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 >> applies. 6749 is about the AS. 6750 is about the RS. The discovery >> document is about the AS. We don=92t yet have a specification or exis= ting >> practice for RS discovery, which would be the 6750 analogy. >> >> >> >> In summary, which title do people prefer? >> >> =B7 =93OAuth 2.0 Discovery=94 >> >> =B7 =93OAuth 2.0 Authorization Server Discovery=94 >> >> >> >> >> >> >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010807070302090506040608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 01/03/16 00:34, Brian Campbell wrote:
+1 for "OAuth 2.0 Authorization Server Discovery=94 =
from those two options.

But what about "OAuth 2.0 Authorization Server Metadata=94?

The document in its current scope (which I agree with, BTW) isn't really
about discovery so much as about describing the metadata at some
well-known(ish) resource.

This sounds even more precise. The updated draft no longer mentions how the client arrives at the AS metadata URL, just its format and parameters. So the discovery bit is essentially gone from it.

Because if we take the OIDC definition of discovery, then

"OpenID Provider Issuer discovery is the process of determining the location of the OpenID Provider."

(from http://openid.net/specs/= openid-connect-discovery-1_0.html#IssuerDiscovery )

So the draft has been reduced to mimicking sections 3 and 4 of OIDC Discovery:

3.=A0 OpenID Provider Metadata -> http://openid.net/specs/ope= nid-connect-discovery-1_0.html#ProviderMetadata
4.=A0 Obtaining OpenID Provider Configuration Information -> http://openid.net/specs/o= penid-connect-discovery-1_0.html#ProviderConfig

I would like to vote for "OAuth 2.0 Authorization Server Metadata=94<= br>

Cheers,

Vladimir


On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones &=
lt;Michael.Jones@microsoft.com>
wrote:


It=92s clear that people want us to move to the na=
me =93OAuth 2.0
Authorization Server Discovery=94.  The editors will plan to make that
change in the draft addressing Working Group Last Call comments.



                                                          Thanks all,

                                                          -- Mike



*From:* Samuel Erdtman [mailto:samuel@erdtman.se]
*Sent:* Saturday, February 27, 2016 6:47 AM
*To:* Mike Jones <Michael.Jones@microsoft.com>
*Cc:* Vladimir Dzhuvinov <vladimir@connect2id.com>; oauth@ietf.org<=
/a>

*Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location



+1 for =93OAuth 2.0 Authorization Server Discovery=94



//Samuel



On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <Michael.Jones@micro=
soft.com>
wrote:

Thanks for your thoughts, Vladimir.  I=92m increasingly inclined to accep=
t
your suggestion to change the title from =93OAuth 2.0 Discovery=94 to =93=
OAuth
2.0 Authorization Server Discovery=94.  While the abstract already makes =
it
clear that the scope of the document is AS discovery, doing so in the tit=
le
seems like it could help clarify things, given that a lot of the discussi=
on
seems to be about resource discovery, which is out of scope of the docume=
nt.



I=92m not saying that resource discovery isn=92t important =96 it is =96 =
but
unlike authorization server discovery, where there=92s lots of existing
practice, including using the existing data format for describing OAuth
implementations that aren=92t being used with OpenID Connect, there=92s n=
o
existing practice to standardize for resource discovery.  The time to
create a standard for that seems to be after existing practice has
emerged.  It **might** or might not use new metadata values in the AS
discovery document, but that=92s still to be determined.  The one reason =
to
leave the title as-is is that resource discovery might end up involving
extensions to this metadata format in some cases.



I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
applies.  6749 is about the AS.  6750 is about the RS.  The discovery
document is about the AS.  We don=92t yet have a specification or existin=
g
practice for RS discovery, which would be the 6750 analogy.



In summary, which title do people prefer?

=B7       =93OAuth 2.0 Discovery=94

=B7       =93OAuth 2.0 Authorization Server Discovery=94



             <OAuth@ietf.org>






      

      

      

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


    

    

  


--------------010807070302090506040608--

--------------ms090305020601000302080108
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
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAzMDEwODM5MjRaMC8GCSqGSIb3DQEJBDEiBCDlZbhelWVynzQRibenKGADnq2bbmAz
U5pEc9UUhHgOrTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQAXgzL+r0e8
vVTekO05uHDrkSFyeYVfAfrvcIkoKnTsSWJ/gNq6K3X8SclPv+mrDqhVWXv3mJH5+bbSsUO6
0pVKkl4m30h8s4NfyN3vfCg5bDGM8azahms43qrtqw8/gbBpC3E4Zo+bOXSReXQohtd8ghQD
qUX1O+dOx1EbOf33ZsDRz4XcHtfmYYsII4SKmqak4s6YznB0Dbo5vLuG4VU/kHf69WC/iMCo
ejNzer6Et+q63V1czFENR5tIeje1Ra471GvGqeODGbPSSqIyWFGwbo79jHlEJ4IoKgvWulse
sCdsUn4KlU2LcoTuMv61sBbTP2B3XfBFVE1/skNxjWsNAAAAAAAA
--------------ms090305020601000302080108--


From nobody Tue Mar  1 00:51:22 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7F1B360F for ; Tue,  1 Mar 2016 00:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level: 
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 IPDfMAABPWnY for ; Tue,  1 Mar 2016 00:51:10 -0800 (PST)
Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E671B2CEA for ; Tue,  1 Mar 2016 00:51:10 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa12-09.prod.phx3.secureserver.net with  id QYr81s00A15ZTut01Yr9k0; Tue, 01 Mar 2016 01:51:09 -0700
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net>  <56D1E7E7.7070200@connect2id.com> 
Cc: oauth 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56D557FB.30701@connect2id.com>
Date: Tue, 1 Mar 2016 10:51:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040003020704030207000007"
Archived-At: 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2016 08:51:12 -0000

This is a cryptographically signed message in MIME format.

--------------ms040003020704030207000007
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi John,

On 28/02/16 01:15, John Bradley wrote:
> If the malicious client is registering it=E2=80=99s own redirect URI th=
en option A won=E2=80=99t help.=20
>
> On the other hand the Good AS should identify the malicious client to t=
he user.

How could that be done in practice, especially with an AS that provides
a channel for dynamic discovery and registration?

> I think this is a separate problem of client impersonation being used f=
or Phishing.
>
> This is really a case of bad guy registers client and phishes the user =
to login pretending to be some other client.
>
> That can all be done with the good client not being involved at all.=20

OK.

Vladimir


>
> John B.
>
>> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov  wrote:
>>
>> Hi Brian,
>>
>> On 27/02/16 00:27, Brian Campbell wrote:
>>> My preference is for Option A.
>>>
>>> The mix-up attack, in all it's variations, relies on there being no m=
eans
>>> in OAuth for the AS to identify itself to the client when it returns =
the
>>> user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitiga=
tion'
>>> addresses that fundamental missing piece by including the 'iss'
>>> authorization response parameter.
>> This fundamental piece is indeed missing. I'm not sure measure "A" can=

>> also cover dynamic discovery and registration though. The mixup attack=

>> was originally described there, with OpenID Connect.
>>
>> How about this variation:
>>
>> Suppose the malicious IdP:
>>
>> 1. Registers the client under attack for
>> a) malicious authz endpoint
>> b) malicious token endpoint (optional)
>>
>> ... while also acting as proxy, where there are two variants:
>> a) repeats the client registration with the honest IdP to obtain
>> client_id + credentials that it keeps for itself; or
>> b) is already registered as a client with the honest IdP
>>
>> Then:
>>
>> 1. When the authz request is made to the malicious authz endpoint, the=

>> request is rewritten with the client_id and redirect_uri which the
>> malicious IdP has with the honest IdP. The state may or may not be rep=
laced.
>>
>> 2. The browser is then given a second redirect with the rewritten
>> parameters to the authz endpoint of the honest IdP.
>>
>> 3. The user doesn't notice this double redirect, and logs in / gives
>> consent.
>>
>> 4. The honest IdP sends the browser back to the registered malicious
>> redirect_uri. The attacker receives the code or tokens (depending on t=
he
>> response type)
>>
>> 5. A second redirect is made back to the redirect_uri of the client,
>> with rewritten state, iss, client_id
>>
>>
>> What is your take on this?
>>
>> The ideal fix for me would be one that covers dynamic discovery and
>> registration as well. I'm not convinced option A does that.
>>
>> Cheers,
>>
>> Vladimir
>>
>>> During the course of the discussions in Darmstadt Hans and I independ=
ently
>>> implemented and successfully interop tested the 'iss' and 'client_id'=

>>> authorization response parameters, which is what was anticipated to b=
e in
>>> the mitigation draft. Doing so was very simple and straightforward. A=
nd it
>>> addresses the vulnerability. We decided, unfortunately, to pull that
>>> functionality out of a looming a product release due to the churn in =
this
>>> WG and the perceived risk of changes in what would eventually become =
the
>>> standard solution. Of course, that kind of risk is always present wit=
h
>>> draft standards but it's been very frustrating in this case to have w=
orked
>>> towards a simple solution to a known problem only to have progress ge=
t hung
>>> up in lack of agreement in this WG.
>>>
>>> I'll also say that in many/most cases the AS doesn't explicitly know =
all of
>>> the resources that tokens it issues can or will be used at (and there=
 are
>>> often more than one). So the ruri/Resource URI parameter isn't really=
 a
>>> workable option.
>>>
>>>
>>>
>>> On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
>>> hannes.tschofenig@gmx.net> wrote:
>>>
>>>> Vladimir,
>>>>
>>>> yes, we could do a formal analysis and it would be a very good idea.=

>>>> It would even go faster if a few of us work together on it. Anyone
>>>> interested?
>>>>
>>>> This would be a good contribution for the workshop in July, btw.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>>>>> Hi Mike,
>>>>>
>>>>> You mention that you spent considerable time in research. I wonder =
if
>>>>> there is existing theory, in communications or information theory, =
that
>>>>> can be used to formally establish and prove (or disprove) the secur=
ity
>>>>> of the proposed OAuth measures? Perhaps some work that is totally
>>>>> unrelated to identity and the web protocols, but could well apply h=
ere?
>>>>>
>>>>> My reasoning is that we have a closed system that is fairly simple,=
 so
>>>>> formal analysis must be entirely possible.
>>>>>
>>>>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>>>>
>>>>> 2. The OAuth protocol follows a simple and well-defined pattern of
>>>>> messages between the parties.
>>>>>
>>>>> 3. The points and the number of ways by which an adversary may brea=
k
>>>>> into OAuth must therefore be finite.
>>>>>
>>>>> 4. The security requirement is essentially to guarantee the precede=
nce
>>>>> and authenticity of the messages from discovery endpoint to RS, and=
 the
>>>>> preferred way to do that is by establishing a binding between the
>>>>> messages, which can be forward or backward binding.
>>>>>
>>>>>
>>>>> Right now the WG concern is whether all possible attacks have been
>>>>> recognised, and then taken care of. If we can have a formal model t=
hat
>>>>> can reliably reveal and prove that, this will be a huge breakthroug=
h.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Vladimir
>>>>>
>>>>>
>>>>>
>>>>> On 20/02/16 12:41, Mike Jones wrote:
>>>>>> Suggesting that they be read is of course, the right long-term
>>>> approach.  But as someone who spent 20+ years as a researcher before=

>>>> switching to digital identity, I was sensitive to not wanting to ups=
tage
>>>> their work by copying too much of their material into our draft befo=
re
>>>> their publications were widely known.  I'll of course commit to work=
ing the
>>>> researchers and the working group to create a self-contained concise=

>>>> description of the threats and mitigations in the working group docu=
ment.
>>>>>>                             Cheers,
>>>>>>                             -- Mike
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>>>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>>>> To: Mike Jones ; William Denniss <
>>>> wdenniss@google.com>; Phil Hunt (IDM) 
>>>>>> Cc: oauth@ietf.org
>>>>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Ca=
ll
>>>> for Adoption
>>>>>> Hi Mike,
>>>>>>
>>>>>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>>>>>> Have you read both of their publications?  If not, do yourself a =
favor
>>>>>>> and do.  They're actually both very readable and quite informativ=
e.
>>>>>> I have read both documents. In context of this discussion the ques=
tion
>>>> is whether we
>>>>>> (a) require them to be read (in which case they should be a normat=
ive
>>>> reference), or
>>>>>> (b) suggest them to be read (since they provide additional backgro=
und
>>>> information). In this case they are an informative reference.
>>>>>> I believe believe we want (b) for the OAuth WG document. While I
>>>> encourage everyone to read the publications I also believe that ther=
e is
>>>> lots of material in there that goes beyond the information our audie=
nce
>>>> typically reads (such as the text about the formal analysis).
>>>>>> There is probably also a middle-ground where we either copy releva=
nt
>>>> text from the papers into the draft or reference specific sections t=
hat are
>>>> "must-read".
>>>>>> One other issue: I actually thought that the threat that is outlin=
ed in
>>>> the research paper is sufficiently well described but the second thr=
eat,
>>>> which is called 'cut-and-paste attack', requires more work.
>>>>>> I noted this in my summary mail to the list, see
>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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


--------------ms040003020704030207000007
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
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAzMDEwODUxMDdaMC8GCSqGSIb3DQEJBDEiBCDzBYgfItIUzJ6cnlOr5JUDGmjLqnRO
rqXqFZI0DnLovzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBeAsKhZZrr
xFgo71rRysIZ0cz2XdD01/F1dC/P25JVuZVQf78ysZkvr7ElSvl+CrbhPjNefUMBNaVPWUyZ
PCH7/ETxIPVceixwthPj+Z5ZUvqiz29VbfCm4zopHyY7D1BGHGpoqOLpTWIw+UXLlTZVUCYm
3s5ZnKobyL5MydhJKgexJzUQfRJ+7+Fi/r0ni1/Zm+NJsx0idDvOwN7JSCCdmbuSDZ/OJcoj
PfZ8Uc7+lyAGVFXo9mIx9hcK/vuBsj1ZUk6wHgOMXZnbR/4pV2jUFXpdytjN4FtZbcvStTH7
zmHBmqqYn376T5Gqp6NJArgzlEgeJnNb7TfaPgSCDZgWAAAAAAAA
--------------ms040003020704030207000007--


From nobody Tue Mar  1 01:24:54 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC761B369D for ; Tue,  1 Mar 2016 01:24:53 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham
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 YYPNOpCLhtCt for ; Tue,  1 Mar 2016 01:24:52 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 B49AC1B3696 for ; Tue,  1 Mar 2016 01:24:51 -0800 (PST)
Received: by mail-lb0-x22f.google.com with SMTP id bc4so95391705lbc.2 for ; Tue, 01 Mar 2016 01:24:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lHvdfISpfin0l+JXOM5osYLM+Ls745zP1AKP/Uaiyhk=; b=kQsir4jZVu77kKi9MWErZaFrSKKL9jRBXsRRQzcnBNfaGPOofA10arfT1ZB0EopsoC C7RF8jjuAqLF8johSoIzVn4im+ORkkuhFAkjNRVd2Yzg2uHswT9vOutusC8N4TzFTjQA LYradg/FtysqJ3gxYkS+Hmj2W7XF2gGI2PRSJ0kxU2OwLZrVlRtcQDzhWSxrCzAHbJMZ os3YGtxTB4K0YF2TM595nCYwHSsJL/iuTu6ngi+9Ge47p9shr1mMtNjqc40o8V0tlnhl +KmMkWIMnTLAf0uiUIMGQqruBMMbDWdyNGzGg20ejgw98SLb3uS/x36kTY14QvjGHoXZ 78rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lHvdfISpfin0l+JXOM5osYLM+Ls745zP1AKP/Uaiyhk=; b=H0s+Glf08p+2GM7Y2G+zEQaCv3TWdvyl6ZFCqHCE1KEFqIAhnmKY+sHhwqGxO8b0P2 oPqvDgHm30meSKMOiaCrlKLPyX2MqKSj5XwGIN31+LKcHU1uAZFhIZA4elQpsLrMNS4w J/h3p0VhRGfoTm58JNQVMd/sIRLfJO6/ykjGi32+xayqFC0D5Af6x0Pzkerxo9zIKhme c2XzcPJ69GJ5Fni1B6QdR/V46oGqR+JgVxn+uOsPsBJE+/smSyLWx+FvlqEtSLerthjR q3uAR4Qp7cLcT16LUJChkdPnV2Ji6BcXtlO6E5oK5fbljab2l0zYs7r9oe4zdIQ43+oG ftIA==
X-Gm-Message-State: AD7BkJJLy5ad28GtEl7GjkRjTDOhdaGazB4ddpx29tYYTKQCp6RU2DhxPXdxP8YHDdEtT2tfeJETmeWtq/xsLA==
X-Received: by 10.112.199.7 with SMTP id jg7mr5812126lbc.109.1456824289875; Tue, 01 Mar 2016 01:24:49 -0800 (PST)
MIME-Version: 1.0
References:      <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>    
In-Reply-To: 
From: Thomas Broyer 
Date: Tue, 01 Mar 2016 09:24:39 +0000
Message-ID: 
To: Brian Campbell , Mike Jones 
Content-Type: multipart/alternative; boundary=001a11c259a44c5ea9052cf95646
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2016 09:24:53 -0000

--001a11c259a44c5ea9052cf95646
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 29, 2016 at 11:35 PM Brian Campbell 
wrote:

> +1 for "OAuth 2.0 Authorization Server Discovery=E2=80=9D from those two =
options.
>
> But what about "OAuth 2.0 Authorization Server Metadata=E2=80=9D?
>
> The document in its current scope (which I agree with, BTW) isn't really
> about discovery so much as about describing the metadata at some
> well-known(ish) resource.
>

+1

(in case that wasn't obvious already by my previous mails)

--001a11c259a44c5ea9052cf95646
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon=
, Feb 29, 2016 at 11:35 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
+1 for "OAuth 2.0 Author=
ization Server Discovery=E2=80=9D from those two options.

But what a=
bout "OAuth 2.0 Authorization Server Metadata=E2=80=9D?

T=
he document in its current scope (which I agree with, BTW) isn't really=
 about discovery so much as about describing the metadata at some well-know=
n(ish) resource.=C2=A0

+1

(in case that wasn't obvious already by my previous m=
ails)


--001a11c259a44c5ea9052cf95646--


From nobody Tue Mar  1 06:33:55 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BB1A88F6 for ; Tue,  1 Mar 2016 06:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
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 mCW0OlTtCiZR for ; Tue,  1 Mar 2016 06:33:50 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 2D6BB1A8901 for ; Tue,  1 Mar 2016 06:33:50 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id s5so69676100qkd.0 for ; Tue, 01 Mar 2016 06:33:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=o0xnLTA0m+V/DMS5OSHFE4sxr5G34G2fpQcTYkDnh2s=; b=YevsXXqdWHv/MwO1r6aFUA2lNq2onsD0KLlvxblBF9/NzPJtD4MB9bXGIqoACU6Oli udEIR0f+zKXe6+AeY7SV2qPvQVlCQSJBhPsUeY4z7eDyx8zHWO8DA/ltEQiXMy9SPeyd jKsSzbTvd4kkjAgKnG6zfIXGn0P0fkbLtT3f9Uj63qkuxobqeLfz1s7xHvSzxQb93+MD 7NxNDdH7vKIkr2WptUEObOhQppcvmaFFCTT7J1vw/WlfSC8EJb9hdfwIeWRMASoTrmZI GdxxiTvA0v3ui01YWAeK6kCEpE72awlJ8g4Y8ww14mZnKylMbCpXDexU7c74AOE8m548 JbiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=o0xnLTA0m+V/DMS5OSHFE4sxr5G34G2fpQcTYkDnh2s=; b=L3yOVpAnwU3QKV4iveFPpvgAATtodpRUYs1cXwzmcE2R9VwtGBeBOoINhJlr0YD7Rb DKCc2BtNOHtxZ+EJzg/Oye4YhbxYWxG9pcN7Moj+A8QDKsDCAHQYgAQew9NB/7TNeY15 5fj5XhRB7gFe6dzUoBYGFFYkbWF4itA7oLjVRgycwEoLn1Azhkpu9/0V3ifjvx50qqxD /OljYreye/vhQXClUKi1rcjPVPZvItlpLy+8fVes7sjltxOyNvQ/Yir0dhR78McEZCtW lJjSy36pCkXcwWWPpMTgrZdxEExnLHtXscjKVUpat2V+xmR4g8oMgho20hf6XbF8eQ+j wxpA==
X-Gm-Message-State: AD7BkJJbilf5fuBRKHOb8kvAQvXWwWLEtpvWlgcuaaWxxCdTeo4PETUjGmHI3X4NuaiZxw==
X-Received: by 10.55.74.9 with SMTP id x9mr27053490qka.81.1456842829154; Tue, 01 Mar 2016 06:33:49 -0800 (PST)
Received: from [192.168.1.36] ([191.115.104.196]) by smtp.gmail.com with ESMTPSA id b24sm13071352qkj.31.2016.03.01.06.33.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 06:33:47 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C0E4FA6A-B72C-424D-AD8D-A5AD5C9E1589"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56D557FB.30701@connect2id.com>
Date: Tue, 1 Mar 2016 11:33:43 -0300
Message-Id: 
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net>  <56D1E7E7.7070200@connect2id.com>  <56D557FB.30701@connect2id.com>
To: Vladimir Dzhuvinov 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2016 14:33:53 -0000

--Apple-Mail=_C0E4FA6A-B72C-424D-AD8D-A5AD5C9E1589
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Inline

> On Mar 1, 2016, at 5:51 AM, Vladimir Dzhuvinov =
 wrote:
>=20
> Hi John,
>=20
> On 28/02/16 01:15, John Bradley wrote:
>> If the malicious client is registering it=E2=80=99s own redirect URI =
then option A won=E2=80=99t help.=20
>>=20
>> On the other hand the Good AS should identify the malicious client to =
the user.
>=20
> How could that be done in practice, especially with an AS that =
provides
> a channel for dynamic discovery and registration?
>=20
Yes that is the question.  I think client impersonation by lying to the =
AS when registering a client as part of a phishing attack is going to =
become more common.

Getting a trusted AS to say you are Tripit or some trusted client when =
you are really a bad guy is becoming a real problem.
This is however not directly connected to the client mix up issue, and =
needs to be addressed separately. =20

One thing we added to dynamic client registration was a software =
statement that can lock down redirect URI for a given client. =20
In the case of Mobile Connect for  Mobile network operators the proposal =
is to have a trusted registration authority that validates clients and =
issues them software statements to register at individual AS.

Validating the developer/client will probably need to be a business =
process, more stringent than just getting a developer account based on =
an email address.   One possibility might be to check if the redirect =
URI has a EV certificate indicating the organization, or trust =
frameworks set up to register clients for conformance with European data =
protection laws (yes with safe harbour going away something like that =
might be required by AS to keep on the good side of the law.  Germany =
did take a run at this once, but it did not work for the internet in a =
practical way)

The biggest issue will probably be identifying native apps.  Custom =
scheme redirects are not real useful.

On iOS and Android(beta) there are now ways for an app to claim a https: =
URI that is controlled by the developer. =
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-00#page-9
That in combination with software statements might be a useful way to =
identify the client and display something useful at the AS.

We need to do more work on this in my opinion.

John B.



>> I think this is a separate problem of client impersonation being used =
for Phishing.
>>=20
>> This is really a case of bad guy registers client and phishes the =
user to login pretending to be some other client.
>>=20
>> That can all be done with the good client not being involved at all.=20=

>=20
> OK.
>=20
> Vladimir
>=20
>=20
>>=20
>> John B.
>>=20
>>> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov =
 wrote:
>>>=20
>>> Hi Brian,
>>>=20
>>> On 27/02/16 00:27, Brian Campbell wrote:
>>>> My preference is for Option A.
>>>>=20
>>>> The mix-up attack, in all it's variations, relies on there being no =
means
>>>> in OAuth for the AS to identify itself to the client when it =
returns the
>>>> user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up =
Mitigation'
>>>> addresses that fundamental missing piece by including the 'iss'
>>>> authorization response parameter.
>>> This fundamental piece is indeed missing. I'm not sure measure "A" =
can
>>> also cover dynamic discovery and registration though. The mixup =
attack
>>> was originally described there, with OpenID Connect.
>>>=20
>>> How about this variation:
>>>=20
>>> Suppose the malicious IdP:
>>>=20
>>> 1. Registers the client under attack for
>>> a) malicious authz endpoint
>>> b) malicious token endpoint (optional)
>>>=20
>>> ... while also acting as proxy, where there are two variants:
>>> a) repeats the client registration with the honest IdP to obtain
>>> client_id + credentials that it keeps for itself; or
>>> b) is already registered as a client with the honest IdP
>>>=20
>>> Then:
>>>=20
>>> 1. When the authz request is made to the malicious authz endpoint, =
the
>>> request is rewritten with the client_id and redirect_uri which the
>>> malicious IdP has with the honest IdP. The state may or may not be =
replaced.
>>>=20
>>> 2. The browser is then given a second redirect with the rewritten
>>> parameters to the authz endpoint of the honest IdP.
>>>=20
>>> 3. The user doesn't notice this double redirect, and logs in / gives
>>> consent.
>>>=20
>>> 4. The honest IdP sends the browser back to the registered malicious
>>> redirect_uri. The attacker receives the code or tokens (depending on =
the
>>> response type)
>>>=20
>>> 5. A second redirect is made back to the redirect_uri of the client,
>>> with rewritten state, iss, client_id
>>>=20
>>>=20
>>> What is your take on this?
>>>=20
>>> The ideal fix for me would be one that covers dynamic discovery and
>>> registration as well. I'm not convinced option A does that.
>>>=20
>>> Cheers,
>>>=20
>>> Vladimir
>>>=20
>>>> During the course of the discussions in Darmstadt Hans and I =
independently
>>>> implemented and successfully interop tested the 'iss' and =
'client_id'
>>>> authorization response parameters, which is what was anticipated to =
be in
>>>> the mitigation draft. Doing so was very simple and straightforward. =
And it
>>>> addresses the vulnerability. We decided, unfortunately, to pull =
that
>>>> functionality out of a looming a product release due to the churn =
in this
>>>> WG and the perceived risk of changes in what would eventually =
become the
>>>> standard solution. Of course, that kind of risk is always present =
with
>>>> draft standards but it's been very frustrating in this case to have =
worked
>>>> towards a simple solution to a known problem only to have progress =
get hung
>>>> up in lack of agreement in this WG.
>>>>=20
>>>> I'll also say that in many/most cases the AS doesn't explicitly =
know all of
>>>> the resources that tokens it issues can or will be used at (and =
there are
>>>> often more than one). So the ruri/Resource URI parameter isn't =
really a
>>>> workable option.
>>>>=20
>>>>=20
>>>>=20
>>>> On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
>>>> hannes.tschofenig@gmx.net> wrote:
>>>>=20
>>>>> Vladimir,
>>>>>=20
>>>>> yes, we could do a formal analysis and it would be a very good =
idea.
>>>>> It would even go faster if a few of us work together on it. Anyone
>>>>> interested?
>>>>>=20
>>>>> This would be a good contribution for the workshop in July, btw.
>>>>>=20
>>>>> Ciao
>>>>> Hannes
>>>>>=20
>>>>> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>>>>>> Hi Mike,
>>>>>>=20
>>>>>> You mention that you spent considerable time in research. I =
wonder if
>>>>>> there is existing theory, in communications or information =
theory, that
>>>>>> can be used to formally establish and prove (or disprove) the =
security
>>>>>> of the proposed OAuth measures? Perhaps some work that is totally
>>>>>> unrelated to identity and the web protocols, but could well apply =
here?
>>>>>>=20
>>>>>> My reasoning is that we have a closed system that is fairly =
simple, so
>>>>>> formal analysis must be entirely possible.
>>>>>>=20
>>>>>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>>>>>=20
>>>>>> 2. The OAuth protocol follows a simple and well-defined pattern =
of
>>>>>> messages between the parties.
>>>>>>=20
>>>>>> 3. The points and the number of ways by which an adversary may =
break
>>>>>> into OAuth must therefore be finite.
>>>>>>=20
>>>>>> 4. The security requirement is essentially to guarantee the =
precedence
>>>>>> and authenticity of the messages from discovery endpoint to RS, =
and the
>>>>>> preferred way to do that is by establishing a binding between the
>>>>>> messages, which can be forward or backward binding.
>>>>>>=20
>>>>>>=20
>>>>>> Right now the WG concern is whether all possible attacks have =
been
>>>>>> recognised, and then taken care of. If we can have a formal model =
that
>>>>>> can reliably reveal and prove that, this will be a huge =
breakthrough.
>>>>>>=20
>>>>>> Cheers,
>>>>>>=20
>>>>>> Vladimir
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 20/02/16 12:41, Mike Jones wrote:
>>>>>>> Suggesting that they be read is of course, the right long-term
>>>>> approach.  But as someone who spent 20+ years as a researcher =
before
>>>>> switching to digital identity, I was sensitive to not wanting to =
upstage
>>>>> their work by copying too much of their material into our draft =
before
>>>>> their publications were widely known.  I'll of course commit to =
working the
>>>>> researchers and the working group to create a self-contained =
concise
>>>>> description of the threats and mitigations in the working group =
document.
>>>>>>>                            Cheers,
>>>>>>>                            -- Mike
>>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>>>>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>>>>> To: Mike Jones ; William Denniss <
>>>>> wdenniss@google.com>; Phil Hunt (IDM) 
>>>>>>> Cc: oauth@ietf.org
>>>>>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: =
Call
>>>>> for Adoption
>>>>>>> Hi Mike,
>>>>>>>=20
>>>>>>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>>>>>>> Have you read both of their publications?  If not, do yourself =
a favor
>>>>>>>> and do.  They're actually both very readable and quite =
informative.
>>>>>>> I have read both documents. In context of this discussion the =
question
>>>>> is whether we
>>>>>>> (a) require them to be read (in which case they should be a =
normative
>>>>> reference), or
>>>>>>> (b) suggest them to be read (since they provide additional =
background
>>>>> information). In this case they are an informative reference.
>>>>>>> I believe believe we want (b) for the OAuth WG document. While I
>>>>> encourage everyone to read the publications I also believe that =
there is
>>>>> lots of material in there that goes beyond the information our =
audience
>>>>> typically reads (such as the text about the formal analysis).
>>>>>>> There is probably also a middle-ground where we either copy =
relevant
>>>>> text from the papers into the draft or reference specific sections =
that are
>>>>> "must-read".
>>>>>>> One other issue: I actually thought that the threat that is =
outlined in
>>>>> the research paper is sufficiently well described but the second =
threat,
>>>>> which is called 'cut-and-paste attack', requires more work.
>>>>>>> I noted this in my summary mail to the list, see
>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>=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
>>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=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=_C0E4FA6A-B72C-424D-AD8D-A5AD5C9E1589
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMDExNDMzNDNaMCMGCSqGSIb3DQEJBDEWBBQFqdkyitMgwi/nF0eMTc2p
iL/mrTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCdjqEjsuhG8/SiuIK1vrCJD9brBivtKRBFy91Mrci8HoUPebPmEMVF
J65V2lu7sxxrU8gKWF4cJOskk/gxQVeLGH92aqtMxHUoqUD8l/GERKNsrg1wvCTDP/lDmDeQmVlE
J01myRTuflXU/jp/6RrKD5aXc4+X18nMbM7T1c6z/eBWuEsWugJN3QttFPwWoxnL+vw/S967LQAe
altAZ0YogS8OzYM7qAZ0f6R84dOm3+gIzv3kSK1U7X+fhycUAUfYGwrAVkW0YCHI4mbaGY7TJc5D
/jSUQ/4sYtRuySIqSyi+rlsr1ch23+Vd/2pw7T9Q3PjpbGL2JYwXc4oSyBVBAAAAAAAA
--Apple-Mail=_C0E4FA6A-B72C-424D-AD8D-A5AD5C9E1589--


From nobody Tue Mar  1 07:35:20 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C01B2D63 for ; Tue,  1 Mar 2016 07:35:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level: 
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 odJi92j4gZd1 for ; Tue,  1 Mar 2016 07:35:16 -0800 (PST)
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA161B2D51 for ; Tue,  1 Mar 2016 07:35:14 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa09-04.prod.phx3.secureserver.net with  id Qfb91s00C15ZTut01fbASZ; Tue, 01 Mar 2016 08:35:11 -0700
References: <56C7702B.2000401@gmx.net>  <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com>  <56C8360C.8010203@gmx.net>  <56C83EEA.8000306@gmx.net>  <56CC21CB.7070404@connect2id.com> <56CEB0A6.4050500@gmx.net>  <56D1E7E7.7070200@connect2id.com>  <56D557FB.30701@connect2id.com> 
Cc: oauth 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56D5B6AD.3090802@connect2id.com>
Date: Tue, 1 Mar 2016 17:35:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020900060209060600050908"
Archived-At: 
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2016 15:35:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms020900060209060600050908
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Inline >

On 01/03/16 16:33, John Bradley wrote:
> Inline
>
>> On Mar 1, 2016, at 5:51 AM, Vladimir Dzhuvinov  wrote:
>>
>> Hi John,
>>
>> On 28/02/16 01:15, John Bradley wrote:
>>> If the malicious client is registering it=E2=80=99s own redirect URI =
then option A won=E2=80=99t help.=20
>>>
>>> On the other hand the Good AS should identify the malicious client to=
 the user.
>> How could that be done in practice, especially with an AS that provide=
s
>> a channel for dynamic discovery and registration?
>>
> Yes that is the question.  I think client impersonation by lying to the=
 AS when registering a client as part of a phishing attack is going to be=
come more common.
>
> Getting a trusted AS to say you are Tripit or some trusted client when =
you are really a bad guy is becoming a real problem.
> This is however not directly connected to the client mix up issue, and =
needs to be addressed separately. =20
>
> One thing we added to dynamic client registration was a software statem=
ent that can lock down redirect URI for a given client. =20
> In the case of Mobile Connect for  Mobile network operators the proposa=
l is to have a trusted registration authority that validates clients and =
issues them software statements to register at individual AS.
>
> Validating the developer/client will probably need to be a business pro=
cess, more stringent than just getting a developer account based on an em=
ail address.   One possibility might be to check if the redirect URI has =
a EV certificate indicating the organization, or trust frameworks set up =
to register clients for conformance with European data protection laws (y=
es with safe harbour going away something like that might be required by =
AS to keep on the good side of the law.  Germany did take a run at this o=
nce, but it did not work for the internet in a practical way)
>
> The biggest issue will probably be identifying native apps.  Custom sch=
eme redirects are not real useful.
>
> On iOS and Android(beta) there are now ways for an app to claim a https=
: URI that is controlled by the developer. https://tools.ietf.org/html/dr=
aft-ietf-oauth-native-apps-00#page-9
> That in combination with software statements might be a useful way to i=
dentify the client and display something useful at the AS.
>
> We need to do more work on this in my opinion.
Thanks John for the exhaustive answer! How do you see this additional wor=
k?

Vladimir

>
> John B.
>
>
>
>>> I think this is a separate problem of client impersonation being used=
 for Phishing.
>>>
>>> This is really a case of bad guy registers client and phishes the use=
r to login pretending to be some other client.
>>>
>>> That can all be done with the good client not being involved at all. =

>> OK.
>>
>> Vladimir
>>
>>
>>> John B.
>>>
>>>> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov  wrote:
>>>>
>>>> Hi Brian,
>>>>
>>>> On 27/02/16 00:27, Brian Campbell wrote:
>>>>> My preference is for Option A.
>>>>>
>>>>> The mix-up attack, in all it's variations, relies on there being no=
 means
>>>>> in OAuth for the AS to identify itself to the client when it return=
s the
>>>>> user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Miti=
gation'
>>>>> addresses that fundamental missing piece by including the 'iss'
>>>>> authorization response parameter.
>>>> This fundamental piece is indeed missing. I'm not sure measure "A" c=
an
>>>> also cover dynamic discovery and registration though. The mixup atta=
ck
>>>> was originally described there, with OpenID Connect.
>>>>
>>>> How about this variation:
>>>>
>>>> Suppose the malicious IdP:
>>>>
>>>> 1. Registers the client under attack for
>>>> a) malicious authz endpoint
>>>> b) malicious token endpoint (optional)
>>>>
>>>> ... while also acting as proxy, where there are two variants:
>>>> a) repeats the client registration with the honest IdP to obtain
>>>> client_id + credentials that it keeps for itself; or
>>>> b) is already registered as a client with the honest IdP
>>>>
>>>> Then:
>>>>
>>>> 1. When the authz request is made to the malicious authz endpoint, t=
he
>>>> request is rewritten with the client_id and redirect_uri which the
>>>> malicious IdP has with the honest IdP. The state may or may not be r=
eplaced.
>>>>
>>>> 2. The browser is then given a second redirect with the rewritten
>>>> parameters to the authz endpoint of the honest IdP.
>>>>
>>>> 3. The user doesn't notice this double redirect, and logs in / gives=

>>>> consent.
>>>>
>>>> 4. The honest IdP sends the browser back to the registered malicious=

>>>> redirect_uri. The attacker receives the code or tokens (depending on=
 the
>>>> response type)
>>>>
>>>> 5. A second redirect is made back to the redirect_uri of the client,=

>>>> with rewritten state, iss, client_id
>>>>
>>>>
>>>> What is your take on this?
>>>>
>>>> The ideal fix for me would be one that covers dynamic discovery and
>>>> registration as well. I'm not convinced option A does that.
>>>>
>>>> Cheers,
>>>>
>>>> Vladimir
>>>>
>>>>> During the course of the discussions in Darmstadt Hans and I indepe=
ndently
>>>>> implemented and successfully interop tested the 'iss' and 'client_i=
d'
>>>>> authorization response parameters, which is what was anticipated to=
 be in
>>>>> the mitigation draft. Doing so was very simple and straightforward.=
 And it
>>>>> addresses the vulnerability. We decided, unfortunately, to pull tha=
t
>>>>> functionality out of a looming a product release due to the churn i=
n this
>>>>> WG and the perceived risk of changes in what would eventually becom=
e the
>>>>> standard solution. Of course, that kind of risk is always present w=
ith
>>>>> draft standards but it's been very frustrating in this case to have=
 worked
>>>>> towards a simple solution to a known problem only to have progress =
get hung
>>>>> up in lack of agreement in this WG.
>>>>>
>>>>> I'll also say that in many/most cases the AS doesn't explicitly kno=
w all of
>>>>> the resources that tokens it issues can or will be used at (and the=
re are
>>>>> often more than one). So the ruri/Resource URI parameter isn't real=
ly a
>>>>> workable option.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
>>>>> hannes.tschofenig@gmx.net> wrote:
>>>>>
>>>>>> Vladimir,
>>>>>>
>>>>>> yes, we could do a formal analysis and it would be a very good ide=
a.
>>>>>> It would even go faster if a few of us work together on it. Anyone=

>>>>>> interested?
>>>>>>
>>>>>> This would be a good contribution for the workshop in July, btw.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> You mention that you spent considerable time in research. I wonde=
r if
>>>>>>> there is existing theory, in communications or information theory=
, that
>>>>>>> can be used to formally establish and prove (or disprove) the sec=
urity
>>>>>>> of the proposed OAuth measures? Perhaps some work that is totally=

>>>>>>> unrelated to identity and the web protocols, but could well apply=
 here?
>>>>>>>
>>>>>>> My reasoning is that we have a closed system that is fairly simpl=
e, so
>>>>>>> formal analysis must be entirely possible.
>>>>>>>
>>>>>>> 1. We have 5 parties (client, AS, RS, user, user agent).
>>>>>>>
>>>>>>> 2. The OAuth protocol follows a simple and well-defined pattern o=
f
>>>>>>> messages between the parties.
>>>>>>>
>>>>>>> 3. The points and the number of ways by which an adversary may br=
eak
>>>>>>> into OAuth must therefore be finite.
>>>>>>>
>>>>>>> 4. The security requirement is essentially to guarantee the prece=
dence
>>>>>>> and authenticity of the messages from discovery endpoint to RS, a=
nd the
>>>>>>> preferred way to do that is by establishing a binding between the=

>>>>>>> messages, which can be forward or backward binding.
>>>>>>>
>>>>>>>
>>>>>>> Right now the WG concern is whether all possible attacks have bee=
n
>>>>>>> recognised, and then taken care of. If we can have a formal model=
 that
>>>>>>> can reliably reveal and prove that, this will be a huge breakthro=
ugh.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Vladimir
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20/02/16 12:41, Mike Jones wrote:
>>>>>>>> Suggesting that they be read is of course, the right long-term
>>>>>> approach.  But as someone who spent 20+ years as a researcher befo=
re
>>>>>> switching to digital identity, I was sensitive to not wanting to u=
pstage
>>>>>> their work by copying too much of their material into our draft be=
fore
>>>>>> their publications were widely known.  I'll of course commit to wo=
rking the
>>>>>> researchers and the working group to create a self-contained conci=
se
>>>>>> description of the threats and mitigations in the working group do=
cument.
>>>>>>>>                            Cheers,
>>>>>>>>                            -- Mike
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>>>>>>>> Sent: Saturday, February 20, 2016 2:25 AM
>>>>>>>> To: Mike Jones ; William Denniss <
>>>>>> wdenniss@google.com>; Phil Hunt (IDM) 
>>>>>>>> Cc: oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: =
Call
>>>>>> for Adoption
>>>>>>>> Hi Mike,
>>>>>>>>
>>>>>>>> On 02/20/2016 10:52 AM, Mike Jones wrote:
>>>>>>>>> Have you read both of their publications?  If not, do yourself =
a favor
>>>>>>>>> and do.  They're actually both very readable and quite informat=
ive.
>>>>>>>> I have read both documents. In context of this discussion the qu=
estion
>>>>>> is whether we
>>>>>>>> (a) require them to be read (in which case they should be a norm=
ative
>>>>>> reference), or
>>>>>>>> (b) suggest them to be read (since they provide additional backg=
round
>>>>>> information). In this case they are an informative reference.
>>>>>>>> I believe believe we want (b) for the OAuth WG document. While I=

>>>>>> encourage everyone to read the publications I also believe that th=
ere is
>>>>>> lots of material in there that goes beyond the information our aud=
ience
>>>>>> typically reads (such as the text about the formal analysis).
>>>>>>>> There is probably also a middle-ground where we either copy rele=
vant
>>>>>> text from the papers into the draft or reference specific sections=
 that are
>>>>>> "must-read".
>>>>>>>> One other issue: I actually thought that the threat that is outl=
ined in
>>>>>> the research paper is sufficiently well described but the second t=
hreat,
>>>>>> which is called 'cut-and-paste attack', requires more work.
>>>>>>>> I noted this in my summary mail to the list, see
>>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>>>>>>>> Ciao
>>>>>>>> Hannes
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--------------ms020900060209060600050908
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
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAzMDExNTM1MDlaMC8GCSqGSIb3DQEJBDEiBCB+o1+o/nesXNVHgdmE78jJ11bI7+1G
fEmfacTXrvSKUjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBXLHWiDkrT
qI/plqPAVLB56gan90hgyeGztGbKHW1pzHhP0SLxlmFnlv8XFhhWpph67un8TljUYsztgKlx
/BGV2CAEsqthTqNJtE3nXggr7bJhRrvJpWn+KSwJCzkmS6aqDV6feucCfAThGPXGTumKdu7P
WLBHR+/+Nk/yLp0K11tHb3v1CqpumAiubduQnBY8i34wQwHggTvNYiDFNpRh1hnsAVfKU5m1
Hb8VIDQj6jZFUxGnQlwp0X+L3Hi0S61kPIKqtK/BiAsM2spkQ3WIvoKZkFo3j9lNcE2Y9sgp
IEvWDlHqSBUHP/Kyh+RuMdHsL+eVWZFoLeULEhuaOKOqAAAAAAAA
--------------ms020900060209060600050908--


From nobody Tue Mar  1 11:31:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F29A1B4054 for ; Tue,  1 Mar 2016 11:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 ZuvxzhwBHRSX for ; Tue,  1 Mar 2016 11:31:27 -0800 (PST)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A442D1B4052 for ; Tue,  1 Mar 2016 11:31:26 -0800 (PST)
Received: from mtaout-aak02.mx.aol.com (mtaout-aak02.mx.aol.com [172.27.2.226]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 9E07138000BB; Tue,  1 Mar 2016 14:31:25 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aak02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4FE5438000083; Tue,  1 Mar 2016 14:31:25 -0500 (EST)
To: Brian Campbell , Mike Jones 
References:   <4724BFD4-B761-40DC-9535-A0968DEAFD66@oracle.com>  <17E6C845-D633-45F6-A123-515437583F02@oracle.com>   <53B19A70-3F17-423F-AE5E-DC6181B8FED7@oracle.com>   <56CEC24C.8040709@connect2id.com>    
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56D5EE06.1090000@aol.com>
Date: Tue, 1 Mar 2016 14:31:18 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000900020909070604070500"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456860685; bh=zP28PF2Mgo+iHe1Qx6fxB6LYlmol0TeELt81Z5Xnp8c=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ZIVcXubEZ09Z69e3WHec/y6ZC8rBDm84ukRjwywqihBhHBnzrZP4X8zGK0mZ8Sa8a maBm/SisoAUdm4Wf4hK46cV2EVQQAwq5lTUyGrlvBpiOj5q+NeUBulVOUwpZ7i1WlX Yw66oGNgbN9+HU8L/D74357OPZ26b+ipJjNCs6vE=
x-aol-sid: 3039ac1b02e256d5ee0d7d31
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2016 19:31:29 -0000

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

I'm fine with this clarification as it is more correctly describes the 
purpose of the document.

Thanks,
George

On 2/29/16 5:34 PM, Brian Campbell wrote:
> +1 for "OAuth 2.0 Authorization Server Discovery†from those two options.
>
> But what about "OAuth 2.0 Authorization Server Metadata�
>
> The document in its current scope (which I agree with, BTW) isn't 
> really about discovery so much as about describing the metadata at 
> some well-known(ish) resource.
>
>
>
> On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones 
> > wrote:
>
>     It’s clear that people want us to move to the name “OAuth 2.0
>     Authorization Server Discoveryâ€. The editors will plan to make
>     that change in the draft addressing Working Group Last Call comments.
>
>     Thanks all,
>
>     -- Mike
>
>     *From:*Samuel Erdtman [mailto:samuel@erdtman.se
>     ]
>     *Sent:* Saturday, February 27, 2016 6:47 AM
>     *To:* Mike Jones      >
>     *Cc:* Vladimir Dzhuvinov      >; oauth@ietf.org
>     
>
>
>     *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>     +1 for “OAuth 2.0 Authorization Server Discoveryâ€
>
>     //Samuel
>
>     On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones
>     >
>     wrote:
>
>         Thanks for your thoughts, Vladimir.  I’m increasingly inclined
>         to accept your suggestion to change the title from “OAuth 2.0
>         Discovery†to “OAuth 2.0 Authorization Server Discoveryâ€.
>         While the abstract already makes it clear that the scope of
>         the document is AS discovery, doing so in the title seems like
>         it could help clarify things, given that a lot of the
>         discussion seems to be about resource discovery, which is out
>         of scope of the document.
>
>         I’m not saying that resource discovery isn’t important – it is
>         – but unlike authorization server discovery, where there’s
>         lots of existing practice, including using the existing data
>         format for describing OAuth implementations that aren’t being
>         used with OpenID Connect, there’s no existing practice to
>         standardize for resource discovery. The time to create a
>         standard for that seems to be after existing practice has
>         emerged.  It **might** or might not use new metadata values in
>         the AS discovery document, but that’s still to be determined. 
>         The one reason to leave the title as-is is that resource
>         discovery might end up involving extensions to this metadata
>         format in some cases.
>
>         I think an analogy to the core OAuth documents RFC 6749 and
>         RFC 6750 applies.  6749 is about the AS. 6750 is about the
>         RS.  The discovery document is about the AS.  We don’t yet
>         have a specification or existing practice for RS discovery,
>         which would be the 6750 analogy.
>
>         In summary, which title do people prefer?
>
>         ·“OAuth 2.0 Discoveryâ€
>
>         ·“OAuth 2.0 Authorization Server Discoveryâ€
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    I'm fine with this
      clarification as it is more correctly describes the purpose of the
      document.

      

      Thanks,

      George

    

    
On 2/29/16 5:34 PM, Brian Campbell
      wrote:

    

    

      

        
+1 for "OAuth 2.0 Authorization Server Discovery†from
          those two options.

          

          But what about "OAuth 2.0 Authorization Server Metadata�

          

        

        The document in its current scope (which I agree with, BTW)
        isn't really about discovery so much as about describing the
        metadata at some well-known(ish) resource. 

        

        

        


          
On Sat, Feb 27, 2016 at 10:48 AM,
            Mike Jones <Michael.Jones@microsoft.com>
            wrote:

            

              

                

                  
It’s
                      clear that people want us to move to the name
                    “OAuth 2.0
                      Authorization Server Discoveryâ€. 
                      The editors will plan to make that change in the
                      draft addressing Working Group Last Call comments.

                  
 

                  
                                                         
                      Thanks all,

                  
                                                         
                      -- Mike

                  
 

                  
                  
From:
                      Samuel Erdtman [mailto:samuel@erdtman.se]
                      

                      Sent: Saturday, February 27, 2016 6:47 AM

                      To: Mike Jones <Michael.Jones@microsoft.com>

                      Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>;
                      oauth@ietf.org

                  

                    


                      Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery
                      Location

                  

                  

                    

                      
 

                      

                        
+1 for “OAuth 2.0
                            Authorization Server Discoveryâ€

                        

                          
 

                        

                        

                          
//Samuel

                        

                      

                      

                        
 

                        

                          
On Thu, Feb 25, 2016 at
                            8:10 PM, Mike Jones <Michael.Jones@microsoft.com>
                            wrote:

                          

                            

                              

                                
Thanks
                                    for your thoughts, Vladimir.  I’m
                                    increasingly inclined to accept your
                                    suggestion to change the title from
                                    “OAuth 2.0 Discovery†to “OAuth 2.0
                                    Authorization Server Discoveryâ€. 
                                    While the abstract already makes it
                                    clear that the scope of the document
                                    is AS discovery, doing so in the
                                    title seems like it could help
                                    clarify things, given that a lot of
                                    the discussion seems to be about
                                    resource discovery, which is out of
                                    scope of the document.

                                
 

                                
I’m
                                    not saying that resource discovery
                                    isn’t important – it is – but unlike
                                    authorization server discovery,
                                    where there’s lots of existing
                                    practice, including using the
                                    existing data format for describing
                                    OAuth implementations that aren’t
                                    being used with OpenID Connect,
                                    there’s no existing practice to
                                    standardize for resource discovery. 
                                    The time to create a standard for
                                    that seems to be after existing
                                    practice has emerged.  It *might*
                                    or might not use new metadata values
                                    in the AS discovery document, but
                                    that’s still to be determined.  The
                                    one reason to leave the title as-is
                                    is that resource discovery might end
                                    up involving extensions to this
                                    metadata format in some cases.

                                
 

                                
I
                                    think an analogy to the core OAuth
                                    documents RFC 6749 and RFC 6750
                                    applies.  6749 is about the AS. 
                                    6750 is about the RS.  The discovery
                                    document is about the AS.  We don’t
                                    yet have a specification or existing
                                    practice for RS discovery, which
                                    would be the 6750 analogy.

                                
 

                                
In
                                    summary, which title do people
                                    prefer?

                                
·      
                                  “OAuth
                                    2.0 Discoveryâ€

                                
·      
                                  “OAuth
                                    2.0 Authorization Server Discoveryâ€

                                
 

                                
            
                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

              

              

            

          

          

        

      

      

      

      

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


    

    

  


--------------000900020909070604070500--


From nobody Tue Mar  1 14:02:41 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4EB1B423C for ; Tue,  1 Mar 2016 14:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level: 
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 HLvmN0vpgIQu for ; Tue,  1 Mar 2016 14:02:36 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 3DD8C1B4257 for ; Tue,  1 Mar 2016 14:02:36 -0800 (PST)
X-AuditID: 1209190c-59fff70000006700-e3-56d6117a8530
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id A7.FB.26368.A7116D65; Tue,  1 Mar 2016 17:02:34 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u21M2X2W030230; Tue, 1 Mar 2016 17:02:34 -0500
Received: from [10.0.1.8] (ip68-104-118-32.lv.lv.cox.net [68.104.118.32]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u21M2R8n005980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Mar 2016 17:02:30 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_46F46E45-1F11-4E7C-9956-091B07F2FE4B"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: 
Date: Tue, 1 Mar 2016 14:02:26 -0800
Message-Id: <693D8AD3-E9E7-4DBB-8466-215C2030BEE5@mit.edu>
References: <003b01d1726f$66036590$320a30b0$@gmail.com> <16802C28-5478-41D5-8596-30C617C89016@mit.edu> <005401d17272$070325a0$150970e0$@gmail.com> <844C70FF-8D41-4D4D-8F9D-F1CAC5D69D9E@mit.edu> <006f01d1728e$f52af250$df80d6f0$@gmail.com> <255B9BB34FB7D647A506DC292726F6E13BBCD3D02F@WSMSG3153V.srv.dir.telstra.com> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixCmqrVsleC3M4Nw3bYsZP46yW2y984rR 4uTbV2wWC+Y3sjuweOycdZfdY8mSn0weH5/eYvGY17GBOYAlissmJTUnsyy1SN8ugSvj6t61 bAX9XxgrXvdcZmtgfHiNsYuRk0NCwETi4tUDQDYXh5BAG5PE3turmCCcDYwSJz++g8ocZZI4 P3kCO0gLs0CCxO1l88DaeQX0JF7duswKYgsLeEv8PdQPZrMJqEpMX9PCBGJzCthJHF7xFKye RUBFYtnl9ewgQ5kFehklTl1dATXISmLKv4UsENteM0lM2DIRbJIIUMe3q9ehjpWV2P37EdME Rv5ZSA6ZheQQiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRNiW3Sjc3MTOnODVZtzg5 MS8vtUjXUC83s0QvNaV0EyM4FiR5djCeeeN1iFGAg1GJhzfj09UwIdbEsuLK3EOMkhxMSqK8 fceBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4P38DyvGmJFZWpRblw6SkOViUxHkL958OExJI TyxJzU5NLUgtgsnKcHAoSfCqCFwLExIsSk1PrUjLzClBSDNxcIIM5wEaHgtSw1tckJhbnJkO kT/FqCglzhsNkhAASWSU5sH1glKVS0aZwitGcaBXhHl3gFTxANMcXPcroMFMQIMl1l8CGVyS iJCSamBct+/guT8bvvns8mdcZS9S5hVnnbBX7m5uk5RWx8kak0vXeObOkvZ8wfqeaZWWh1Tv pcmOs4uKuzSPRPVKr/W2sEzayf+DoTE1Y2f+3e/hn5e+W7Y6KXbzs7YqW7/vpSbP7b8fElwZ 76IcvXjTi5lLV87L3DrjiY3lgpVaPTdDV6l97wh5ypqmxFKckWioxVxUnAgAVy5GVDADAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2016 22:02:40 -0000

--Apple-Mail=_46F46E45-1F11-4E7C-9956-091B07F2FE4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1, this was a driving requirement when I wrote the first strawman. I =
can=E2=80=99t tell you the number of times I had frameworks mess things =
up with OAuth 1, which does exactly the algorithm that you mention =
below.=20

I=E2=80=99m currently in favor of just leaving the repeated parameter =
and header out of the core hashing mechanism. We could, if someone =
wanted to get really clever, introduce a more generic hashing mechanism =
that could handle the whole message in different ways. But I think the =
existing mechanism is good enough for most cases that we can roll with =
it.

 =E2=80=94 Justin


> On Feb 28, 2016, at 7:18 PM, Phil Hunt (IDM)  =
wrote:
>=20
> The issue for any service is that things like gateways and proxies may =
change or add parameters.
>=20
> There is a long tradition with http to mess with things headers and =
payload in the real world. Not ideal, but a certain reality.=20
>=20
> Thus for certain services it is likely only possible to sign a subset =
of params that the client and service provider want to verify did not =
change.=20
>=20
> Phil
>=20
> On Feb 28, 2016, at 18:39, Manger, James =
> wrote:
>=20
>> Being able to selectively include or exclude individual query string =
name=3Dvalue parameters in a signature feels far too dangerous. Always =
sign them all =E2=80=94 with the only exception being the signature =
itself if transmitted as a query string parameter.
>> Unfortunately we do need to selectively include or exclude HTTP =
headers as they are a mix of transport, app-layer, end-to-end, and =
hop-by-hop items.
>> =20
>> Ignoring duplicate query parameter names is a poor design for a =
fairly generic HTTP signing method. My suggestion would be to do a =
stable sort on parameter names. That is, sort the names, but preserve =
the order of values when a name appears multiple times. =E2=80=A6hoping =
that works with almost all frameworks.
>> =20
>> --
>> James Manger
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Brock Allen
>> Sent: Monday, 29 February 2016 12:17 PM
>> To: 'Justin Richer' >
>> Cc: '>' >
>> Subject: Re: [OAUTH-WG] HTTP request signing and repeated =
query/header keys
>> =20
>> Yea, I=E2=80=99m cool with just saying =E2=80=9Cduplicate keys =
won=E2=80=99t work=E2=80=9D for my implementation, unless I do some =
implementation specific thing like sort them by value order or some such =
(but that would have to be on both sides).
>> =20
>> -Brock
>> =20
>> From: Justin Richer [mailto:jricher@mit.edu ]=20=

>> Sent: Sunday, February 28, 2016 8:13 PM
>> To: Brock Allen >
>> Cc: > >
>> Subject: Re: [OAUTH-WG] HTTP request signing and repeated =
query/header keys
>> =20
>> Yeah, that=E2=80=99s the trick =E2=80=94 you don=E2=80=99t want to =
end up replicating the entire HTTP message inside the JWS envelope, =
because then you end up with a SOAP kind of approach where you=E2=80=99re =
not really using the outside HTTP constructs to their fullest anymore.=20=

>> =20
>> In the end, I don=E2=80=99t think this spec is ever going to be =
perfectly universal, but if it can hit a majority of use cases with a =
simple and robust solution, I think we=E2=80=99re in good shape.
>> =20
>>  =E2=80=94 Justin
>> =20
>> On Feb 28, 2016, at 1:50 PM, Brock Allen > wrote:
>> =20
>> Now that I=E2=80=99m thinking about this, the only thing that comes =
to mind is a hash of the value included somehow (which I=E2=80=99m sure =
you=E2=80=99ve already thought of). That=E2=80=99s obviously more =
complexity and overhead for all scenarios to support this edge case.
>> =20
>> -Brock
>> =20
>> From: Brock Allen [mailto:brockallen@gmail.com =
]=20
>> Sent: Sunday, February 28, 2016 4:40 PM
>> To: 'Justin Richer' >
>> Cc: '>' >
>> Subject: RE: [OAUTH-WG] HTTP request signing and repeated =
query/header keys
>> =20
>> Ok, missed that =E2=80=93 thanks.
>> =20
>> For now in my implementation I=E2=80=99m also ignoring this problem =
:)
>> =20
>> -Brock
>> =20
>> From: Justin Richer [mailto:jricher@mit.edu ]=20=

>> Sent: Sunday, February 28, 2016 4:37 PM
>> To: Brock Allen >
>> Cc: > >
>> Subject: Re: [OAUTH-WG] HTTP request signing and repeated =
query/header keys
>> =20
>> In =C2=A77.5 we currently have:
>> =20
>>    The behavior of repeated query parameters or repeated HTTP headers =
is
>>    undefined by this specification.  If a header or query parameter =
is
>>    repeated on either the outgoing request from the client or the
>>    incoming request to the protected resource, that query parameter =
or
>>    header name MUST NOT be covered by the hash and signature. [[ Note =
to
>>    the WG: is this something we need to cover? ]]
>> =20
>> Which is to say: Yeah, that=E2=80=99s a problem, probably. We either =
declare this behavior out of scope and say you can=E2=80=99t use this =
method with that kind of API (or at least those parameters/headers) or =
we define a mechanism for handling that. I=E2=80=99m in favor of the =
former, and removing the text from the generation sections that says =
repeated parameters are processed with no special handling, making them =
explicitly out of scope throughout.
>> =20
>> I would love to see more feedback from the group about this, =
especially if someone=E2=80=99s got a clever solution.
>> =20
>>  =E2=80=94 Justin
>> =20
>> On Feb 28, 2016, at 1:31 PM, Brock Allen > wrote:
>> =20
>> Given that the client can iterate over the query/headers in any order =
to generate the concatenated value to hash, I think there=E2=80=99s an =
issue with query string or header values with repeated keys. I=E2=80=99ll =
stick with query params for simplicity in my sample.
>> =20
>> If a client signs this concatenated query: =E2=80=9Ca=3D1&a=3D2=E2=80=9D=
 then the =E2=80=9Cp=E2=80=9D value in the signed JSON object could be =
this:
>> =20
>> "p": [["a", "a"], "blah"]
>> =20
>> On the resource server, how do you know which key/value pair to put =
in which order for verification? Also, given that different server =
implementations express these incoming parameters in different ways, it =
seems problematic to be consistent.
>> =20
>> Thanks.
>> =20
>> -Brock
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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



--Apple-Mail=_46F46E45-1F11-4E7C-9956-091B07F2FE4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1, this was a driving requirement when I wrote the first =
strawman. I can=E2=80=99t tell you the number of times I had frameworks =
mess things up with OAuth 1, which does exactly the algorithm that you =
mention below. 

I=E2=80=99m currently in favor of just leaving the repeated =
parameter and header out of the core hashing mechanism. We could, if =
someone wanted to get really clever, introduce a more generic hashing =
mechanism that could handle the whole message in different ways. But I =
think the existing mechanism is good enough for most cases that we can =
roll with it.

 =E2=80=94 Justin


On Feb 28, 2016, at 7:18 PM, =
Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:



The issue for =
any service is that things like gateways and proxies may change or add =
parameters.

There is a long tradition with http to mess with things =
headers and payload in the real world. Not ideal, but a certain =
reality. 

Thus for certain services it is likely only possible to sign =
a subset of params that the client and service provider want to verify =
did not change. 

Phil

On Feb 28, 2016, at 18:39, Manger, James =
<James.H.Manger@team.telstra.com> wrote:

Being able =
to selectively include or exclude individual query string name=3Dvalue =
parameters in a signature feels far too dangerous. Always sign them all =
=E2=80=94 with the only exception being the signature itself if =
transmitted as a query string parameter.
Unfortunately we do need to selectively include or exclude =
HTTP headers as they are a mix of transport, app-layer, end-to-end, and =
hop-by-hop items. 
 
Ignoring =
duplicate query parameter names is a poor design for a fairly generic =
HTTP signing method. My suggestion would be to do a stable sort on =
parameter names. That is, sort the names, but preserve the order of =
values when a name appears multiple times. =E2=80=A6hoping that works =
with almost all frameworks.
 
--
James =
Manger
 
From:=
 OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of =
Brock Allen
Sent: Monday, 29 =
February 2016 12:17 PM
To: 'Justin =
Richer' <jricher@mit.edu>
Cc: =
'<oauth@ietf.org>' =
<OAuth@ietf.org>Subject: Re: [OAUTH-WG] HTTP request =
signing and repeated query/header keys
 
Yea, I=E2=80=99m =
cool with just saying =E2=80=9Cduplicate keys won=E2=80=99t work=E2=80=9D =
for my implementation, unless I do some implementation specific thing =
like sort them by value order or some such (but that would have to be on =
both sides).
 
-Brock
 
From:=
 Justin Richer [mailto:jricher@mit.edu] 
Sent: Sunday, February 28, 2016 8:13 PM
To: Brock Allen <brockallen@gmail.com>
Cc: <oauth@ietf.org> <OAuth@ietf.org>
Subject:=
 Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
 
Yeah, that=E2=80=99s the trick =E2=80=94 you =
don=E2=80=99t want to end up replicating the entire HTTP message inside =
the JWS envelope, because then you end up with a SOAP kind of approach =
where you=E2=80=99re not really using the outside HTTP constructs to =
their fullest anymore. 
 
In the end, I =
don=E2=80=99t think this spec is ever going to be perfectly universal, =
but if it can hit a majority of use cases with a simple and robust =
solution, I think we=E2=80=99re in good shape.
 
 =E2=80=94 =
Justin
 
On Feb 28, 2016, at 1:50 PM, Brock Allen <brockallen@gmail.com> wrote:
 
Now that I=E2=80=99=
m thinking about this, the only thing that comes to mind is a hash of =
the value included somehow (which I=E2=80=99m sure you=E2=80=99ve =
already thought of). That=E2=80=99s obviously more complexity and =
overhead for all scenarios to support this edge case. 
 
-Brock
 
From: Brock Allen =
[mailto:brockallen@gmail.com] 
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' <jricher@mit.edu>
Cc: =
'<oauth@ietf.org>' =
<OAuth@ietf.org>Subject: RE: [OAUTH-WG] HTTP request =
signing and repeated query/header keys
 
Ok, missed that =
=E2=80=93 thanks.
 
For now in my =
implementation I=E2=80=99m also ignoring this problem :)
 
-Brock
 
From: Justin =
Richer [mailto:jricher@mit.edu] 
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen <brockallen@gmail.com>
Cc: <oauth@ietf.org> <OAuth@ietf.org>
Subject:=
 Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
 
In =C2=A77.5 we =
currently have:
 
   =
The behavior of repeated query parameters or repeated HTTP headers =
is
   undefined by this specification.  If a =
header or query parameter is
   repeated on =
either the outgoing request from the client or the
   incoming request to the protected resource, that =
query parameter or
   header name MUST NOT be covered =
by the hash and signature. [[ Note to
   the WG: is this something we need to cover? =
]]
 
Which is to say: =
Yeah, that=E2=80=99s a problem, probably. We either declare this =
behavior out of scope and say you can=E2=80=99t use this method with =
that kind of API (or at least those parameters/headers) or we define a =
mechanism for handling that. I=E2=80=99m in favor of the former, and =
removing the text from the generation sections that says repeated =
parameters are processed with no special handling, making them =
explicitly out of scope throughout.
 
I would love to see =
more feedback from the group about this, especially if someone=E2=80=99s =
got a clever solution.
 
 =E2=80=94 Justin
 
On Feb 28, 2016, at 1:31 PM, Brock Allen <brockallen@gmail.com> wrote:
 
Given that the client can =
iterate over the query/headers in any order to generate the concatenated =
value to hash, I think there=E2=80=99s an issue with query string or =
header values with repeated keys. I=E2=80=99ll stick with query params =
for simplicity in my sample. 
 
If a client signs this concatenated query: =E2=80=9Ca=3D1&a=
=3D2=E2=80=9D then the =E2=80=9Cp=E2=80=9D value in the signed JSON =
object could be this:
 
"p": [["a", "a"], "blah"]
 
On the resource server, how do you know which key/value pair =
to put in which order for verification? Also, given that different =
server implementations express these incoming parameters in different =
ways, it seems problematic to be consistent.
 
Thanks.
 
-Brock
 
_______________________________________________
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

=

--Apple-Mail=_46F46E45-1F11-4E7C-9956-091B07F2FE4B--


From nobody Wed Mar  2 16:42:53 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72221A1A2F for ; Wed,  2 Mar 2016 16:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 UB4tyFCq2M7F for ; Wed,  2 Mar 2016 16:42:49 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F1F1A1A13 for ; Wed,  2 Mar 2016 16:42:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vZw7jFMNadFUyq/bw8bcs7NiAb0VyolaMuo+qI3/f5k=; b=FgisSEOpoEIVJf+QOtF4XSMtIBivhnjyPIuHkMAGfSaijpv7ku+re8sKMdi0yc7Vy/j1A7d72yqh02fLrrKZZOHsDz+xMFgjD3x16f2M244rSqEtHt0Aw9UjRu8Q7ArarypWDTL6qhE1g4otyLTSLrp5sHMyt24GK3Edxln+IQw=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.427.16; Thu, 3 Mar 2016 00:42:45 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0427.016; Thu, 3 Mar 2016 00:42:45 +0000
From: Mike Jones 
To: Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
Thread-Index: AdF05ZlBny4USW2wSxCkXEotBc11fg==
Date: Thu, 3 Mar 2016 00:42:45 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [4.16.82.82]
x-ms-office365-filtering-correlation-id: 63d1ceec-b0e3-4551-a4e4-08d342fcbc96
x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:MmUYr0tsX0R9oOnkl+XMK7dlaHxEeqQTqjTBHruVVoFOFo3HgRaL0zSo2uV/5fAIGhcSetZeLgsMaH7zpgyZoWUw2/25CwnmPnKGeYgcIHGyzSzSjwyXieIXosQDJIPC4my3/mokmPOQ65DmO/H+5A==; 24:EHpDbR89+UyAHIvRj384Bum4jaNW1rkv3N7n3i0U+bo4kDj+43omPX+3VTzvKTtVvNnNfpwiQg+yCYVefZnajKgbhgGaowfVNEHJhXSYtgU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; 
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(5002640100001)(19580405001)(19580395003)(10090500001)(77096005)(189998001)(2501003)(5001960100004)(586003)(3846002)(86362001)(74316001)(6116002)(1096002)(1220700001)(40100003)(102836003)(11100500001)(33656002)(50986999)(54356999)(76576001)(5008740100001)(66066001)(122556002)(86612001)(2906002)(3660700001)(3280700002)(92566002)(5001770100001)(87936001)(10290500002)(10400500002)(5005710100001)(15975445007)(107886002)(99286002)(5003600100002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 00:42:45.0677 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
Archived-At: 
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 00:42:52 -0000

SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBieSB0aGUgd29ya2luZyBn
cm91cC4gIEFzcGVjdHMgb2YgaXQgYXJlIGFscmVhZHkgYmVpbmcgdXNlZCBpbiBwcm9kdWN0aW9u
IGJ5IEdvb2dsZSBhbmQgTWljcm9zb2Z0LiAgSXQgaXMgYWxzbyBub3JtYXRpdmVseSByZWZlcmVu
Y2VkIGJ5IHRoZSBtb2JpbGUgcHJvZmlsZSBmb3IgT3BlbklEIENvbm5lY3QgYmVpbmcgcHJvZHVj
ZWQgYnkgdGhlIE9wZW5JRCBNT0RSTkEgd29ya2luZyBncm91cC4NCg0KCQkJCQktLSBNaWtlDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogVGh1
cnNkYXksIEZlYnJ1YXJ5IDE4LCAyMDE2IDU6MDkgQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3Vi
amVjdDogW09BVVRILVdHXSAybmQgQ2FsbCBmb3IgQWRvcHRpb246IEF1dGhlbnRpY2F0aW9uIE1l
dGhvZCBSZWZlcmVuY2UgVmFsdWVzDQoNCkluIHJlc3BvbnNlIHRvIG15IG1lc3NhZ2UgdG8gdGhl
IGxpc3QgcmVnYXJkaW5nIHRoZSBpbml0aWFsIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSBBdXRo
ZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcyBkcmFmdCwgc2VlIGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTY5NC5odG1sLCBN
aWtlIHN1Ym1pdHRlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IHRvIHRha2Ug
cmFpc2VkIGNvbmNlcm5zIGludG8gYWNjb3VudC4gU2V2ZXJhbCB3b3JraW5nIGdyb3VwIHBhcnRp
Y2lwYW50cyByZXNwb25kZWQgcG9zaXRpdmVseSB0byB0aGUgbmV3IHZlcnNpb24uDQoNCldlIHdv
dWxkIHRoZXJlZm9yZSBsaWtlIHRvIGlzc3VlIGEgMm5kIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRo
ZSByZWNlbnRseSBzdWJtaXR0ZWQgdmVyc2lvbiAtMDU6DQpodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtYW1yLXZhbHVlcy0wNQ0KDQpQbGVhc2UgbGV0IHVzIGtu
b3cgYnkgTWFyY2ggM3JkIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGUgYWRvcHRp
b24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBP
QXV0aCB3b3JraW5nIGdyb3VwLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQo=


From nobody Wed Mar  2 17:04:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D631B1B3737 for ; Wed,  2 Mar 2016 17:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level: 
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 7kF9E6u6dEKm for ; Wed,  2 Mar 2016 17:03:58 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 747F21B3735 for ; Wed,  2 Mar 2016 17:03:58 -0800 (PST)
Received: by mail-ob0-x22b.google.com with SMTP id ts10so6491918obc.1 for ; Wed, 02 Mar 2016 17:03:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0CJdTupibF85TLn7CmystHR2WoxN1diwV2A/aCwKH3g=; b=kf7+5GG/dX+WJbGUC8hPs39VdBMKknEzSa0iaC+hG1zcY89O6aLNxEi+VpYiLuLq0p ooFeNNFC9f6MdP9pQVlVQK1+1I4mrLjXBfz3JHsvH0fvcg5/MsTnXZikkdRAIZhF31X2 1spaNv1Z15ZD5yBA3NapGztiIMNV4SFMvGdgbHKjX9tg97I1uYrKFtj+qRtSibmI2+C8 sXFhsHWM5h8QM7uwv1Wn75NIlj+vgrns6eYZa3yyKum1LmerocdCLLETMmnfV/j72fng p4pV6wLvXVu8NZPntSwjsZVwITgB0vPVtZ1385Vhp29guhwlCxD1H1YgethcjamB322P c26A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0CJdTupibF85TLn7CmystHR2WoxN1diwV2A/aCwKH3g=; b=iMcjZP2tNxU0jaOO/L4x7sA8djdHQDFpMOlNN/V8A13ky+VVNnUxAPZuRRQ2SzMIEE JaydzB0yeqUzTi8MGeo9m4Vpl3OPSQjD8cXlKaRIXDj6Vaz535yigF3773Ub8sN2MfHu U7OnQFVDPGPtBkBPsEp0SNBnGTyXl80oYlL/HX69AXoSt90r/yDmWl1HEIZxH3Tbu90R sIOp7AriWgITpk2uIXY18Gm9oX+Alutnv7DHGqeJpvhBOI4NKEl+LD9LRgKPwOjDFtv1 5An4ZqCgAEKKD4AWtWCaZ6gkykPEKvySc3LkY84pV7auhJ774jdw4HL8gSJXTKiFf+bp a6kQ==
X-Gm-Message-State: AD7BkJLJUEh45vqZfe2ehNODDiYOOiyXOWVnXsbQXuSb61ASKe/U6txcW8OLXzo5Kg06QznkwPGbDqlTE3XPhBph
X-Received: by 10.182.114.167 with SMTP id jh7mr23559900obb.70.1456967037685;  Wed, 02 Mar 2016 17:03:57 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: William Denniss 
Date: Thu, 03 Mar 2016 01:03:46 +0000
Message-ID: 
To: Hannes Tschofenig , Mike Jones ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c2e2e6bb5cf6052d1a9278
Archived-At: 
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 01:04:00 -0000

--001a11c2e2e6bb5cf6052d1a9278
Content-Type: text/plain; charset=UTF-8

I support adoption of this specification by the working group.

We are already using some values in production and I see interoperability
advantages in having these standardized.

On Wed, Mar 2, 2016 at 4:42 PM Mike Jones 
wrote:

> I support adoption of this specification by the working group.  Aspects of
> it are already being used in production by Google and Microsoft.  It is
> also normatively referenced by the mobile profile for OpenID Connect being
> produced by the OpenID MODRNA working group.
>
>                                         -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Thursday, February 18, 2016 5:09 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference
> Values
>
> In response to my message to the list regarding the initial call for
> adoption of the Authentication Method Reference Values draft, see
> https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike
> submitted an updated version of the document to take raised concerns into
> account. Several working group participants responded positively to the new
> version.
>
> We would therefore like to issue a 2nd call for adoption of the recently
> submitted version -05:
> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
>
> Please let us know by March 3rd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth working
> group.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a11c2e2e6bb5cf6052d1a9278
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I support adoption of this specificatio=
n by the working group.

We are already using some values in producti=
on and I see interoperability advantages in having these standardized. 
On Wed, Mar 2, 2016 at 4:=
42 PM Mike Jones <Michael=
.Jones@microsoft.com> wrote:
I support adoption of this specification by the working group.=C2=A0 Aspec=
ts of it are already being used in production by Google and Microsoft.=C2=
=A0 It is also normatively referenced by the mobile profile for OpenID Conn=
ect being produced by the OpenID MODRNA working group.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike<=
br>


-----Original Message-----

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig

Sent: Thursday, February 18, 2016 5:09 AM

To: oauth@ietf.org<=
br>
Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference =
Values



In response to my message to the list regarding the initial call for adopti=
on of the Authentication Method Reference Values draft, see https://www.ietf.org/mail-archive/web/oauth/curren=
t/msg15694.html, Mike submitted an updated version of the document to t=
ake raised concerns into account. Several working group participants respon=
ded positively to the new version.



We would therefore like to issue a 2nd call for adoption of the recently su=
bmitted version -05:

https://tools.ietf.org/html/draft-jones-o=
auth-amr-values-05



Please let us know by March 3rd whether you accept / object to the adoption=
 of this document as a starting point for work in the OAuth working group.<=
br>


Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a11c2e2e6bb5cf6052d1a9278--


From nobody Wed Mar  2 17:18:09 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4136A1B3787 for ; Wed,  2 Mar 2016 17:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level: 
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 UvLRDA0di2yo for ; Wed,  2 Mar 2016 17:18:06 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 87E341B3782 for ; Wed,  2 Mar 2016 17:18:06 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u231I2eD025001 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Mar 2016 01:18:03 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u231I26R013737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 3 Mar 2016 01:18:02 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u231I1Eg032533; Thu, 3 Mar 2016 01:18:01 GMT
Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Mar 2016 17:18:01 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-50F15C3A-5E65-4CF0-8CD9-A97C9EDB2CE3
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Wed, 2 Mar 2016 17:17:59 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <6CE40A87-A264-429E-B4A2-7414E9657783@oracle.com>
References:  
To: William Denniss 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 01:18:08 -0000

--Apple-Mail-50F15C3A-5E65-4CF0-8CD9-A97C9EDB2CE3
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

+1 for adoption. Again.=20

Phil

> On Mar 2, 2016, at 17:03, William Denniss  wrote:
>=20
> I support adoption of this specification by the working group.
>=20
> We are already using some values in production and I see interoperability a=
dvantages in having these standardized.=20
>=20
>> On Wed, Mar 2, 2016 at 4:42 PM Mike Jones  w=
rote:
>> I support adoption of this specification by the working group.  Aspects o=
f it are already being used in production by Google and Microsoft.  It is al=
so normatively referenced by the mobile profile for OpenID Connect being pro=
duced by the OpenID MODRNA working group.
>>=20
>>                                         -- Mike
>>=20
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni=
g
>> Sent: Thursday, February 18, 2016 5:09 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Referenc=
e Values
>>=20
>> In response to my message to the list regarding the initial call for adop=
tion of the Authentication Method Reference Values draft, see https://www.ie=
tf.org/mail-archive/web/oauth/current/msg15694.html, Mike submitted an updat=
ed version of the document to take raised concerns into account. Several wor=
king group participants responded positively to the new version.
>>=20
>> We would therefore like to issue a 2nd call for adoption of the recently s=
ubmitted version -05:
>> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
>>=20
>> Please let us know by March 3rd whether you accept / object to the adopti=
on of this document as a starting point for work in the OAuth working group.=

>>=20
>> Ciao
>> Hannes & Derek
>>=20
>> _______________________________________________
>> 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

--Apple-Mail-50F15C3A-5E65-4CF0-8CD9-A97C9EDB2CE3
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


+1 for adoption. Again. 

P=
hil

On Mar 2, 2016, at 17:03, William Denniss <wdenniss@google.com> wrote:

<=
blockquote type=3D"cite">
I support a=
doption of this specification by the working group.

We are already us=
ing some values in production and I see interoperability advantages in havin=
g these standardized. 

=
On Wed, Mar 2, 2016 at 4:42 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
I support adoption of this specification by the worki=
ng group.  Aspects of it are already being used in production by Google=
 and Microsoft.  It is also normatively referenced by the mobile profil=
e for OpenID Connect being produced by the OpenID MODRNA working group.



                     =
                   -- Mike



-----Original Message-----

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig

Sent: Thursday, February 18, 2016 5:09 AM

To: oauth@ietf.org
Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference V=
alues



In response to my message to the list regarding the initial call for adoptio=
n of the Authentication Method Reference Values draft, see https://www.ietf.org/mail-archive/web/oauth/current/ms=
g15694.html, Mike submitted an updated version of the document to take r=
aised concerns into account. Several working group participants responded po=
sitively to the new version.



We would therefore like to issue a 2nd call for adoption of the recently sub=
mitted version -05:

https://tools.ietf.org/html/draft-jones-oauth=
-amr-values-05



Please let us know by March 3rd whether you accept / object to the adoption o=
f this document as a starting point for work in the OAuth working group.
=



Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




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

--Apple-Mail-50F15C3A-5E65-4CF0-8CD9-A97C9EDB2CE3--


From nobody Wed Mar  2 17:20:10 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63121B3791 for ; Wed,  2 Mar 2016 17:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 MOpzUkHQO9X3 for ; Wed,  2 Mar 2016 17:20:07 -0800 (PST)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 E561A1B3790 for ; Wed,  2 Mar 2016 17:20:06 -0800 (PST)
Received: by mail-yk0-x233.google.com with SMTP id 1so3142340ykg.3 for ; Wed, 02 Mar 2016 17:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nXeOkwpi6uhCQV5XPU/C/kGs6p7IWp4FdIsqwzwJwgw=; b=aAhMQ+6ad7VaTCpj7XEHZgFSCb/SJMY7LiNICOIZLXvbJ6PqIuJ35c1n3RZotoD+0F emxdICRFSMedhAGJlL5+BT4r4tk6kaclasObxQiDdjcyvkYdiv1uHG4SJfTyNxp+rAzD 4VL7YPjgeP0pptQ8+Bfa71r2OGUFUBIPD+2mnZ51Rr4tzX+0TZDrxTLpI85XskSmWd8D palEfDeFcAIRHyxVkOhlcOEUxOjmxb9yzHk6zCr3R5I+f7NDhKsYUeY45epHjcdcqlYl yY8cm+5IGNxHLD1z01cT1C4CFmHzmEceov4ZfTGINt8Qy/GLbUVPg835vg/jicDYQ/K+ UrSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nXeOkwpi6uhCQV5XPU/C/kGs6p7IWp4FdIsqwzwJwgw=; b=ZHPtcojDJb5om54XHsC+ZTXNxOsrKG3NWH9pukJ8yYhew+b3cTZ3DOlT1NFQQatWbu vUFbuR3mxucck8gfsP+VdpY8L2Lq2J//wv7nNdh6v8nmQUA6yEQ55jiUg2Dj+3iJkKzz 2phc6rXnHma9lIZlZ4oTaLzDEyIWusR1JQ9AlZyujzt4QCN3B5Pvgo+DSGY4M15cEAsJ eb9430naiTeIIyiNvgqLvDdzut8Qvw8yF6EeViP5W0bmQ7yurJq4HwP5WZSkjNWDoRHq zjkdTDN6qk8Brc/z/H8c61Z6rjwgrkMfPOr13a/bTShSMcxBv6H2bm8s09pxFg5XmtM3 g36w==
X-Gm-Message-State: AD7BkJIMm6nJfBbB9yInaYmcHtRluto5kok7+b+fH9ig+7Ey86J+laD7D31n7L1gG9md76abamj2YtNzsgY04Q==
MIME-Version: 1.0
X-Received: by 10.37.230.84 with SMTP id d81mr16270411ybh.128.1456968006232; Wed, 02 Mar 2016 17:20:06 -0800 (PST)
Received: by 10.37.214.130 with HTTP; Wed, 2 Mar 2016 17:20:05 -0800 (PST)
Received: by 10.37.214.130 with HTTP; Wed, 2 Mar 2016 17:20:05 -0800 (PST)
In-Reply-To: <6CE40A87-A264-429E-B4A2-7414E9657783@oracle.com>
References:   <6CE40A87-A264-429E-B4A2-7414E9657783@oracle.com>
Date: Wed, 2 Mar 2016 22:20:05 -0300
Message-ID: 
From: John Bradley 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=94eb2c0b1c26762205052d1acc0e
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 01:20:09 -0000

--94eb2c0b1c26762205052d1acc0e
Content-Type: text/plain; charset=UTF-8

+1 for adoption still
On Mar 2, 2016 10:18 PM, "Phil Hunt (IDM)"  wrote:

> +1 for adoption. Again.
>
> Phil
>
> On Mar 2, 2016, at 17:03, William Denniss  wrote:
>
> I support adoption of this specification by the working group.
>
> We are already using some values in production and I see interoperability
> advantages in having these standardized.
>
> On Wed, Mar 2, 2016 at 4:42 PM Mike Jones 
> wrote:
>
>> I support adoption of this specification by the working group.  Aspects
>> of it are already being used in production by Google and Microsoft.  It is
>> also normatively referenced by the mobile profile for OpenID Connect being
>> produced by the OpenID MODRNA working group.
>>
>>                                         -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
>> Tschofenig
>> Sent: Thursday, February 18, 2016 5:09 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method
>> Reference Values
>>
>> In response to my message to the list regarding the initial call for
>> adoption of the Authentication Method Reference Values draft, see
>> https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike
>> submitted an updated version of the document to take raised concerns into
>> account. Several working group participants responded positively to the new
>> version.
>>
>> We would therefore like to issue a 2nd call for adoption of the recently
>> submitted version -05:
>> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
>>
>> Please let us know by March 3rd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth working
>> group.
>>
>> Ciao
>> Hannes & Derek
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--94eb2c0b1c26762205052d1acc0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 for adoption still 


On Mar 2, 2016 10:18 PM, "Phil Hunt (IDM)&q=
uot; <phil.hunt@oracle.com&g=
t; wrote:
+1 for adoption. Again.=C2=A0

Phil

On M=
ar 2, 2016, at 17:03, William Denniss <wdenniss@google.com> wrote:

I support a=
doption of this specification by the working group.

We are already u=
sing some values in production and I see interoperability advantages in hav=
ing these standardized. 

On Wed, Mar 2, 2016 at 4:42 PM Mike Jones <Michael.Jones@microsoft.com> =
wrote:
I support adoption of this s=
pecification by the working group.=C2=A0 Aspects of it are already being us=
ed in production by Google and Microsoft.=C2=A0 It is also normatively refe=
renced by the mobile profile for OpenID Connect being produced by the OpenI=
D MODRNA working group.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike<=
br>


-----Original Message-----

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig

Sent: Thursday, February 18, 2016 5:09 AM

To: oauth@ietf.org<=
br>
Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference =
Values



In response to my message to the list regarding the initial call for adopti=
on of the Authentication Method Reference Values draft, see https://www.ietf.org/mail-archive/web/oauth/curren=
t/msg15694.html, Mike submitted an updated version of the document to t=
ake raised concerns into account. Several working group participants respon=
ded positively to the new version.



We would therefore like to issue a 2nd call for adoption of the recently su=
bmitted version -05:

https://tools.ietf.org/html/draft-jones-o=
auth-amr-values-05



Please let us know by March 3rd whether you accept / object to the adoption=
 of this document as a starting point for work in the OAuth working group.<=
br>


Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




___________________=
____________________________
OAuth mailing list
<=
span>OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth
<=
/div>

_______________________________________________=


OAuth mailing list

OAuth@ietf.org

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




--94eb2c0b1c26762205052d1acc0e--


From nobody Wed Mar  2 23:43:07 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D751A009B for ; Wed,  2 Mar 2016 23:43:05 -0800 (PST)
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
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 vGHxj4zfKsJh for ; Wed,  2 Mar 2016 23:43:03 -0800 (PST)
Received: from p3plsmtpa08-10.prod.phx3.secureserver.net (p3plsmtpa08-10.prod.phx3.secureserver.net [173.201.193.111]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3B81A0098 for ; Wed,  2 Mar 2016 23:43:03 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa08-10.prod.phx3.secureserver.net with  id RKj11s00515ZTut01Kj1Fu; Thu, 03 Mar 2016 00:43:02 -0700
To: oauth@ietf.org
References:   <6CE40A87-A264-429E-B4A2-7414E9657783@oracle.com> 
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <56D7EB04.8080800@connect2id.com>
Date: Thu, 3 Mar 2016 09:43:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030203010105010509070409"
Archived-At: 
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 07:43:05 -0000

This is a cryptographically signed message in MIME format.

--------------ms030203010105010509070409
Content-Type: multipart/alternative;
 boundary="------------010605040007000501030902"

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

+1 to have the AMR spec adopted

On 03/03/16 03:20, John Bradley wrote:
> +1 for adoption still
> On Mar 2, 2016 10:18 PM, "Phil Hunt (IDM)"  wrote=
:
>
>> +1 for adoption. Again.
>>
>> Phil
>>
>> On Mar 2, 2016, at 17:03, William Denniss  wrote:=

>>
>> I support adoption of this specification by the working group.
>>
>> We are already using some values in production and I see interoperabil=
ity
>> advantages in having these standardized.
>>
>> On Wed, Mar 2, 2016 at 4:42 PM Mike Jones 
>> wrote:
>>
>>> I support adoption of this specification by the working group.  Aspec=
ts
>>> of it are already being used in production by Google and Microsoft.  =
It is
>>> also normatively referenced by the mobile profile for OpenID Connect =
being
>>> produced by the OpenID MODRNA working group.
>>>
>>>                                         -- Mike
>>>
>>> -----Original Message-----
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
>>> Tschofenig
>>> Sent: Thursday, February 18, 2016 5:09 AM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method
>>> Reference Values
>>>
>>> In response to my message to the list regarding the initial call for
>>> adoption of the Authentication Method Reference Values draft, see
>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mi=
ke
>>> submitted an updated version of the document to take raised concerns =
into
>>> account. Several working group participants responded positively to t=
he new
>>> version.
>>>
>>> We would therefore like to issue a 2nd call for adoption of the recen=
tly
>>> submitted version -05:
>>> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
>>>
>>> Please let us know by March 3rd whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth w=
orking
>>> group.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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


--------------010605040007000501030902
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    +1 to have the AMR spec adopted

    

    
On 03/03/16 03:20, John Bradley wrote:=


    

    

      
+1 for adoption still
On Mar 2, 2016 10:18 PM, "Phil Hunt (IDM)" <phil.hunt@oracle.com> wrote:



      

        
+1 for adoption. Again.

Phil

On Mar 2, 2016, at 17:03, William Denniss <wdenniss@google.com> w=
rote:

I support adoption of this specification by the working group.

We are already using some values in production and I see interoperability=

advantages in having these standardized.

On Wed, Mar 2, 2016 at 4:42 PM Mike Jones <Michael.Jones@microso=
ft.com>
wrote:



        

          
I support adoption of this specification by the =
working group.  Aspects
of it are already being used in production by Google and Microsoft.  It i=
s
also normatively referenced by the mobile profile for OpenID Connect bein=
g
produced by the OpenID MODRNA working group.

                                        -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
Tschofenig
Sent: Thursday, February 18, 2016 5:09 AM
To: =
oauth@ietf.org
Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method
Reference Values

In response to my message to the list regarding the initial call for
adoption of the Authentication Method Reference Values draft, see
https://www.ietf.org/mail-archive/we=
b/oauth/current/msg15694.html, Mike
submitted an updated version of the document to take raised concerns into=

account. Several working group participants responded positively to the n=
ew
version.

We would therefore like to issue a 2nd call for adoption of the recently
submitted version -05:
https://tools.ietf.org/html/draft-jones-oa=
uth-amr-values-05

Please let us know by March 3rd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth worki=
ng
group.

Ciao
Hannes & Derek

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



        

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


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




      

      

      

      

      

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


    

    

  


--------------010605040007000501030902--

--------------ms030203010105010509070409
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
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAzMDMwNzQzMDBaMC8GCSqGSIb3DQEJBDEiBCCUz7vwVokIU6qVIt0LTkrj3oIqx1Fz
YsKWof3zS8QiTjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQAbgriocgIH
9vzGNHqN0JTBYo6kifOXGvIGDz2JAvdksrtgTT0Nx1XcNkuDgcIn5CEpmMgnhVEooeRfmSw8
PxIKNTPBDf0E2WvTmJOK/d/G5Mr4QXhJ1SEe5HqIUWcpU5c1V/0PizkcNIfkC+T5J9GEKKyo
m5DdScB/bOD2uMV6Ok82HdCFhenEDPv9/Ft79J/2U8STwOSbH+iEtPPUhXhBMKB1zY6Hvpyy
2lmxKP84A84CbYD+ddpciH+mnccX5JQo1dP1RA3/WEUeGLhgPybdWDQG+nKdDOcm5ahErxhQ
QRztscEkCnuEk/bwVyH2aJ6k3s02lMs5rQuuARg4fxoKAAAAAAAA
--------------ms030203010105010509070409--


From nobody Thu Mar  3 00:49:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A08F1A1B73 for ; Thu,  3 Mar 2016 00:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 u60L9kLYIyC8 for ; Thu,  3 Mar 2016 00:49:47 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (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 D6FA21A1B71 for ; Thu,  3 Mar 2016 00:49:46 -0800 (PST)
Received: from [80.67.16.121] (helo=webmail.df.eu) by smtprelay01.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1abOx5-0007VA-T9; Thu, 03 Mar 2016 09:49:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_cbf78e75f2f7e0eae7538215eb4d89cf"
Date: Thu, 03 Mar 2016 09:49:43 +0100
From: torsten@lodderstedt.net
To: Vladimir Dzhuvinov 
In-Reply-To: <56D7EB04.8080800@connect2id.com>
References:   <6CE40A87-A264-429E-B4A2-7414E9657783@oracle.com>  <56D7EB04.8080800@connect2id.com>
Message-ID: <52912e6eb13bcc988fdde0897eb19f29@lodderstedt.net>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 08:49:50 -0000

--=_cbf78e75f2f7e0eae7538215eb4d89cf
Content-Transfer-Encoding: 7bit
Content-Type: text/plain

 

+1 for adoption as WG document 

Note: AMRs are mainly intended to be used in OIDC context. e.g. the
MODRNA WG refers to this spec. The document should clearly state that. 

Am 03.03.2016 08:43, schrieb Vladimir Dzhuvinov: 

> +1 to have the AMR spec adopted
> 
> On 03/03/16 03:20, John Bradley wrote: 
> 
> +1 for adoption still
> On Mar 2, 2016 10:18 PM, "Phil Hunt (IDM)"  wrote:
> 
> +1 for adoption. Again.
> 
> Phil
> 
> On Mar 2, 2016, at 17:03, William Denniss  wrote:
> 
> I support adoption of this specification by the working group.
> 
> We are already using some values in production and I see interoperability
> advantages in having these standardized.
> 
> On Wed, Mar 2, 2016 at 4:42 PM Mike Jones 
> wrote:
> 
> I support adoption of this specification by the working group. Aspects
> of it are already being used in production by Google and Microsoft. It is
> also normatively referenced by the mobile profile for OpenID Connect being
> produced by the OpenID MODRNA working group.
> 
> -- Mike
> 
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
> Tschofenig
> Sent: Thursday, February 18, 2016 5:09 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method
> Reference Values
> 
> In response to my message to the list regarding the initial call for
> adoption of the Authentication Method Reference Values draft, see
> https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html [1], Mike
> submitted an updated version of the document to take raised concerns into
> account. Several working group participants responded positively to the new
> version.
> 
> We would therefore like to issue a 2nd call for adoption of the recently
> submitted version -05:
> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05 [2]
> 
> Please let us know by March 3rd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth working
> group.
> 
> Ciao
> Hannes & Derek
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth [3]
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth [3]
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth [3]

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

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

 

Links:
------
[1] https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html
[2] https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
[3] https://www.ietf.org/mailman/listinfo/oauth

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




+1 for adoption as WG document


Note: AMRs are mainly intended to be us=
ed in OIDC context. e.g. the MODRNA WG refers to this spec. The document sh=
ould clearly state that.


Am 03.03.2016 08:43, schrieb Vladimir Dzhuvinov:


+1 to have the AMR spec adopted



On 03/03/16 03:20, John Bradley wrote:




+1 for adoption still
On Mar 2, 2016 10:18 PM, "Phil Hunt (IDM)" <phil.hunt@oracle.com> wr=
ote:






+1 for adoption. Again.

Phil

On Mar 2, 2016, at 17:03, William Denniss <wdenniss@google.com> wrote=
:

I support adoption of this specification by the working group.

We are already using some values in production and I see interoperability
advantages in having these standardized.

On Wed, Mar 2, 2016 at 4:42 PM Mike Jones <Michael.Jones@microsoft=
=2Ecom>
wrote:






I support adoption of this specification by the working group.  Aspect=
s
of it are already being used in production by Google and Microsoft.  It is
also normatively referenced by the mobile profile for OpenID Connect being
produced by the OpenID MODRNA working group.

                                        -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
Tschofenig
Sent: Thursday, February 18, 2016 5:09 AM
To: oa=
uth@ietf.org
Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method
Reference Values

In response to my message to the list regarding the initial call for
adoption of the Authentication Method Reference Values draft, see
https://www.ietf.org/mail-archive/web/oa=
uth/current/msg15694.html, Mike
submitted an updated version of the document to take raised concerns into
account. Several working group participants responded positively to the new
version.

We would therefore like to issue a 2nd call for adoption of the recently
submitted version -05:
https://tools.ietf.org/html/draft-jones-oauth-=
amr-values-05

Please let us know by March 3rd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth working
group.

Ciao
Hannes & Derek

_______________________________________________
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


_______________________________________________
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








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





 


 



--=_cbf78e75f2f7e0eae7538215eb4d89cf--


From philippe.clement@orange.com  Thu Mar  3 02:45:59 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD691A897C for ; Thu,  3 Mar 2016 02:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 EvThz4U0i1w4 for ; Thu,  3 Mar 2016 02:45:58 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0120D1A897A for ; Thu,  3 Mar 2016 02:45:58 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 179263B430B; Thu,  3 Mar 2016 11:45:56 +0100 (CET)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [10.114.50.54]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id EC10627C058; Thu,  3 Mar 2016 11:45:55 +0100 (CET)
Received: from OPEXCNORM73.corporate.adroot.infra.ftgroup ([fe80::3991:195b:e05c:93d5]) by OPEXCNORM62.corporate.adroot.infra.ftgroup ([fe80::711e:8fd9:cdba:7676%21]) with mapi id 14.03.0279.002; Thu, 3 Mar 2016 11:45:55 +0100
From: 
To: "hannes.tschofenig@gmx.net" , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
Thread-Index: AdF05ZlBny4USW2wSxCkXEotBc11fgAAnRzQABRgdZA=
Date: Thu, 3 Mar 2016 10:45:55 +0000
Message-ID: <20274_1457001956_56D815E3_20274_2428_1_BA1DE49CF3A1754F875D2318BF2412CD1308C1F4@OPEXCNORM73.corporate.adroot.infra.ftgroup>
References:  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.114.50.247]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.3.102417
Archived-At: 
Subject: [OAUTH-WG] TR: 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 10:47:28 -0000

I support the adoption of the specification. AMR values are important in th=
e business field of MNO, as discussed in the OIF/MODRNA workgroup

Regards,
Philippe

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, March 2, 2016 4:43 PM
To: Hannes Tschofenig ; oauth@ietf.org
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Refere=
nce Values

I support adoption of this specification by the working group.  Aspects of =
it are already being used in production by Google and Microsoft.  It is als=
o normatively referenced by the mobile profile for OpenID Connect being pro=
duced by the OpenID MODRNA working group.

					-- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 5:09 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference =
Values

In response to my message to the list regarding the initial call for adopti=
on of the Authentication Method Reference Values draft, see https://www.iet=
f.org/mail-archive/web/oauth/current/msg15694.html, Mike submitted an updat=
ed version of the document to take raised concerns into account. Several wo=
rking group participants responded positively to the new version.

We would therefore like to issue a 2nd call for adoption of the recently su=
bmitted version -05:
https://tools.ietf.org/html/draft-jones-oauth-amr-values-05

Please let us know by March 3rd whether you accept / object to the adoption=
 of this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Derek

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Thu Mar  3 08:58:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F901A886B for ; Thu,  3 Mar 2016 08:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.904
X-Spam-Level: 
X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.006, T_DKIM_INVALID=0.01] autolearn=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 kKhJaGiGSTM7 for ; Thu,  3 Mar 2016 08:58:00 -0800 (PST)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3ED31A87A4 for ; Thu,  3 Mar 2016 08:58:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id 8CF9EB4137 for ; Thu,  3 Mar 2016 16:57:47 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1457024267; x=1457888268; bh=inJMueW1LO YMcWXmJqq8/I43X4ryb57WuxJWDBHxjF4=; b=Fpb9rVguZqpTOluohSzddfQlK6 KO7SOY9SgDdHs3pMD1AEANkvOPX+NRQkMduFs9BVcWgtUJISa6sA9gKE1vij/yMQ 5syUQhs2SiCWM7/oEF1tGASb0f1yPTx8MTC5sW7vOZwh9IK5vMNvozCciclfxSUp 6sbF2cKPr001zLgc8=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAVH28m8dNIa for ; Thu,  3 Mar 2016 16:57:47 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 578ECB40E6 for ; Thu,  3 Mar 2016 16:57:47 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 03 Mar 2016 08:57:47 -0800
From: Mike Schwartz 
To: oauth@ietf.org
Organization: Gluu
In-Reply-To: 
References: 
Message-ID: <1cb334e5c012f6d4cbdeaaf4b843f2b7@gluu.org>
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 16:58:01 -0000

OAuth Guru's,

I know you are all going to approve this AMR spec anyway, but I'd just 
like to dissent. I think this specification is useless, and potentially 
harmful.

Just as an example--two domains that use "face" as the amr probably have 
totally different algorithms, sensitivities, training, and identity 
management processes that contribute to the significance of this value. 
So rather than interoperability, this standard just sets up domains for 
miscommunication.

If it doesn't serve interoperabilty, what use case does this standard 
solve?

I think a bad quick and dirty solution is worse than no solution at all. 
If I had a vote, I'd definitely vote against this one.

- Mike


-------------------------------------
Michael Schwartz
Gluu
Founder / CEO


From nobody Thu Mar  3 09:52:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30DA1B2B09 for ; Thu,  3 Mar 2016 09:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
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 vXBXHfQBf6-3 for ; Thu,  3 Mar 2016 09:52:35 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 69D4F1B2B05 for ; Thu,  3 Mar 2016 09:52:25 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id u110so23170308qge.3 for ; Thu, 03 Mar 2016 09:52:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AKgPcGJT/7vWyErtNQM1Lb6zV6x3/x2KCY8F/ZlXHto=; b=VrYE/UVEoy3xhSmpR72/Lz+flareWc2d93Ja1chGsjVU1+R5l0RqKtW9bTTjUAVncJ 97ctHH85SZRhMfNUqlyO0q55ODlm3vAn1CiDye7ENeZ90X1Fxkke7geNyXdkhDXMKrTI akddnL/zx+vhkc9cesb1o2iwjmzeZSTyAL2WS/SYdIJjZBIni+hEAiz2vCCERs8hC1zl r/fpeZIxxU46vKXNziWqdsNfYBlmlkjtqhOE+OtofI5g+Ddiuy7yNRvL8TADI+mYWxvI uEiLVzWpq+nHT3AG6HPHattK08yzKEIaBlfbJGZK//KYQD8Lw6dK9Pnudb6KXsgI5w84 Bgmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AKgPcGJT/7vWyErtNQM1Lb6zV6x3/x2KCY8F/ZlXHto=; b=MV7SAGGgZ+kxhTd++9tRSg4p/G0hOtFYGfFHjyI7xvcUVwDFcGD1JDCtKldAJOXNFo 5qP2G3lA3VV6PPCWNHigM16TV/iOdIeHUWWzGtCWaVbQ+ihNX013wFIF5u0RNw5dh7SK xg3oSGrzWWhosaogZPsGfG5nwk+AYoU06QPq4lY7LCUa67N/44pfhzxOqFqWT16NS9T+ MM4to+JM0PLe9Ofp3EimxgwT6pRWMA1vhuwHgcCaPKrAsJqGO+ZOJWHIPc9LNmmwR/83 rJzbppKbUUVqw+lRfSE3uduWN0MkGeON5a9IEckZ3MHK4oc8y8SrK5IUCMfYvUB9WdnJ BQMw==
X-Gm-Message-State: AD7BkJLpG2zEqgmGV7FbPYeyym8rNO1FAdRHtm2zXDeA8ycBgQjIvkvXAht6NoV7Q8gCOQ==
X-Received: by 10.140.169.9 with SMTP id p9mr4990902qhp.50.1457027544498; Thu, 03 Mar 2016 09:52:24 -0800 (PST)
Received: from [192.168.1.68] ([191.115.43.188]) by smtp.gmail.com with ESMTPSA id u16sm17419819qka.22.2016.03.03.09.52.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Mar 2016 09:52:23 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1BC2F598-B068-4BC8-8843-941C27D7FC08"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <1cb334e5c012f6d4cbdeaaf4b843f2b7@gluu.org>
Date: Thu, 3 Mar 2016 14:52:17 -0300
Message-Id: <6EF2AFD9-74C7-4DA4-B344-FA3BC45155D7@ve7jtb.com>
References:  <1cb334e5c012f6d4cbdeaaf4b843f2b7@gluu.org>
To: Michael Schwartz 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Mar 2016 17:52:37 -0000

--Apple-Mail=_1BC2F598-B068-4BC8-8843-941C27D7FC08
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mike if you subscribe to the mailing list your opinion counts towards =
consensus.   I am sure you are well aware that the IETF doesn=E2=80=99t =
vote in WG.

Do you object to the specific initial values in the registry or the =
notion of having a IANA registry for the values.

You are also free to contribute text to the authors or the WG if it is =
accepted as a work item.

The question at this point is if it should this draft be the starting =
point for a work item in the Working group.

We are a long way from approving a spec to go to the IESG for review.

John B.

> On Mar 3, 2016, at 1:57 PM, Mike Schwartz  wrote:
>=20
> OAuth Guru's,
>=20
> I know you are all going to approve this AMR spec anyway, but I'd just =
like to dissent. I think this specification is useless, and potentially =
harmful.
>=20
> Just as an example--two domains that use "face" as the amr probably =
have totally different algorithms, sensitivities, training, and identity =
management processes that contribute to the significance of this value. =
So rather than interoperability, this standard just sets up domains for =
miscommunication.
>=20
> If it doesn't serve interoperabilty, what use case does this standard =
solve?
>=20
> I think a bad quick and dirty solution is worse than no solution at =
all. If I had a vote, I'd definitely vote against this one.
>=20
> - Mike
>=20
>=20
> -------------------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_1BC2F598-B068-4BC8-8843-941C27D7FC08
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMDMxNzUyMThaMCMGCSqGSIb3DQEJBDEWBBTAphGFCqUt0EwxQ630cX8D
Uqj9bDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAzOuSzCSR1KZyRwOM09J/UnkLicmiIbshs3oaz+UO5gCgT3s/XLhOa
BnkmEDwv0YufDUZHaw0pRMVydt53O9TSsxsZtpHN1rNM/KQ4h2u+KNuuNdBuAMsp8C7I0oxANgqq
EzbxXhIQtPyhnjOUW5hVLvIvwG44chhOOYqKRiOaScMFgnb7b0LjsaVX1SJK9TXZnOKukeFpFxfk
tCg6QzIv9jUfUu4aYK0lw9RIzzxPnltG7Awu4wOt7kpaD1kFCIrANt5XA0BmNO1k4bwphANRiexC
RNLZMQBlg/R1h5JrSesEaM+S4KkhPQiKOIFFsOwmVfL8iM79DqMNttsgbjPfAAAAAAAA
--Apple-Mail=_1BC2F598-B068-4BC8-8843-941C27D7FC08--


From nobody Thu Mar  3 22:45:48 2016
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 1AC571B340D; Thu,  3 Mar 2016 22:45:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160304064547.26415.51461.idtracker@ietfa.amsl.com>
Date: Thu, 03 Mar 2016 22:45:47 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Mar 2016 06:45:47 -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 of the IETF.

        Title           : OAuth 2.0 Device Flow
        Authors         : William Denniss
                          Stein Myrseth
                          John Bradley
                          Michael B. Jones
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-device-flow-01.txt
	Pages           : 8
	Date            : 2016-03-03

Abstract:
   The device flow is suitable for OAuth 2.0 clients executing on
   devices that do not have an easy data-entry method (e.g., game
   consoles, TVs, picture frames, and media hubs), but where the end-
   user has separate access to a user-agent on another computer or
   device (e.g., desktop computer, a laptop, a smart phone, or a
   tablet).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-01


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 Mar  3 22:49:37 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93831B341B for ; Thu,  3 Mar 2016 22:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 vHdyMDNfceKs for ; Thu,  3 Mar 2016 22:49:22 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901EE1B3406 for ; Thu,  3 Mar 2016 22:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OxMzyGXi2g5fscjPlZGCXx16qhdnTuJhrkVpMxkud84=; b=nHXeFE0H4FQqV+07w01KwdH1n52zOflzjl4mKz2YSZsQaimAyI1/Iv4CsCro4kGg4chtHwgyJfmO9+yfFJGPzWLWKm0MGWCY44wkR09MPj83wYNx1r8tRttkAFZSqKYEuSEJcsanfrvpAQF8YCu/+jYv+t16ZC1Bzb2IShfkWMA=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.415.20; Fri, 4 Mar 2016 06:49:01 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0427.016; Fri, 4 Mar 2016 06:49:01 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: Tidied-up OAuth 2.0 Device Flow specification
Thread-Index: AdF14D63FrpboB4LSDuOdAoQloMcZA==
Date: Fri, 4 Mar 2016 06:49:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [64.134.228.231]
x-ms-office365-filtering-correlation-id: 46c606d0-8e19-44b1-895b-08d343f911bf
x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:kxJxF/100R0kAZgwv+4H3AWauCo1Eg5p/8VTbDBH/cWn4NVrGpwOCCLVSsIwI9VAW6/zs9H/C1bprf0cFn2z2NR9QTKfbXlbL8bSJlDRNkROgPHDSai+6o35MoNTpJmZvWmzIUD5FB6qw9dOGTr15g==; 24:o+MU5JrnFVZwqtjpSJRw639MU0Cp+tRS4oW7rw1UiJx9yzhwZWqjEIbFOt9rwrdf3/eRlk1qGWhWgBmyg1KBsSWf5T24tlUoOTCujH/BWT0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; 
x-forefront-prvs: 0871917CDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(209900001)(5003600100002)(10290500002)(10400500002)(5005710100001)(5002640100001)(66066001)(92566002)(450100001)(3846002)(11100500001)(3660700001)(1096002)(10090500001)(586003)(3280700002)(790700001)(86612001)(6116002)(87936001)(1730700002)(86362001)(2906002)(5008740100001)(50986999)(1220700001)(8990500004)(229853001)(2900100001)(19625215002)(2351001)(102836003)(54356999)(76576001)(5004730100002)(19617315012)(99286002)(74316001)(40100003)(16236675004)(110136002)(33656002)(189998001)(107886002)(2501003)(19580395003)(19300405004)(15975445007)(81166005)(122556002)(77096005)(6606295002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442D9A68D09ABACAE189B79F5BE0BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 06:49:01.0711 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441
Archived-At: 
Subject: [OAUTH-WG] Tidied-up OAuth 2.0 Device Flow specification
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Mar 2016 06:49:28 -0000

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

The OAuth 2.0 Device Flow specification has been tidied up to apply spellin=
g and grammar corrections and add the Document History appendix.  No normat=
ive changes were made.  Again, if you're using an OAuth device flow, please=
 let us know whether your implementation matches this specification, and if=
 not, let us know how it differs.

The specification is available at:

*       http://tools.ietf.org/html/draft-ietf-oauth-device-flow-01

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-device-flow-01.html

                                                          -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=3D1552 and =
as @selfissued.

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











The OAuth 2.0 Device Flow specification has been tid=
ied up to apply spelling and grammar corrections and add the Document Histo=
ry appendix.  No normative changes were made.  Again, if you̵=
7;re using an OAuth device flow, please let us know
 whether your implementation matches this specification, and if not, let us=
 know how it differs.


 


The specification is available at:


·      
http://tools.ietf.org/html/draft-ietf-oauth-devi=
ce-flow-01


 


An HTML-formatted version is also available at:=



·      
http://self-issued.info/docs/draft-ietf-o=
auth-device-flow-01.html


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           -- Mike


 


P.S.  This notice was also posted at 
http://self-issued.info/?p=3D1552 and as 
@selfissued.






--_000_BY2PR03MB442D9A68D09ABACAE189B79F5BE0BY2PR03MB442namprd_--


From nobody Fri Mar  4 11:57:23 2016
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 CFE021A891C; Fri,  4 Mar 2016 11:57:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160304195722.15295.99595.idtracker@ietfa.amsl.com>
Date: Fri, 04 Mar 2016 11:57:22 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Mar 2016 19:57:23 -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 of the IETF.

        Title           : OAuth 2.0 Token Exchange: An STS for the REST of Us
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-token-exchange-04.txt
	Pages           : 28
	Date            : 2016-03-04

Abstract:
   This specification defines a protocol for a lightweight 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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-04

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


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 Fri Mar  4 12:13:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66ED1A892B for ; Fri,  4 Mar 2016 12:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 IQxd4pyUEge0 for ; Fri,  4 Mar 2016 12:13:37 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 B63D41A8920 for ; Fri,  4 Mar 2016 12:13:37 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id l127so74167132iof.3 for ; Fri, 04 Mar 2016 12:13:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nKEqKfofZixJVXev7cWc6WYDDf+NKnGkCvNNrfPCha4=; b=nhQ6mJPYTJ4ZbmQglsvCynFt9SmG+eeS1Box8e98CVViXsiw+rEW286B4DH53Dh5TO oP7pEVkLWJDlIqRvMuP97ptttZz3gF4rgCo5VMOT8+CBbal5HCdtQ3B0gS6F8DplhU8F /jJ7gDb/41UidBv+ogCxxu98zpu2vEv9QjnB0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nKEqKfofZixJVXev7cWc6WYDDf+NKnGkCvNNrfPCha4=; b=VMHYKqDDDphjvg8yydpElZAZO3W4zNMS/pYp0ceTQw7vqPH4pB+d0aDPd75xoaKaMD zBuSuEL2nb/uJSiz1KnAmb3Wchy0nhzX+y2k43ZhuGAW1w7nE0dkkbWOG3CP8Kf4d4TK 5Yn/7giyAWv87U6zMMPRirORnXuSI2KarvVoSfpzgj9itzrkXmWcPSP6BdZ1gG7tNwqD QTmLrMh+mpo3rzzm3OeIy1p1YExrWu/LATuW47xZm7hrQtwFDRhoTHNiMAgno93Xn14r J0ue5Br8gDZQjRTaWNXWQkLVNV9vWTZ5LFIuWNmeY3KGsclSfOw93UWNS/RQgYi6X1g4 vC+g==
X-Gm-Message-State: AD7BkJIChAV0g3dfsx/8biSMzpZinn9ySkrkFKSqhpWv9Kactk9o7MbHBU/S6+vY+/I6aGkkycvLTg4A/+KkMzz3
X-Received: by 10.107.5.149 with SMTP id 143mr12232504iof.129.1457122417066; Fri, 04 Mar 2016 12:13:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 4 Mar 2016 12:13:07 -0800 (PST)
In-Reply-To: <20160304195722.15295.99595.idtracker@ietfa.amsl.com>
References: <20160304195722.15295.99595.idtracker@ietfa.amsl.com>
From: Brian Campbell 
Date: Fri, 4 Mar 2016 13:13:07 -0700
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=001a113eecee10629a052d3ec072
Archived-At: 
Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-exchange-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Mar 2016 20:13:39 -0000

--001a113eecee10629a052d3ec072
Content-Type: text/plain; charset=UTF-8

A new draft of "OAuth 2.0 Token Exchange" has been published addressing
review comments on the prior draft. The changes from -03 are listed here:

https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-04

   o  Clarified that the "resource" and "audience" request parameters
      can be used at the same time (via http://www.ietf.org/mail-

      archive/web/oauth/current/msg15335.html
).
   o  Clarified subject/actor token validity after token exchange and
      explained a bit more about the recommendation to not issue refresh
      tokens (via http://www.ietf.org/mail-archive/web/oauth/current/

      msg15318.html
).
   o  Updated the examples appendix to use an issuer value that doesn't
      imply that the client issued and signed the tokens and used
      "Bearer" and "urn:ietf:params:oauth:token-type:access_token" in
      one of the responses (via http://www.ietf.org/mail-

      archive/web/oauth/current/msg15335.html
).
   o  Defined and registered urn:ietf:params:oauth:token-type:id_token,
      since some use cases perform token exchanges for ID Tokens and no



---------- Forwarded message ----------
From: 
Date: Fri, Mar 4, 2016 at 12:57 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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

        Title           : OAuth 2.0 Token Exchange: An STS for the REST of
Us
        Authors         : Michael B. Jones
                          Anthony Nadalin
                          Brian Campbell
                          John Bradley
                          Chuck Mortimore
        Filename        : draft-ietf-oauth-token-exchange-04.txt
        Pages           : 28
        Date            : 2016-03-04

Abstract:
   This specification defines a protocol for a lightweight 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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-04

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


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/

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

--001a113eecee10629a052d3ec072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



A new draft of "OAuth 2.0 Token Exchange&quo=
t; has been published addressing review comments on the prior draft. The ch=
anges from -03 are listed here: 

https://tools.ietf.org/html/draft-ietf-oauth-token-exchan=
ge-04

   o  Clarified that the "resource" and "audience" requ=
est parameters
      can be used at the same time (via http://www.ietf=
.org/mail-
      archive/web/oauth/current/msg15335.html).
   o  Clarified subject/actor token validity after token exchange and
      explained a bit more about the recommendation to not issue refresh
      tokens (via http://www.ietf.org/mail-archive/web/=
oauth/current/
      msg15318.html).
   o  Updated the examples appendix to use an issuer value that doesn't
      imply that the client issued and signed the tokens and used
      "Bearer" and "urn:ietf:params:oauth:token-type:access_=
token" in
      one of the responses (via http://www.ietf.org/mai=
l-
      archive/web/oauth/current/msg15335.html).
   o  Defined and registered urn:ietf:params:oauth:token-type:id_token,
      since some use cases perform token exchanges for ID Tokens and no

---------- Forwarded message ---------=
-
From:  <internet-drafts@ietf=
.org>
Date: Fri, Mar 4, 2016 at 12:57 PM
Subject: [OAUT=
H-WG] I-D Action: draft-ietf-oauth-token-exchange-04.txt
To: i-d-announce@ietf.orgCc: oauth@ietf.org




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 of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Token Exchange: An STS for the REST of Us

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich=
ael B. Jones

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Anthony Nadalin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Brian Campbell

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 John Bradley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Chuck Mortimore

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-token-exchange-04.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 28

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2016-03-04



Abstract:

=C2=A0 =C2=A0This specification defines a protocol for a lightweight HTTP- =
and

=C2=A0 =C2=A0JSON- based Security Token Service (STS) by defining how to re=
quest

=C2=A0 =C2=A0and obtain security tokens from OAuth 2.0 authorization server=
s,

=C2=A0 =C2=A0including security tokens employing impersonation and delegati=
on.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-token-exchange/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf=
-oauth-token-exchange-04



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?u=
rl2=3Ddraft-ietf-oauth-token-exchange-04





Please note that it may take a couple of minutes from the time of submissio=
n

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





--001a113eecee10629a052d3ec072--


From nobody Fri Mar  4 18:59:41 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E491B38CD for ; Fri,  4 Mar 2016 18:59:39 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham
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 dJmpychrWh0v for ; Fri,  4 Mar 2016 18:59:37 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 B2EEA1B38C6 for ; Fri,  4 Mar 2016 18:59:36 -0800 (PST)
Received: by mail-lb0-x22c.google.com with SMTP id cf7so64234483lbb.1 for ; Fri, 04 Mar 2016 18:59:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=hUQ4eznTgwcYRd2yvYOGY4xcS+nzl5+XXC4Xdk62pWs=; b=BC68xgmHNvxEEgSLudlRH5FMDj7oQvKnnJIXqKPOmxIUzzr/S9KqGpn+xTdUkVMUck PX8ZEVRSU5acCwnKKZGbEMQGsQkQAuM1HyHbkeoEFKIRaUx7J2xlgXcmsR5kdutpJkLr 4lTkWpbdupiPhq38NEVDj+AoSTXQY87lbxs5o2c/qCXQgn/jL7UY6Q+RHokH+sbS8fV9 zDJYLgYdMzCex3d/0yBMcevueyyeHoe3oqsj3tF8zbmIm2kKMfyoIsVeyB6pzZWgFptc hKH2ASu90V553V6kIkGsQOcO8BYB4ZWA3ttmq1SoyMRbJcETWwAobOpKN5u3EQsGApja NC9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hUQ4eznTgwcYRd2yvYOGY4xcS+nzl5+XXC4Xdk62pWs=; b=EvuB5uZ6+BUc9wzAOeJoG0nCdJVdhv6kygZdnOAq2oBFu1fWwcQHJdZLqWOXmGx7ox 9msv1yNM4SSGthVHMDvkxwIuASTI2I1APzdSpqueOfEufmm0YmBLl7t+RkRyZPgsdAWW HZw0sfFiuzMNJFbOhJycE7uNuu17WKUT7ttXaEVhTwQkoaHpA7DVNQLzWysf7ympLUwW lNyt3omwB7BCCS2jRjC+Jm4brtJZBqL+3Pf4bjZRI45zwSgiIcT9NpDzLehU6U5cZr1Y q6yBkD13F+VfLJrKp1u0ZxNORvesvn8HXM8TZbNJak6SFLg4nlShOW9mBIsoNe9Q6P+B E7QA==
X-Gm-Message-State: AD7BkJKBqDqoXyyEMrEceTMsGwaTL+G5pBkFnKj6XI/qEpxEgRBPj+M/sCC1qd0MptG/NqZ/cFmv/Qd6kMMl4A==
X-Received: by 10.112.140.129 with SMTP id rg1mr4385160lbb.80.1457146774981; Fri, 04 Mar 2016 18:59:34 -0800 (PST)
MIME-Version: 1.0
References: <20160304195722.15295.99595.idtracker@ietfa.amsl.com> 
In-Reply-To: 
From: Thomas Broyer 
Date: Sat, 05 Mar 2016 02:59:25 +0000
Message-ID: 
To: Brian Campbell , oauth 
Content-Type: multipart/alternative; boundary=001a11c26ba8e89675052d446bcd
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-exchange-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 05 Mar 2016 02:59:40 -0000

--001a11c26ba8e89675052d446bcd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Should the act and may_act also be registered for Introspection Endpoint
responses?

Le ven. 4 mars 2016 21:13, Brian Campbell  a
=C3=A9crit :

>
> A new draft of "OAuth 2.0 Token Exchange" has been published addressing
> review comments on the prior draft. The changes from -03 are listed here:
>
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-04
>
>    o  Clarified that the "resource" and "audience" request parameters
>       can be used at the same time (via http://www.ietf.org/mail- 
>       archive/web/oauth/current/msg15335.html ).
>    o  Clarified subject/actor token validity after token exchange and
>       explained a bit more about the recommendation to not issue refresh
>       tokens (via http://www.ietf.org/mail-archive/web/oauth/current/ 
>       msg15318.html ).
>    o  Updated the examples appendix to use an issuer value that doesn't
>       imply that the client issued and signed the tokens and used
>       "Bearer" and "urn:ietf:params:oauth:token-type:access_token" in
>       one of the responses (via http://www.ietf.org/mail- 
>       archive/web/oauth/current/msg15335.html ).
>    o  Defined and registered urn:ietf:params:oauth:token-type:id_token,
>       since some use cases perform token exchanges for ID Tokens and no
>
>
>
> ---------- Forwarded message ----------
> From: 
> Date: Fri, Mar 4, 2016 at 12:57 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-04.txt
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
>         Title           : OAuth 2.0 Token Exchange: An STS for the REST o=
f
> Us
>         Authors         : Michael B. Jones
>                           Anthony Nadalin
>                           Brian Campbell
>                           John Bradley
>                           Chuck Mortimore
>         Filename        : draft-ietf-oauth-token-exchange-04.txt
>         Pages           : 28
>         Date            : 2016-03-04
>
> Abstract:
>    This specification defines a protocol for a lightweight 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's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-04
>
>
> 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/
>
> _______________________________________________
> 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
>

--001a11c26ba8e89675052d446bcd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Should the act and may_act also be registered for Introspect=
ion Endpoint responses?


Le ven. 4 mars 2016 21:13, =
Brian Campbell <bcampbell@=
pingidentity.com> a =C3=A9crit=C2=A0:

A new draft of "OAuth 2.0 Token Ex=
change" has been published addressing review comments on the prior dra=
ft. The changes from -03 are listed here: 

https://tools.ietf.org/html/draft-ietf-oauth-=
token-exchange-04

   o  Clarified that the "resource" and "audience" requ=
est parameters
      can be used at the same time (via http://www.ietf=
.org/mail-
      archive/web/oauth/current/msg15335.html).
   o  Clarified subject/actor token validity after token exchange and
      explained a bit more about the recommendation to not issue refresh
      tokens (via http://www.ietf.org/mail-archive/web/=
oauth/current/
      msg15318.html).
   o  Updated the examples appendix to use an issuer value that doesn't
      imply that the client issued and signed the tokens and used
      "Bearer" and "urn:ietf:params:oauth:token-type:access_=
token" in
      one of the responses (via http://www.ietf.org/mai=
l-
      archive/web/oauth/current/msg15335.html).
   o  Defined and registered urn:ietf:params:oauth:token-type:id_token,
      since some use cases perform token exchanges for ID Tokens and no


----=
------ Forwarded message ----------
From: =
 <internet-drafts@ietf.org>
Date: Fri, Mar 4, =
2016 at 12:57 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-=
exchange-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org




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 of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Token Exchange: An STS for the REST of Us

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich=
ael B. Jones

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Anthony Nadalin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Brian Campbell

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 John Bradley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Chuck Mortimore

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-token-exchange-04.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 28

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2016-03-04



Abstract:

=C2=A0 =C2=A0This specification defines a protocol for a lightweight HTTP- =
and

=C2=A0 =C2=A0JSON- based Security Token Service (STS) by defining how to re=
quest

=C2=A0 =C2=A0and obtain security tokens from OAuth 2.0 authorization server=
s,

=C2=A0 =C2=A0including security tokens employing impersonation and delegati=
on.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-token-exchange/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf=
-oauth-token-exchange-04



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?u=
rl2=3Ddraft-ietf-oauth-token-exchange-04





Please note that it may take a couple of minutes from the time of submissio=
n

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




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a11c26ba8e89675052d446bcd--


From nobody Mon Mar  7 00:44:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF07D1B37C4 for ; Mon,  7 Mar 2016 00:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level: 
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 z18fxrlIq-zR for ; Mon,  7 Mar 2016 00:43:59 -0800 (PST)
Received: from mailgate4.ebu.ch (mailgate4.ebu.ch [193.43.93.76]) by ietfa.amsl.com (Postfix) with ESMTP id 316141B37C1 for ; Mon,  7 Mar 2016 00:43:58 -0800 (PST)
Received: from smtp2010.ebu.ch (HELO mailprd.gva.ebu.ch) ([10.73.222.140]) by mailgate4.ebu.ch with ESMTP/TLS/AES128-SHA; 07 Mar 2016 09:43:56 +0100
Received: from MAILDRS.gva.ebu.ch ([169.254.2.93]) by mailprd.gva.ebu.ch ([fe80::d915:3098:d72d:8897%18]) with mapi id 14.03.0266.001; Mon, 7 Mar 2016 09:43:56 +0100
From: "Barroco, Michael" 
To: "oauth@ietf.org" 
Thread-Topic: Cross Platform Authentication - OAuth 2.0 Device Flow
Thread-Index: AdF4TUn5WIPc0D1oRLui+Bm5k9YcEw==
Date: Mon, 7 Mar 2016 08:43:56 +0000
Message-ID: 
Accept-Language: en-US, fr-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.73.220.154]
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tvp-cpa@list.ebu.ch" 
Subject: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Mar 2016 08:44:02 -0000

Dear all,


We are contacting you because we noticed that you recently restarted the wo=
rk on OAuth 2.0 Device Flow. We are in the process of publishing an ETSI st=
andard [1] specifying a protocol with very similar goals. This has been dev=
eloped by an EBU (European Broadcasting Union) working group involving broa=
dcasters, such as BBC, SRG-RTS, VRT, RTVE, TVP, Global Radio UK, and device=
 manufacturers.


Our work on the =93Cross Platform Authentication=94 protocol targets media =
devices, such as connected TVs and radio receivers. It is based on the earl=
y OAuth 2.0 Device Flow draft, but includes additional features driven by b=
roadcast industry requirements. These include: dynamic registration of clie=
nts, dynamic discovery of the authorization provider, and issuing of access=
 tokens without requiring association with a user account in order to provi=
de device-based authentication that does not require user sign-in or pairin=
g. Our draft protocol specification is available here [2].


Cross Platform Authentication also specifies several aspects left open to i=
mplementers in OAuth 2.0, such as endpoint URL paths, to facilitate interop=
erability. Also note that reference implementations are available [3].


We would be very interested in working together with you to explain our des=
ign requirements and try to align our protocol designs.


With best regards,


The EBU Cross Platform Authentication group

https://tech.ebu.ch/cpa



[1] https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=
=3D47970


[2] https://tech.ebu.ch/docs/tech/tech3366.pdf

[3] https://tech.ebu.ch/code/cpa
---------------------------------------------------------------------------=
---

**************************************************
This email and any files transmitted with it are confidential and intended =
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager.=
 This footnote also confirms that this email message has been swept by the =
mailgateway
**************************************************


From nobody Mon Mar  7 07:52:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DAC1B4337 for ; Mon,  7 Mar 2016 07:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 zy3hHGnF9jAs for ; Mon,  7 Mar 2016 07:51:58 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 9E4C31B4336 for ; Mon,  7 Mar 2016 07:51:58 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id ig19so21077907igb.1 for ; Mon, 07 Mar 2016 07:51:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9BIudLF1VNDeqzTkv2zqVneRShhfe8ntOxGIY5ugWbY=; b=JNOMO6LILjmeU5E4VfKJU0LKhAAZJ4peGe32lpcam3kF17c+jUoWlQndw+iJNOTIt8 poJtqLSikoZ0dZh0DAF8CXY+2xWNeFntyydcdQGVcP750cbAKopEMh+vPxDmYvmJpfeA x/cUzj/j6BoVwZatmKluiTlJ3dao7d+bMo/A0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9BIudLF1VNDeqzTkv2zqVneRShhfe8ntOxGIY5ugWbY=; b=ieqt4oNhEN8VFlZZpkuVe4ol336h2tMw9tMFNpqdNIs7LkfidTlKqJV3nt1zMEWlR8 BtCAi4WkJOKwQRwPoLkP8rkvqOF2ayE/NJmDV5Lj1/9nn6Kkk5Ky6xmxspMkUoPWEjMM reZ75frmwU9V8liERDJFxTaFkqZbi+HVDErK28HrGZm+x0GfM+cdQUQs3g8r5WSa0DHI CvT9ir+b6w6sowxiaMaEg4DSUPLRRLy5Iym37rixUkp218ScKjzBKVRi2xwXKi5r7OYk Qhlqw0MRkUXUcQTwUJg4BGT0pI5e3kc/Zy5FXITArwjS/+C+vdUlHQRMWePkA227GLT1 qd6w==
X-Gm-Message-State: AD7BkJJXVQbWkSikJbrpUSPEC8NdCzWu3k1UBOC1pXkzTC70+BHG8sVb0KW8Crz3R9Vjho1n25mw/kw6FyPeyEjF
X-Received: by 10.50.20.129 with SMTP id n1mr13309130ige.77.1457365917437; Mon, 07 Mar 2016 07:51:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Mon, 7 Mar 2016 07:51:27 -0800 (PST)
In-Reply-To: 
References: <20160304195722.15295.99595.idtracker@ietfa.amsl.com>  
From: Brian Campbell 
Date: Mon, 7 Mar 2016 08:51:27 -0700
Message-ID: 
To: Thomas Broyer 
Content-Type: multipart/alternative; boundary=047d7bd755aed12f3a052d777132
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-exchange-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Mar 2016 15:52:00 -0000

--047d7bd755aed12f3a052d777132
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I hadn't considered that but it's a good question. Do folks see value in
the act/may_act claim semantics for introspection? I think doing it for act
makes a lot of sense while may_act seems a bit awkward in that context of
use. But maybe I'm just not seeing it.

On Fri, Mar 4, 2016 at 7:59 PM, Thomas Broyer  wrote:

> Should the act and may_act also be registered for Introspection Endpoint
> responses?
>
> Le ven. 4 mars 2016 21:13, Brian Campbell  a
> =C3=A9crit :
>
>>
>> A new draft of "OAuth 2.0 Token Exchange" has been published addressing
>> review comments on the prior draft. The changes from -03 are listed here=
:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-04
>>
>>    o  Clarified that the "resource" and "audience" request parameters
>>       can be used at the same time (via http://www.ietf.org/mail- 
>>       archive/web/oauth/current/msg15335.html ).
>>    o  Clarified subject/actor token validity after token exchange and
>>       explained a bit more about the recommendation to not issue refresh
>>       tokens (via http://www.ietf.org/mail-archive/web/oauth/current/ 
>>       msg15318.html ).
>>    o  Updated the examples appendix to use an issuer value that doesn't
>>       imply that the client issued and signed the tokens and used
>>       "Bearer" and "urn:ietf:params:oauth:token-type:access_token" in
>>       one of the responses (via http://www.ietf.org/mail- 
>>       archive/web/oauth/current/msg15335.html ).
>>    o  Defined and registered urn:ietf:params:oauth:token-type:id_token,
>>       since some use cases perform token exchanges for ID Tokens and no
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: 
>> Date: Fri, Mar 4, 2016 at 12:57 PM
>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-04.txt
>> To: i-d-announce@ietf.org
>> Cc: oauth@ietf.org
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Web Authorization Protocol of the IETF.
>>
>>         Title           : OAuth 2.0 Token Exchange: An STS for the REST
>> of Us
>>         Authors         : Michael B. Jones
>>                           Anthony Nadalin
>>                           Brian Campbell
>>                           John Bradley
>>                           Chuck Mortimore
>>         Filename        : draft-ietf-oauth-token-exchange-04.txt
>>         Pages           : 28
>>         Date            : 2016-03-04
>>
>> Abstract:
>>    This specification defines a protocol for a lightweight 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's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-04
>>
>>
>> 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/
>>
>> _______________________________________________
>> 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
>>
>

--047d7bd755aed12f3a052d777132
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I hadn't considered that but it's a good ques=
tion. Do folks see value in the act/may_act claim semantics for introspecti=
on? I think doing it for act makes a lot of sense while may_act seems a bit=
 awkward in that context of use. But maybe I'm just not seeing it.=C2=
=A0 

On Fri, Mar 4, 2016 at 7:59 PM, Thomas Broyer <t.broyer@gmail.com&=
gt; wrote:
Should t=
he act and may_act also be registered for Introspection Endpoint responses?=



Le ven. 4 mars 2016 21:13, =
Brian Campbell <bcampbell@pingidentity.com> a =C3=A9crit=C2=A0:

A new draft of "=
OAuth 2.0 Token Exchange" has been published addressing review comment=
s on the prior draft. The changes from -03 are listed here: 

<=
div>
https://tools.ietf.org/html/d=
raft-ietf-oauth-token-exchange-04

   o  Clarified that the "resource" and "audience" requ=
est parameters
      can be used at the same time (via http://www.ietf=
.org/mail-
      archive/web/oauth/current/msg15335.html).
   o  Clarified subject/actor token validity after token exchange and
      explained a bit more about the recommendation to not issue refresh
      tokens (via http://www.ietf.org/mail-archive/web/=
oauth/current/
      msg15318.html).
   o  Updated the examples appendix to use an issuer value that doesn't
      imply that the client issued and signed the tokens and used
      "Bearer" and "urn:ietf:params:oauth:token-type:access_=
token" in
      one of the responses (via http://www.ietf.org/mai=
l-
      archive/web/oauth/current/msg15335.html).
   o  Defined and registered urn:ietf:params:oauth:token-type:id_token,
      since some use cases perform token exchanges for ID Tokens and no


----=
------ Forwarded message ----------
From: =
 <internet-drafts@ietf.org>
Date: Fri, Mar 4, =
2016 at 12:57 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-=
exchange-04.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org




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 of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Token Exchange: An STS for the REST of Us

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich=
ael B. Jones

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Anthony Nadalin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Brian Campbell

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 John Bradley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Chuck Mortimore

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-token-exchange-04.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 28

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2016-03-04



Abstract:

=C2=A0 =C2=A0This specification defines a protocol for a lightweight HTTP- =
and

=C2=A0 =C2=A0JSON- based Security Token Service (STS) by defining how to re=
quest

=C2=A0 =C2=A0and obtain security tokens from OAuth 2.0 authorization server=
s,

=C2=A0 =C2=A0including security tokens employing impersonation and delegati=
on.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-token-exchange/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf=
-oauth-token-exchange-04



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?u=
rl2=3Ddraft-ietf-oauth-token-exchange-04





Please note that it may take a couple of minutes from the time of submissio=
n

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




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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







--047d7bd755aed12f3a052d777132--


From nobody Wed Mar  9 23:28:20 2016
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 C0F8112D57B for ; Wed,  9 Mar 2016 23:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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] 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 7kbjfWDCJDmd for ; Wed,  9 Mar 2016 23:28:17 -0800 (PST)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 E8C0412D572 for ; Wed,  9 Mar 2016 23:28:16 -0800 (PST)
Received: by mail-vk0-x22c.google.com with SMTP id e185so85529356vkb.1 for ; Wed, 09 Mar 2016 23:28:16 -0800 (PST)
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:date:message-id:subject:from:to :cc; bh=e7ooY8LP/+6+qW+2MBAohrI3NnkEl/VQXWiGRneuF8w=; b=sNwfPam932vN0SiWTeI/+vDZtYxRl42LH5hqP0XAn87hJzKmXzvq0pyfviaA/7Z6Wl fv/b5tVArKsoMt07OAUjvqyO7/7uq49ppqokWqsjs9CvrStoKI0JLSaz7F81Gslv+WUC N639YsSh2P72eYGHDoKqpA23lpyPLM6znRgerOQnc5NTtPTGqcyNz7I9giLKq/GzMc+8 vRRTn4OXArPx1Hnjrey0hfCoc6BPc/UwKsKWs/Wk8Y4kAhrMFxogxRw8bmhpsFwesdzt gDYwnpBCkVQvas+t/7uRl3sppf4dE6YSk9TRRLLZkt11xrR4fj5llOl1yIsxA3GuFPMB X2VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=e7ooY8LP/+6+qW+2MBAohrI3NnkEl/VQXWiGRneuF8w=; b=kZXiP9yAP+wPkkOCP/fmDIPXEPX0pNolmgAkBU2iXh3DRSj2meqaRaGiowqmz5mRmZ M2Ws6n9XTv8hESdoZKrnq/P0ytYe2ona+OowPH8EKgZEEpNkXsuXtXM5AMTVCeu7GEpR pawbLnewGD5zkHkslWjx4mU5BpqCW+idjlEjrsc+YSUa4qXMBFfo0oGZJW3TMJDNxaWG GZnCQJ5jo9eWAytlgiffyr1D/6dWyYo23VwZSKRXKewtOAYAK2veqoym46mU44Af3SYV UwdEE1KUtLVL54HmOuhwBGR491lx4Jit8QPagDkN9Sx7uj0jDjTxULwI6O//b8ZJWT5o cQmQ==
X-Gm-Message-State: AD7BkJK09pBZWCON+pQYbO96KLqejccjP+S62bsvcz+yQJ0vgqA6IT2b2m5PYHoJ2aVYMTzz6Kkvitq5s+4hLg==
MIME-Version: 1.0
X-Received: by 10.31.49.207 with SMTP id x198mr2064277vkx.1.1457594895859; Wed, 09 Mar 2016 23:28:15 -0800 (PST)
Received: by 10.159.37.42 with HTTP; Wed, 9 Mar 2016 23:28:15 -0800 (PST)
In-Reply-To: <56C5C9D5.6040703@gmx.net>
References: <56C5C9D5.6040703@gmx.net>
Date: Thu, 10 Mar 2016 08:28:15 +0100
Message-ID: 
From: Samuel Erdtman 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a11430efefe94e7052dacc1c4
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 07:28:19 -0000

--001a11430efefe94e7052dacc1c4
Content-Type: text/plain; charset=UTF-8

Hi,

I sent a few comments two weeks ago that has not been explicitly commented
on. (I might have sent them in the wrong way, if so sorry about that)

https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w

Most of the comments are minor but I would like to se
jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
and at least get a comment of the difference between response_types_supported
and grant_types_supported

Best regards
//Samuel




On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a11430efefe94e7052dacc1c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I sent a few comments two weeks ago=
 that has not been explicitly commented on. (I might have sent them in the =
wrong way, if so sorry about that)=C2=A0




On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <=
span dir=3D"ltr"><hannes.tschofenig@gmx.net> wrote:
Hi all,



This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery specifica=
tion:

https://tools.ietf.org/html/draft-ietf-oa=
uth-discovery-01



Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a11430efefe94e7052dacc1c4--


From nobody Thu Mar 10 02:21:38 2016
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 8398512D641 for ; Thu, 10 Mar 2016 02:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 VeGKTnhhjGul for ; Thu, 10 Mar 2016 02:21:35 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E6312D5C9 for ; Thu, 10 Mar 2016 02:21:34 -0800 (PST)
Received: from [192.168.10.140] ([195.149.223.22]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MHrk1-1agz3e2pkj-003bEn for ; Thu, 10 Mar 2016 11:21:31 +0100
To: "oauth@ietf.org" 
References: <56C5C273.30406@gmx.net>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56E14AAA.2040203@gmx.net>
Date: Thu, 10 Mar 2016 11:21:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C5C273.30406@gmx.net>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KlSvXPbngCtKBpUUSdJ3fJMnAEB7qKIFO"
X-Provags-ID: V03:K0:3S8NAkX/yqZxD3cHeML75Rbr0EiYcMvS/YktvHlH3TUZT5+5UKD UQ7HlFau60gFFHmrB7UGOpgO6C0D3jWeYR3g4+4YMFWyDM8UpjMG1o6nuAttCw8OxFvaKKH gT2sZjNwPf9HZ/BP+SZanenqR5iYtyN8j/hdbKiPmd+bwBTvG2sOg60lu1YJLe7A1eSALez 1E/7r3dBoa0m9p5ZyqFAw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:rZT/PTzuKRo=:TxyZ9YP669TFtC31kfw4fU Z/bMww/7ymf+GIKHG5UdkMQhG5LVzBkPkFafmZ7HFItD7ydMRNdDxm5PkzdP9ew7M1Y442cWP JUgWqr4IxNChnWCSNEd5CuhQ1iiUXS46TKIAtcDKPtMiL8+qWmiJD+1UIV1lqAeN3vVaQE3TW HO6June8BPbJrh6ZBygM65Lp9QM5/qohktv2R4DPA92E/o1eBMhOV2WP/x0QTKBa4Y1VOH0bI FU0ekKA1p/n6IzzIRXQjTRyJ7MJ//dAgORGAoQnaOOtxnM+/bmEOxnSw7kooTZQXpCGpW9ns8 Fr9STk2dxbu2+mwUmEUgmq9+S6ycc3Je5akQAoiROeeRNuH6rSHm4CjLqk6KAlH4a7FQn6MlC usqDrTESFsXHkW1kh6Awipp0qAZnydrnZW9Styn2oYgA+z94tniN1Rnbnic/ZmriCgWCc/yB9 fz/ZtXMTQHm3nE5SlO9jrIEkwQvBAaBTzuxi8GLXFbenXfk5xbugo6MCp6roLeK4bSCiwQNSo HPGDRxM2TssCvOs0Z9R16BR43//4+Y8w11e8Kox3yniwguNThSpiWqV8zUgr6bLP9F+EoBbgW HHl2rZX3WKEIgTNq2k2kFsQEwOqoTvy9RhjoD1yjDATON8JgF1QwprhviWy1ur7f7ALx0ZAI0 KVAcLGXhwAwC4nEJvKs8E7DjCa6nC4qr+BgVUDIp8+UV01MCiSKfLxhMbDSi1Tu1pZ0KrzF8W AZ69A8GBWFfdyhR8AEjmfIDCMA7q0yBuxzj+4fJTz4SPcUM6jROruvDcPkE=
Archived-At: 
Subject: [OAUTH-WG] Conclusion ... was 2nd Call for Adoption: Authentication Method Reference Values
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 10:21:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--KlSvXPbngCtKBpUUSdJ3fJMnAEB7qKIFO
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi all,

we would like to conclude this call for adoption.

Based on the feedback we would believe that this document should become
a working group document and thereby a starting point for further work.

We do, however, take the feedback from Mike Schwartz serious. He raises
a good point regarding the reliability of the conveyed values when
different algorithms, and different processes are used by those making
the assertions. This needs to be addressed as part of operational
considerations in a future version of the document.

We also believe that the introduction needs to be extended to explain
the envisioned use case/scenarios (or call them architecture) for those
who had not been involved in this work from the beginning.

Ciao
Hannes & Derek

On 02/18/2016 02:09 PM, Hannes Tschofenig wrote:
> In response to my message to the list regarding the initial call for
> adoption of the Authentication Method Reference Values draft, see
> https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike=

> submitted an updated version of the document to take raised concerns
> into account. Several working group participants responded positively t=
o
> the new version.
>=20
> We would therefore like to issue a 2nd call for adoption of the recentl=
y
> submitted version -05:
> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
>=20
> Please let us know by March 3rd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>=20
> Ciao
> Hannes & Derek
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--KlSvXPbngCtKBpUUSdJ3fJMnAEB7qKIFO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW4UqqAAoJEGhJURNOOiAtcS0IAJAF3zLI+N3RPCyXt6jnxk7Z
3el5zYGmyTwaG0CKKlsmBmPezIWRIH0rNVrHwCBt9yHN9vJlGxiTW/5QDhS9PYHX
wxzksDdDrsq73oXePs+ncZS3eN73qmCFCuhmuW/W3ewT6fMzCm94QJb1Nntt64MA
EOdXDChQwW1QzjMlRSQUC47qAPvLKPg2pCaAMh+eBdD4t5o+2/Wz3cDj7pazwQiv
AL70HkB/GYMA5m6QWXbaM4b/qW+e2y7rIwf4kSOJU4FA0+AQRJHjYisav8b8oYbr
03tpr/0yr98Vk9qaQoBQbcMXo5Uio5Y7zCd1tJtEhEez1JDuLr6YQTmunJ5SVjc=
=XlfO
-----END PGP SIGNATURE-----

--KlSvXPbngCtKBpUUSdJ3fJMnAEB7qKIFO--


From nobody Thu Mar 10 03:33:31 2016
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 6BFA912D6B6 for ; Thu, 10 Mar 2016 03:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 YyaKob7Nadm7 for ; Thu, 10 Mar 2016 03:33:27 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D841712D6A9 for ; Thu, 10 Mar 2016 03:33:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=92BFEd86HOm4ck8G8/jYwD5J/fIKkiipBPgt645Iio0=; b=ElRC1F196SOU/1MxAHkV7O61fzCzcsTO1PwtOiumx2Lx9YJAEnZ3N3RaeK0dNHB1NN6Rf6fM0qyg2VceX8vsCUyKqtcXkybK2zN9JIojWd+uoKXnJ1m065l0jFEE5KcOR14Gr7aC//ZbnaAJXn/773eGZvY5I6zmmybevY64qlY=
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (TLS) id 15.1.427.16; Thu, 10 Mar 2016 11:33:22 +0000
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0427.019; Thu, 10 Mar 2016 11:33:22 +0000
From: Mike Jones 
To: Samuel Erdtman , Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH0aW6XIA1+zU6W/8nt5o9Vup9SaC2AgABAvnA=
Date: Thu, 10 Mar 2016 11:33:22 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: erdtman.se; dkim=none (message not signed) header.d=none;erdtman.se; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.244.136.197]
x-ms-office365-filtering-correlation-id: b510035f-1a7a-4944-0152-08d348d7c9b1
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 5:7GunmJHciIbk3Y2kVqeyirdTkv5Jz8N2NKm6u7ND61Z9J1lHp4rJhXECbNmDLDDrkoWx4u8Ty9l79JWCQhwHJ0BE+Rv3UwJ/5doepYX+62bJ2q2rvEBROqubBa4yOJb6nZAIZknkIyLsPVzclw4jRw==; 24:cniQVXMxeb1BLz+02FOBTF0aVp1tp/Lbu21j8xJ/DwlMSah6OmJac+sbE/8H3VUaw8fDsQjSa3xFe+O6jbF4C7LltYck7+AbjFgW1lR+OWM=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; 
x-forefront-prvs: 08770259B4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(53754006)(77096005)(19580405001)(1096002)(76576001)(122556002)(86612001)(86362001)(189998001)(3280700002)(54356999)(50986999)(5003600100002)(76176999)(5002640100001)(19300405004)(5001770100001)(4326007)(3660700001)(586003)(10090500001)(1220700001)(102836003)(5008740100001)(99286002)(19617315012)(10400500002)(2906002)(6116002)(19609705001)(3846002)(15975445007)(5005710100001)(11100500001)(5004730100002)(106116001)(66066001)(87936001)(16236675004)(19580395003)(33656002)(10290500002)(19625215002)(790700001)(81166005)(92566002)(2900100001)(74316001)(575784001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645E0CD7293E541DC2AA993F5B40SN1PR0301MB1645_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2016 11:33:22.6642 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 11:33:29 -0000

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

VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBTYW11ZWwuICBZZXMsIHlvdeKAmXJlIHJpZ2h0IHRo
YXQgandrc191cmkgc2hvdWxkIGJlIE9QVElPTkFMLCBzaW5jZSBub3QgYWxsIHVzZSBjYXNlcyBu
ZWVkIGtleXMuICBMaWtld2lzZSwgcmVnaXN0cmF0aW9uX2VuZHBvaW50IHNob3VsZCBiZSBPUFRJ
T05BTCwgcmF0aGVyIHRoYW4gUkVDT01NRU5ERUQuDQoNClRoZSBncmFudF90eXBlIHZhbHVlcyBh
cmUgZGVmaW5lZCBpbiBPQXV0aCBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gW1JGQyA3NTkx
XSBhbmQgYXJlIGlkZW50aWZpZXJzIGZvciB0aGUgZ3JhbnQgdHlwZSBjb25jZXB0IGRlZmluZWQg
aW4gUkZDIDY3NDkuICBUaGV5IGlkZW50aWZ5IHRoZSBncmFudCB0eXBlcyB0aGF0IGNhbiBiZSB1
c2VkIGF0IHRoZSBUb2tlbiBFbmRwb2ludC4gIFRoZSByZXNwb25zZV90eXBlIGNvbmNlcHQgaXMg
ZGVmaW5lZCBpbiBSRkMgNjc0OSwgYW5kIGlkZW50aWZpZXMgYSByZXNwb25zZSBzeW50YXggZnJv
bSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gIFdlIGNhbiBzYXkgbW9yZSB0byBkaWZmZXJl
bnRpYXRlIHRoZXNlIGluIHRoZSBuZXh0IGRyYWZ0Lg0KDQpCVFcsIGxlc3QgaXQgYmUgaW4gZG91
YnQsIEkgc3VwcG9ydCB0aGlzIGRyYWZ0IG1vdmluZyBmb3J3YXJkLCB3aXRoIHRoZSBuYW1lIGNo
YW5nZWQgdG8g4oCcT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeeKAnSBv
ciDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCd
IOKAkyBhcyBkaXNjdXNzZWQgaW4gdGhlIHRocmVhZCDigJxPQXV0aCAyLjAgRGlzY292ZXJ5IExv
Y2F0aW9u4oCdLiAgSeKAmW0gYWxzbyBvcGVuIHRvIGludHJvZHVjaW5nIHRoZSDigJwvLndlbGwt
a25vd24vb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXLigJ0gaWRlbnRpZmllciwgYXMgZGlzY3Vz
c2VkIGluIHRoYXQgdGhyZWFkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTYW11ZWwgRXJkdG1hbg0KU2VudDog
V2VkbmVzZGF5LCBNYXJjaCA5LCAyMDE2IDExOjI4IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcg
PGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIE9BdXRoIDIuMCBEaXNj
b3ZlcnkNCg0KSGksDQoNCkkgc2VudCBhIGZldyBjb21tZW50cyB0d28gd2Vla3MgYWdvIHRoYXQg
aGFzIG5vdCBiZWVuIGV4cGxpY2l0bHkgY29tbWVudGVkIG9uLiAoSSBtaWdodCBoYXZlIHNlbnQg
dGhlbSBpbiB0aGUgd3Jvbmcgd2F5LCBpZiBzbyBzb3JyeSBhYm91dCB0aGF0KQ0KDQpodHRwczov
L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL1owTENCdXZGRENRVGQ0eGZ3b2Rk
bGJDMlA3dw0KDQpNb3N0IG9mIHRoZSBjb21tZW50cyBhcmUgbWlub3IgYnV0IEkgd291bGQgbGlr
ZSB0byBzZQ0Kandrc191cmkgdG8gYmUgY2hhbmdlZCBmcm9tIFJFUVVJUkVEIHRvIE9QVElPTkFM
IG9yIFJFQ09NTUVOREVEDQphbmQgYXQgbGVhc3QgZ2V0IGEgY29tbWVudCBvZiB0aGUgZGlmZmVy
ZW5jZSBiZXR3ZWVuIHJlc3BvbnNlX3R5cGVzX3N1cHBvcnRlZCBhbmQgZ3JhbnRfdHlwZXNfc3Vw
cG9ydGVkDQoNCkJlc3QgcmVnYXJkcw0KLy9TYW11ZWwNCg0KDQoNCg0KT24gVGh1LCBGZWIgMTgs
IDIwMTYgYXQgMjo0MCBQTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdt
eC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIGFsbCwN
Cg0KVGhpcyBpcyBhIExhc3QgQ2FsbCBmb3IgY29tbWVudHMgb24gdGhlICBPQXV0aCAyLjAgRGlz
Y292ZXJ5IHNwZWNpZmljYXRpb246DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDENCg0KU2luY2UgdGhpcyBkb2N1bWVudCB3YXMgb25seSBh
ZG9wdGVkIHJlY2VudGx5IHdlIGFyZSBydW5uaW5nIHRoaXMgbGFzdA0KY2FsbCBmb3IgKiozIHdl
ZWtzKiouDQoNClBsZWFzZSBoYXZlIHlvdXIgY29tbWVudHMgaW4gbm8gbGF0ZXIgdGhhbiBNYXJj
aCAxMHRoLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K
PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91
dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhh
bmtzIGZvciB5b3VyIGNvbW1lbnRzLCBTYW11ZWwuJm5ic3A7IFllcywgeW914oCZcmUgcmlnaHQg
dGhhdCBqd2tzX3VyaSBzaG91bGQgYmUgT1BUSU9OQUwsIHNpbmNlIG5vdCBhbGwgdXNlIGNhc2Vz
IG5lZWQga2V5cy4mbmJzcDsgTGlrZXdpc2UsIHJlZ2lzdHJhdGlvbl9lbmRwb2ludCBzaG91bGQN
CiBiZSBPUFRJT05BTCwgcmF0aGVyIHRoYW4gUkVDT01NRU5ERUQuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgZ3JhbnRfdHlwZSB2YWx1ZXMgYXJlIGRlZmlu
ZWQgaW4gT0F1dGggRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIFtSRkMgNzU5MV0gYW5kIGFy
ZSBpZGVudGlmaWVycyBmb3IgdGhlIGdyYW50IHR5cGUgY29uY2VwdCBkZWZpbmVkIGluIFJGQyA2
NzQ5LiZuYnNwOyBUaGV5IGlkZW50aWZ5DQogdGhlIGdyYW50IHR5cGVzIHRoYXQgY2FuIGJlIHVz
ZWQgYXQgdGhlIFRva2VuIEVuZHBvaW50LiZuYnNwOyBUaGUgcmVzcG9uc2VfdHlwZSBjb25jZXB0
IGlzIGRlZmluZWQgaW4gUkZDIDY3NDksIGFuZCBpZGVudGlmaWVzIGEgcmVzcG9uc2Ugc3ludGF4
IGZyb20gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuJm5ic3A7IFdlIGNhbiBzYXkgbW9yZSB0
byBkaWZmZXJlbnRpYXRlIHRoZXNlIGluIHRoZSBuZXh0IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QlRXLCBsZXN0IGl0IGJlIGluIGRvdWJ0LCBJIHN1
cHBvcnQgdGhpcyBkcmFmdCBtb3ZpbmcgZm9yd2FyZCwgd2l0aCB0aGUgbmFtZSBjaGFuZ2VkIHRv
IOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnnigJ0gb3Ig4oCcT0F1
dGggMi4wIEF1dGhvcml6YXRpb24NCiBTZXJ2ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCdIOKAkyBh
cyBkaXNjdXNzZWQgaW4gdGhlIHRocmVhZCDigJxPQXV0aCAyLjAgRGlzY292ZXJ5IExvY2F0aW9u
4oCdLiZuYnNwOyBJ4oCZbSBhbHNvIG9wZW4gdG8gaW50cm9kdWNpbmcgdGhlDQo8L3NwYW4+4oCc
Ly53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCdIDxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj4NCmlkZW50aWZpZXIsIGFzIGRpc2N1c3NlZCBpbiB0aGF0IHRocmVh
ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF
bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21w
b3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNhbXVlbCBFcmR0bWFuPGJyPg0KPGI+
U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggOSwgMjAxNiAxMToyOCBQTTxicj4NCjxiPlRvOjwv
Yj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7PGJy
Pg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B
VVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlbnQgYSBmZXcgY29tbWVudHMgdHdvIHdl
ZWtzIGFnbyB0aGF0IGhhcyBub3QgYmVlbiBleHBsaWNpdGx5IGNvbW1lbnRlZCBvbi4gKEkgbWln
aHQgaGF2ZSBzZW50IHRoZW0gaW4gdGhlIHdyb25nIHdheSwgaWYgc28gc29ycnkgYWJvdXQgdGhh
dCkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0
aC9aMExDQnV2RkRDUVRkNHhmd29kZGxiQzJQN3ciPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v
cmcvYXJjaC9tc2cvb2F1dGgvWjBMQ0J1dkZEQ1FUZDR4ZndvZGRsYkMyUDd3PC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3N0IG9mIHRo
ZSBjb21tZW50cyBhcmUgbWlub3IgYnV0IEkgd291bGQgbGlrZSB0byBzZSZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+andrc191cmkgdG8g
YmUgY2hhbmdlZCBmcm9tJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6
YmxhY2siPlJFUVVJUkVEPC9zcGFuPiZuYnNwO3RvIE9QVElPTkFMIG9yJm5ic3A7PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlJFQ09NTUVOREVEPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPmFuZCBhdCBsZWFzdCBnZXQgYSBjb21t
ZW50IG9mIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4mbmJzcDtyZXNwb25zZV90eXBlc19zdXBwb3J0
ZWQgYW5kIGdyYW50X3R5cGVzX3N1cHBvcnRlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Y29sb3I6YmxhY2siPkJlc3QgcmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2NvbG9yOmJsYWNrIj4vL1NhbXVlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMTgsIDIw
MTYgYXQgMjo0MCBQTSwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5u
ZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdA
Z214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgYWxsLDxicj4N
Cjxicj4NClRoaXMgaXMgYSBMYXN0IENhbGwgZm9yIGNvbW1lbnRzIG9uIHRoZSZuYnNwOyBPQXV0
aCAyLjAgRGlzY292ZXJ5IHNwZWNpZmljYXRpb246PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292
ZXJ5LTAxPC9hPjxicj4NCjxicj4NClNpbmNlIHRoaXMgZG9jdW1lbnQgd2FzIG9ubHkgYWRvcHRl
ZCByZWNlbnRseSB3ZSBhcmUgcnVubmluZyB0aGlzIGxhc3Q8YnI+DQpjYWxsIGZvciAqKjMgd2Vl
a3MqKi48YnI+DQo8YnI+DQpQbGVhc2UgaGF2ZSB5b3VyIGNvbW1lbnRzIGluIG5vIGxhdGVyIHRo
YW4gTWFyY2ggMTB0aC48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzICZhbXA7IERlcmVrPGJy
Pg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA
aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_SN1PR0301MB1645E0CD7293E541DC2AA993F5B40SN1PR0301MB1645_--


From nobody Thu Mar 10 03:51:44 2016
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 0A94F12D6C6 for ; Thu, 10 Mar 2016 03:51:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 NvraaFR16dS5 for ; Thu, 10 Mar 2016 03:51:41 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 8414312D6C2 for ; Thu, 10 Mar 2016 03:51:40 -0800 (PST)
Received: by mail-lb0-x22f.google.com with SMTP id bc4so107976263lbc.2 for ; Thu, 10 Mar 2016 03:51:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LH4z1+9VjU7pMtoqRH8+QBdzLyxezM3VY4XmSMV11cs=; b=Krr1FIhz33R+ZlXLtU2Y2ZvPZghbfHV56rMleW4uiZKx0k29JE3dc/hLLCT6+MZXbi cVBf4Z3EHVyZf6ZuEWG4gQEbrE1VzCDLzdgkvwGJy2v8JWjJU9nRwbRujGP8yyN9Eofk XURyZ54qwU24gCpeV1nvx3/e7B7tWKfBgnMV1ONK929Vic8GYN4pbMDptht9kkdUgvrk PVQ3PXwf9a7QmaG27z/e/gxPONWczZdkZQvY/7X2CQPvyiqvbpGcbXZdeEOCAk3O7I66 qAqowIiULkFTVdhC5YNQB1VTffVuyX8tklBXC+h2240X+FXxhKNvpesszwRp8w0Gs5b1 m4vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LH4z1+9VjU7pMtoqRH8+QBdzLyxezM3VY4XmSMV11cs=; b=Jb6dgjNi31sQcK2tDgcCKTIlqz09Jcw3+SGQN/DgClwkbyXltZqhsL85o6k1lAgCwA iDqDkCU8jg+eQCU5U44QK6ra/LcrixTAdxYYSZMuKiLYVFxM1NNHyXNLprt1S7DlD08S yLZWBSOZZj0094/vWi3BzUfmm4UcIhYTmlN/MoWjHSsuulwhP6BRX83+eHm28io9koK0 0hqVsNz/90WfjUKzHvzoIj1uxzebkXNTK/mymInEvOZ5+n0hf6HeiCSVSZMAovWl2s/G 7oTMPtZ+0FzgXMV5cyPS84lMmJRqBJMyN73bCxpw8I4sHyXhHJn9stm7nsekHi3nJ7O2 RRZw==
X-Gm-Message-State: AD7BkJK2KdkNZiV9oQrEUHWypDpr+FPgonatcnGItLA/vj94P7tZZxYis4TgoIpJ5Ov+7ikSn80OXiMrLb8Biw==
X-Received: by 10.25.143.65 with SMTP id r62mr834117lfd.58.1457610698448; Thu, 10 Mar 2016 03:51:38 -0800 (PST)
MIME-Version: 1.0
References: <56C5C9D5.6040703@gmx.net>  
In-Reply-To: 
From: Thomas Broyer 
Date: Thu, 10 Mar 2016 11:51:28 +0000
Message-ID: 
To: Mike Jones , Samuel Erdtman ,  Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a114035fee6e916052db06f2d
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 11:51:43 -0000

--001a114035fee6e916052db06f2d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree with Samuel's comments wrt jwks_uri and registration_endpoint; and
support the name change to =E2=80=9COAuth 2.0 Authorization Server Discover=
y
Metadata=E2=80=9D (or possibly =E2=80=9COAuth 2.0 Authorization Server Disc=
overy=E2=80=9D; but I'd
rather narrow down the scope to only talk about metadata, without discovery
mechanism of that metadata; I won't fight for that though, it's just a
preference, not a strong opinion)

On Thu, Mar 10, 2016 at 12:33 PM Mike Jones 
wrote:

> Thanks for your comments, Samuel.  Yes, you=E2=80=99re right that jwks_ur=
i should
> be OPTIONAL, since not all use cases need keys.  Likewise,
> registration_endpoint should be OPTIONAL, rather than RECOMMENDED.
>
>
>
> The grant_type values are defined in OAuth Dynamic Client Registration
> [RFC 7591] and are identifiers for the grant type concept defined in RFC
> 6749.  They identify the grant types that can be used at the Token
> Endpoint.  The response_type concept is defined in RFC 6749, and identifi=
es
> a response syntax from the authorization endpoint.  We can say more to
> differentiate these in the next draft.
>
>
>
> BTW, lest it be in doubt, I support this draft moving forward, with the
> name changed to =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=
=9D or =E2=80=9COAuth 2.0
> Authorization Server Discovery Metadata=E2=80=9D =E2=80=93 as discussed i=
n the thread
> =E2=80=9COAuth 2.0 Discovery Location=E2=80=9D.  I=E2=80=99m also open to=
 introducing the =E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D
> identifier, as discussed in that thread.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tschofenig 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> Hi,
>
>
>
> I sent a few comments two weeks ago that has not been explicitly commente=
d
> on. (I might have sent them in the wrong way, if so sorry about that)
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w
>
>
>
> Most of the comments are minor but I would like to se
>
> jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
>
> and at least get a comment of the difference
> between response_types_supported and grant_types_supported
>
>
>
> Best regards
>
> //Samuel
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specificatio=
n:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> 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
>

--001a114035fee6e916052db06f2d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I agree with Samuel's comments wrt jwks_uri and=C2=A0r=
egistration_endpoint; and support the name change to =E2=80=9COAuth 2.0 Aut=
horization Server Discovery Metadata=E2=80=9D (or possibly =E2=80=9COAuth 2=
.0 Authorization Server Discovery=E2=80=9D; but I'd rather narrow down =
the scope to only talk about metadata, without discovery mechanism of that =
metadata; I won't fight for that though, it's just a preference, no=
t a strong opinion)

On=
 Thu, Mar 10, 2016 at 12:33 PM Mike Jones <Michael.Jones@microsoft.com> wrote:











Thanks for your comments, Samuel.=C2=
=A0 Yes, you=E2=80=99re right that jwks_uri should be OPTIONAL, since not a=
ll use cases need keys.=C2=A0 Likewise, registration_endpoint should
 be OPTIONAL, rather than RECOMMENDED.


=C2=A0


The grant_type values are defined in =
OAuth Dynamic Client Registration [RFC 7591] and are identifiers for the gr=
ant type concept defined in RFC 6749.=C2=A0 They identify
 the grant types that can be used at the Token Endpoint.=C2=A0 The response=
_type concept is defined in RFC 6749, and identifies a response syntax from=
 the authorization endpoint.=C2=A0 We can say more to differentiate these i=
n the next draft.


=C2=A0


BTW, lest it be in doubt, I support t=
his draft moving forward, with the name changed to =E2=80=9COAuth 2.0 Autho=
rization Server Discovery=E2=80=9D or =E2=80=9COAuth 2.0 Authorization
 Server Discovery Metadata=E2=80=9D =E2=80=93 as discussed in the thread =
=E2=80=9COAuth 2.0 Discovery Location=E2=80=9D.=C2=A0 I=E2=80=99m also open=
 to introducing the
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D 
identifier, as discussed in that thread.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 -- Mike


=C2=A0



From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Samuel Erdtman

Sent: Wednesday, March 9, 2016 11:28 PM

To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discove=
ry


=C2=A0




Hi,




=C2=A0






I sent a few comments two weeks ago that has not bee=
n explicitly commented on. (I might have sent them in the wrong way, if so =
sorry about that)=C2=A0






=C2=A0







=C2=A0






Most of the comments are minor but I would like to s=
e=C2=A0






jwks_uri to be changed from=C2=A0REQUIRED=C2=A0to OPTIONAL or=C2=A0RECOMMENDED






and at =
least get a comment of the difference between=C2=A0response_types_supported=
 and grant_types_supported






=C2=A0






Best re=
gards






//Samue=
l






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig &=
lt;hannes.ts=
chofenig@gmx.net> wrote:




Hi all,



This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery specifica=
tion:

https://tools.ietf.org/html/draft-ietf-oauth-discovery-01<=
br>


Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek





_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a114035fee6e916052db06f2d--


From nobody Thu Mar 10 03:54:31 2016
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 28CE112D6A8 for ; Thu, 10 Mar 2016 03:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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] 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 ueVqb_mYBWm7 for ; Thu, 10 Mar 2016 03:54:27 -0800 (PST)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 7EC6412D668 for ; Thu, 10 Mar 2016 03:54:27 -0800 (PST)
Received: by mail-vk0-x232.google.com with SMTP id k1so92244748vkb.0 for ; Thu, 10 Mar 2016 03:54:27 -0800 (PST)
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:date:message-id:subject:from:to :cc; bh=+V7mlAkRTb6gM4mhcKK7yq/1QxidMrQG/Z4Zz37ODyw=; b=VRr3YNUx1uTUz6Xs+pVyIJJ0kyZYHOupiR+RaSv9pMgI9rsaSbhAVkgLW0MAITOrBi Aghjj1F9GjyFVz+fveqobjBFAkXBQ7HEultLyThqYviMaDiz9jQB83miwmHpL0yK+t/2 Iqjxd9ai100D6b+bHkkwmcNpI8YTMfoa8RxpK1az8ZYMzH3WeoFtMK7UFpA6WOV7DqLD g1jiQBHzi9+S/aJ9pdyizzwFqmE/6pXQ8UTB6qAxed0oTv5A5GUfKmwKPf+vpwHZxx07 ASFXrVNxtEdgO/VKz5cY0WHdK+p/OgU8WkG8Lld/nIRFKl1tk23Un+Vb6CNf7GjZyV/O I8FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+V7mlAkRTb6gM4mhcKK7yq/1QxidMrQG/Z4Zz37ODyw=; b=L53KzKC2BulMSrF4tichL56PrIalFcamgI53wBqzAQryiTyZsk9YyXUX+yVKroJ1ia KQ2QfA7wbbF2W2UiufVfPs+TyGn2xggttPZTXO8OtWh6VCuerRp7H4teDSGq3n0LOp9E dCmelVc43ZD6/GzZ/KGj2HWebctE4dQqDb+mgLV3sQCMaI1Vsd/ydYp6SIzZotc12SKq fW2g+ah56VDSmeOKXPw9iz9TvNUK0Bn1/hB5Hj37mhoPb6gHh1UACTdmS1iEllwJXUxx qEPIf1LHuBYpzHIEx9E0QmVbgGjsEXv3Q3c6GbEM560uJb4IJBTSFYitPqA14Ez3LaKb Rvsg==
X-Gm-Message-State: AD7BkJJVAeW2Fvk/c4wa2s/R4cVTRSo6vnmOiQh0pjtxVQiz0ZdxHCryj5xployWZjCOUrShO1Pek+K9EycTJQ==
MIME-Version: 1.0
X-Received: by 10.31.52.134 with SMTP id b128mr3110986vka.124.1457610866442; Thu, 10 Mar 2016 03:54:26 -0800 (PST)
Received: by 10.159.37.42 with HTTP; Thu, 10 Mar 2016 03:54:26 -0800 (PST)
In-Reply-To: 
References: <56C5C9D5.6040703@gmx.net>  
Date: Thu, 10 Mar 2016 12:54:26 +0100
Message-ID: 
From: Samuel Erdtman 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a114402beea5878052db0794a
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 11:54:30 -0000

--001a114402beea5878052db0794a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Mike!

Then lets take it to the next level :)

//Samuel

On Thu, Mar 10, 2016 at 12:33 PM, Mike Jones 
wrote:

> Thanks for your comments, Samuel.  Yes, you=E2=80=99re right that jwks_ur=
i should
> be OPTIONAL, since not all use cases need keys.  Likewise,
> registration_endpoint should be OPTIONAL, rather than RECOMMENDED.
>
>
>
> The grant_type values are defined in OAuth Dynamic Client Registration
> [RFC 7591] and are identifiers for the grant type concept defined in RFC
> 6749.  They identify the grant types that can be used at the Token
> Endpoint.  The response_type concept is defined in RFC 6749, and identifi=
es
> a response syntax from the authorization endpoint.  We can say more to
> differentiate these in the next draft.
>
>
>
> BTW, lest it be in doubt, I support this draft moving forward, with the
> name changed to =E2=80=9COAuth 2.0 Authorization Server Discovery=E2=80=
=9D or =E2=80=9COAuth 2.0
> Authorization Server Discovery Metadata=E2=80=9D =E2=80=93 as discussed i=
n the thread
> =E2=80=9COAuth 2.0 Discovery Location=E2=80=9D.  I=E2=80=99m also open to=
 introducing the =E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D
> identifier, as discussed in that thread.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tschofenig 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> Hi,
>
>
>
> I sent a few comments two weeks ago that has not been explicitly commente=
d
> on. (I might have sent them in the wrong way, if so sorry about that)
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w
>
>
>
> Most of the comments are minor but I would like to se
>
> jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
>
> and at least get a comment of the difference
> between response_types_supported and grant_types_supported
>
>
>
> Best regards
>
> //Samuel
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specificatio=
n:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--001a114402beea5878052db0794a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Mike!

Then lets take it to the n=
ext level :)

//Samuel

On Thu, Mar 10, 2016 at 12:33 PM, =
Mike Jones <Michael.Jones@microsoft.com> wrote:











Thanks for your comments, Samuel.=C2=
=A0 Yes, you=E2=80=99re right that jwks_uri should be OPTIONAL, since not a=
ll use cases need keys.=C2=A0 Likewise, registration_endpoint should
 be OPTIONAL, rather than RECOMMENDED.


=C2=A0


The grant_type values are defined in =
OAuth Dynamic Client Registration [RFC 7591] and are identifiers for the gr=
ant type concept defined in RFC 6749.=C2=A0 They identify
 the grant types that can be used at the Token Endpoint.=C2=A0 The response=
_type concept is defined in RFC 6749, and identifies a response syntax from=
 the authorization endpoint.=C2=A0 We can say more to differentiate these i=
n the next draft.


=C2=A0


BTW, lest it be in doubt, I support t=
his draft moving forward, with the name changed to =E2=80=9COAuth 2.0 Autho=
rization Server Discovery=E2=80=9D or =E2=80=9COAuth 2.0 Authorization
 Server Discovery Metadata=E2=80=9D =E2=80=93 as discussed in the thread =
=E2=80=9COAuth 2.0 Discovery Location=E2=80=9D.=C2=A0 I=E2=80=99m also open=
 to introducing the
=E2=80=9C/.well-known/oauth-authorization-server=E2=80=9D 
identifier, as discussed in that thread.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 -- Mike


=C2=A0



From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Samuel Erdtman

Sent: Wednesday, March 9, 2016 11:28 PM

To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discove=
ry


=C2=A0




Hi,




=C2=A0






I sent a few comments two weeks ago that has not bee=
n explicitly commented on. (I might have sent them in the wrong way, if so =
sorry about that)=C2=A0






=C2=A0







=C2=A0






Most of the comments are minor but I would like to s=
e=C2=A0






jwks_uri to be changed from=C2=A0REQUIRED=C2=A0to OPTIONAL or=C2=A0RECOMMENDED






and at =
least get a comment of the difference between=C2=A0response_types_supported=
 and grant_types_supported






=C2=A0






Best re=
gards






//Samue=
l






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig &=
lt;hannes.ts=
chofenig@gmx.net> wrote:




Hi all,



This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery specifica=
tion:

https://tools.ietf.org/html/draft-ietf-oauth-discovery-01<=
br>


Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek





_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0












--001a114402beea5878052db0794a--


From nobody Thu Mar 10 05:05:49 2016
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 CDFA412D71A for ; Thu, 10 Mar 2016 05:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 1ap3dm-DrSyZ for ; Thu, 10 Mar 2016 05:05:44 -0800 (PST)
Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id B417F12D520 for ; Thu, 10 Mar 2016 05:05:41 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.22,559,1449529200";  d="asc'?scan'208";a="89288356"
X-IPAS-Result: A2CoBADeb+FW/84N74JeGQEBAQESAQGCYn1tBrxJBQUXCoVuAoIHAQEBAQEBZSeEQgEBAQIBAQEBGgZLCwULAgEIQgICJwslAgQOBQ6IAQMKCAENrgyPJgEBAQEBAQEDAQEBAQEBAQEQBASGGIFzgk+CPYFlgxgrgQ8FjTOKCYFOgUqBZW2JcoRHiFSOamKDZGqIVQF9AQEB
Received: from umu-ex06.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.206]) by smtp5.umu.se with ESMTP; 10 Mar 2016 14:04:28 +0100
Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX06.ad.umu.se (2002:82ef:dce::82ef:dce) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 10 Mar 2016 14:04:28 +0100
Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Thu, 10 Mar 2016 14:04:28 +0100
From: Roland Hedberg 
To: Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRes1gaW6XIA1+zU6W/8nt5o9Vug==
Date: Thu, 10 Mar 2016 13:04:28 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>
In-Reply-To: <56C5C9D5.6040703@gmx.net>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-pgp-agent: GPGMail 2.5.2
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.239.200.165]
Content-Type: multipart/signed; boundary="Apple-Mail=_89EE4FD9-D452-4757-A295-6238C2F74C3D"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 13:05:47 -0000

--Apple-Mail=_89EE4FD9-D452-4757-A295-6238C2F74C3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I support this document being moved forward with these two changes:

- change name to =E2=80=9COAuth 2.0 Authorization Server Discovery =
Metadata=E2=80=9D as proposed by Brian and
- use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 =
instead of =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.

> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig =
:
>=20
> Hi all,
>=20
> This is a Last Call for comments on the  OAuth 2.0 Discovery =
specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>=20
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>=20
> Please have your comments in no later than March 10th.
>=20
> Ciao
> Hannes & Derek
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

=E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


--Apple-Mail=_89EE4FD9-D452-4757-A295-6238C2F74C3D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJW4XDbAAoJEMHjX+0KUIOoCxUP/jtmltnWRAjzcrcSxCBXABWl
aRs1OWQB4whDryg96s9qNUto3C+lBdgp1MqTZvH2UjiO9gRfR12seRiztWMqvkYO
MK0YOYeiMHcwsZL4SnNGMjs4jRlx2Ch3ElEBlk44AyvjCDVz4xHka9I4MTyeySx7
H7jdPUgHx2M40S5BNyx5aJmhcRR4s9poIS6Anifc2CUxpJHf0mjx3cxOgc9qaG8g
XdD/WMUt9ZdEK/LnHaarxvA1mKxrwg4fqOKcegD5BR1zwI/0/otpzxQgbUuA8l77
u1IIk9J150u3hw4WEO3/4zev9IDxwxi9ed2ePo9LCh+yQsTADkN+1U3Uf3OhhtY7
A3vtC85x6EpRQymxzPVXieqBnbrbLXhIKiAEzDvZ34QRE6EOap6doE9xgmf9yQhb
l4i3uWYSzfbY77VPjU2s6bc58ocl+IUA8l8x5XJf/3aeJ+C46fUWo3ChGxZMYQxv
uJWaUUMnz3wHEHCeZYDC9ac416FhxL9lJ6HNROxTLW5ZjvgQONekhf7KkzRUbSGR
7QM+vz6YxMkoCExQgMgB0Y5Og5O1hryGRz8YoFSb13HRGVIVwrAGD9vPKmk5bl+b
jfbHfGoRHVgP1WiESrCG2UdR0dTjznpzdttprnFpMtSUQX6bwu9HI7Es0z/bjnrR
EY0sSnR/4hAp+ap9G3Lp
=hDEg
-----END PGP SIGNATURE-----

--Apple-Mail=_89EE4FD9-D452-4757-A295-6238C2F74C3D--


From nobody Thu Mar 10 07:36:39 2016
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 9608C12D8EC for ; Thu, 10 Mar 2016 07:36:37 -0800 (PST)
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=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 xlGUlHMJpKBS for ; Thu, 10 Mar 2016 07:36:34 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 DB46312D8DE for ; Thu, 10 Mar 2016 07:36:02 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id z76so110169962iof.3 for ; Thu, 10 Mar 2016 07:36:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M/N/+f66Fay3+RTOPIf4efte6pYgzoa6zcrPFIMFz4k=; b=pleHL0dl/BM6ALW4oYxmBJGBLV18/Yi116v1RJSubcTguSpZmw0MXCcvEItJNlU0F2 GL3Z7XVHMKNbETOP6zAEJD+lgMYQOW/0Nt1hY25E/ac0JwoUpYIIhbzEk1VBPdF4zo1P krTr0E5rJnzDgp3C2LlI3rMbSL7w07BwUeKqc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M/N/+f66Fay3+RTOPIf4efte6pYgzoa6zcrPFIMFz4k=; b=MvuMa3NyNy+DvvWjl9cWlIXEeKBHNOCADRaMoZtfqIqdyhjV3t+iYAho3+8EwwNYUp unxEuZGPb+X6e5gz9tks0bxaDd3OqrEOxLPPRjgAbWw3009SLW4PaE6YqDo0HKUmEA4D FNcPjjtBhYG11LFC77mAqohgTXbwFa6QPKurpfa3cJrJrKgTkGz8OJoZHpxwgKVmzodA OiRum9j9KWjj9Vengkw6+nDuBvEZTzikKfaRGT5+wwwObhF0d7pAOOP3aUXqjj54EOR5 tekirVzvzbtlAR/wnjhbF41eWHqDe0/MuwF8pWDaIZLrT23sZI9jehJ2XhF25mJkF8FS wUdA==
X-Gm-Message-State: AD7BkJLG6RpX89mI0rlOfAxwAekIbXmhqTV9iKeJucnlebd6KdCdws4AzpeYn8E3cfYasGOAjt9Vti9IN2ojestm
X-Received: by 10.107.132.18 with SMTP id g18mr4738326iod.48.1457624162193; Thu, 10 Mar 2016 07:36:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.152.130 with HTTP; Thu, 10 Mar 2016 07:35:32 -0800 (PST)
In-Reply-To: 
References: <56C5C9D5.6040703@gmx.net> 
From: Brian Campbell 
Date: Thu, 10 Mar 2016 08:35:32 -0700
Message-ID: 
To: Roland Hedberg 
Content-Type: multipart/alternative; boundary=001a113ecbe467703c052db392e9
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 15:36:37 -0000

--001a113ecbe467703c052db392e9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
wrote:

> I support this document being moved forward with these two changes:
>
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
> proposed by Brian and
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>
> > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  >:
> >
> > Hi all,
> >
> > This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> >
> > Since this document was only adopted recently we are running this last
> > call for **3 weeks**.
> >
> > Please have your comments in no later than March 10th.
> >
> > Ciao
> > Hannes & Derek
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> =E2=80=94 Roland
>
> =E2=80=9DEverybody should be quiet near a little stream and listen."
> From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a113ecbe467703c052db392e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.he=
dberg@umu.se> wrote:
I supp=
ort this document being moved forward with these two changes:



- change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=
=E2=80=9D as proposed by Brian and

- use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 inst=
ead of =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.




> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net>:

>

> Hi all,

>

> This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery spec=
ification:

> https://tools.ietf.org/html/draft-ietf=
-oauth-discovery-01

>

> Since this document was only adopted recently we are running this last=


> call for **3 weeks**.

>

> Please have your comments in no later than March 10th.

>

> Ciao

> Hannes & Derek

>


> _________________________________________=
______

> OAuth mailing list

> OAuth@ietf.org

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



=E2=80=94 Roland



=E2=80=9DEverybody should be quiet near a little stream and listen."
>From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a113ecbe467703c052db392e9--


From nobody Thu Mar 10 07:45:36 2016
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 2936412D8E9 for ; Thu, 10 Mar 2016 07:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 UmrqUBSFrw6t for ; Thu, 10 Mar 2016 07:45:33 -0800 (PST)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 3138D12D859 for ; Thu, 10 Mar 2016 07:45:33 -0800 (PST)
Received: by mail-qg0-x22b.google.com with SMTP id u110so73612344qge.3 for ; Thu, 10 Mar 2016 07:45:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lAsXpNr37iibC1XxOt6UkWXmGZv7aYiXNtUBRhg0FHc=; b=k1tbO7JRkQ3+Od1N9RQYRs0WvAjpMOjTMMo8b/+/qoJyBzxqJHlQHCcqKTcd3JTtwy eYgD+LRnXjkEC3hGZ3dtAienRCRvq0RZ00XxQvTeNABBddEH+NU3iX9i6ljSXNB1lWdN yKsnlIz3bVgj6qcbr+byrDYQlRtaZAeaoduHEOj3xM5Uxs9JmMlJsH9ZJhqHCSP1sCwf rHz3a+dIgamKDnpgElGG1zf9WQC/TYI/NfjpKDHaXxOHS6B+2M6jO8g1e42iSZdkeFW6 Htq1Q8D8+Z66wsXSquJk2U4I1Pokg22sBcutdf8KMYxL6AY2bVq2juiCUB/7O4S9qWvs pcvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lAsXpNr37iibC1XxOt6UkWXmGZv7aYiXNtUBRhg0FHc=; b=IIlg3oEbg/V8UOkhAgeRW9JI3y8Sf8QzEwbTKOg8mSrb3YK5VtvhZ7RhqmwQd7YcMI SZctEy8KVeNuRA8Hupm/N8ekzaelXg+IzTEgBk4R9kTtTFAGCWBUrThgG+Xh8VCm5hEa G9IicEe6D2zRW+oX0zTh0wXoerOC2q6QMbjJeCWUilbJvOWrBqYsIZ5SfWQMISLzM9N7 wBnkn7Jo9aqm3I8oIDWJx7hl7vO2RuHMiCB95GAQq4mAjzUPJ9ORB41oflOiHj01/DRc AsB5jNh/4O4gmiAbi04aMUOoenzAgnM6MAkC985WFcMz6jH6J14BnOL6rrp0pbNzxFet iB2Q==
X-Gm-Message-State: AD7BkJKyJ9RssSPwBgwnxJB+2HihLBwApH0wGEXs3ynnGdPs/AUPsr2pHWxzRVZCWOhdLSi5EY6Kw8A7lGX9VA==
X-Received: by 10.140.101.238 with SMTP id u101mr5012800qge.33.1457624732210;  Thu, 10 Mar 2016 07:45:32 -0800 (PST)
MIME-Version: 1.0
References: <56C5C9D5.6040703@gmx.net> 
In-Reply-To: 
From: Nat Sakimura 
Date: Thu, 10 Mar 2016 15:45:22 +0000
Message-ID: 
To: Roland Hedberg , Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a11c1678e611ee0052db3b4bc
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 15:45:35 -0000

--001a11c1678e611ee0052db3b4bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 in proceeding with the following changes:

   1. Change name to "*OAuth 2.0 Authorization Server Metadata*", aligning
   with section 2.
   2. Have the AS dictate the URI path suffix through link header in the
   HEAD response to AS or OOB mechanism.
   3. Align the title of section 3 to section 2 so that it will be "Obtaini=
ng
   Authorization Server Metadata"
   4. Align the title of section 3.1 to section 2 so that it will be
"Authorization
   Server Metadata Request"
   5. Align the title of section 3.2 to section 2 so that it will be
"Authorization
   Server Metadata Response"
   6. Align the title of section 3.3 to section 2 so that it will be
"Authorization
   Server Metadata Validation"
   7. Align the title of section 7.1 to section 2 so that it will be "*OAut=
h
   Authorization Server Metadata Registry*"
   8. Change all the occurrence of "authorization server discovery
   metadata" to "authorization server metadata".
   9. Change all the occurrence of "discovery metadata" to "authorization
   server metadata" in a not-case-sensitive way but preserving the original
   case.
   10. Change "supporting discovery" to "supporting this specification".
   11. Change abbrev=3D"OAuth 2.0 Discovery" to abbrev=3D"OAuth 2.0 AS Meta=
data"

Best,

Nat Sakimura

2016=E5=B9=B43=E6=9C=8810=E6=97=A5(=E6=9C=A8) 22:05 Roland Hedberg :

> I support this document being moved forward with these two changes:
>
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
> proposed by Brian and
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>
> > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  >:
> >
> > Hi all,
> >
> > This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> >
> > Since this document was only adopted recently we are running this last
> > call for **3 weeks**.
> >
> > Please have your comments in no later than March 10th.
> >
> > Ciao
> > Hannes & Derek
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> =E2=80=94 Roland
>
> =E2=80=9DEverybody should be quiet near a little stream and listen."
> From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a11c1678e611ee0052db3b4bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 in proceeding with the following changes:=C2=A0
  • Change name to "OAuth 2.0 Auth=
orization Server Metadata", aligning with section 2.=C2=A0<=
br>
  • Have the AS dictate the URI pat=
h suffix through link header in the HEAD response to AS or OOB mechanism.=
=C2=A0
  • Align the title o=
f section 3 to section 2 so that it will be "Obtaining Authorizat=
ion Server Metadata"
    =

  • Align the title of section 3.1 to section 2 so that it will be "<=
span style=3D"font-size:1em;line-height:0pt;font-weight:bold;color:rgb(0,0,=
0)">Authorization Server Metadata Request"
  • Align the=
 title of section 3.2 to section 2 so that it will be "Authorizat=
ion Server Metadata Response"
  • Align the title of section 3.3 to section 2 so that it wil=
l be "Authorization Server Metada=
ta Validation"
  • A=
lign the title of section 7.1 to section 2 so that it will be "OAut=
h Authorization Server Metadata Registry"
  • Change all the occurrence of "authorization server dis=
covery metadata" to "authorization server metadata".=C2=A0
  • Change all the=C2=A0oc=
currence of "discovery metadata" to "authorization server me=
tadata" in a not-case-sensitive way but preserving the original case.=
=C2=A0
  • Change "supporting discovery" to "supporting =
this specification".=C2=A0
  • Cha=
nge abbrev=3D"OAuth 2.0 Discovery" to abbrev=3D"OAuth 2.0 AS=
 Metadata"
    • Best,=C2=A0

    =

    Nat Sakimura

    2016=E5=B9=B43=E6=9C=8810=E6=97=A5(=E6=9C=A8) 22:05 Roland Hedberg <roland.hedberg@umu.se>:
    I support this document being moved forw=
ard with these two changes:
    

    
- change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=
=E2=80=9D as proposed by Brian and
    
- use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 inst=
ead of =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
    

    
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net>=
;:
    
>
    
> Hi all,
    
>
    
> This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery spec=
ification:
    
> https://tools.ietf.org/html/draft-ietf=
-oauth-discovery-01
    
>
    
> Since this document was only adopted recently we are running this last=

    
> call for **3 weeks**.
    
>
    
> Please have your comments in no later than March 10th.
    
>
    
> Ciao
    
> Hannes & Derek
    
>
    
> _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org=

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

    
=E2=80=94 Roland
    

    
=E2=80=9DEverybody should be quiet near a little stream and listen."
>From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
    

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

    

--001a11c1678e611ee0052db3b4bc--


From nobody Thu Mar 10 08:06:20 2016
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 5C84F12D995 for ; Thu, 10 Mar 2016 08:06:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level: 
X-Spam-Status: No, score=-1.919 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] 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 N9Lgj158xPgz for ; Thu, 10 Mar 2016 08:06:17 -0800 (PST)
Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EC412D982 for ; Thu, 10 Mar 2016 08:06:07 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa06-10.prod.phx3.secureserver.net with  id UG651s00K15ZTut01G66tx; Thu, 10 Mar 2016 09:06:07 -0700
To: oauth@ietf.org
References: <56C5C9D5.6040703@gmx.net>  
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <56E19B6D.6060509@connect2id.com>
Date: Thu, 10 Mar 2016 18:06:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050801040100020302010508"
Archived-At: 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 16:06:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms050801040100020302010508
Content-Type: multipart/alternative;
 boundary="------------000902000706000207060404"

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

+1 to move forward with these

On 10/03/16 17:35, Brian Campbell wrote:
> +1
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg =

> wrote:
>
>> I support this document being moved forward with these two changes:
>>
>> - change name to =93OAuth 2.0 Authorization Server Discovery Metadata=94=
 as
>> proposed by Brian and
>> - use the URI path suffix =92oauth-authorization-server=92 instead of
>> =92openid-configuration=92 as proposed by Justin.
>>
>>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig >> :
>>>
>>> Hi all,
>>>
>>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>> specification:
>>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>>
>>> Since this document was only adopted recently we are running this las=
t
>>> call for **3 weeks**.
>>>
>>> Please have your comments in no later than March 10th.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> =97 Roland
>>
>> =94Everybody should be quiet near a little stream and listen."
>> From =92Open House for Butterflies=92 by Ruth Krauss
>>
>>
>> _______________________________________________
>> 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

--------------000902000706000207060404
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    +1 to move forward with these
    
    
    
    
    On 10/03/16 17:35, Brian Campbell
      wrote:
    
    
    
    
    
      
    +1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se=
>
wrote:


    
      
    
        
    I support this document being moved forward with t=
hese two changes:

- change name to =93OAuth 2.0 Authorization Server Discovery Metadata=94 =
as
proposed by Brian and
- use the URI path suffix =92oauth-authorization-server=92 instead of
=92openid-configuration=92 as proposed by Justin.


    
        
    
          
    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig &l=
t;hannes.tschofenig@gmx.net
:

Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery

    
        
    
        
    specification:

    
        
    
          
    https://tools.ietf.=
org/html/draft-ietf-oauth-discovery-01

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek

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

    
        
    
        
    =97 Roland

=94Everybody should be quiet near a little stream and listen."
=46rom =92Open House for Butterflies=92 by Ruth Krauss


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



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

    
    
    
  


--------------000902000706000207060404--

--------------ms050801040100020302010508
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
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAzMTAxNjA2MDVaMC8GCSqGSIb3DQEJBDEiBCBIXZCc+rIZRS3DeOjScGZmeIBCnIDK
Xl3Lg55qePuUOzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCLJwmjGFjK
muMmhjEBTEe1oDUXxOX/RRYd0t/9KNNqLJ8g654arqxtkjz4e9bhl+Pta29Nf0pY2yWMmt6g
pYYYLBN8HnvpQINJGi46a21NudJ66hVxD0C2wd5o1yn4mFyONNpQ16AAtTxPcfJpmnYNT81W
jXNtZDHFBNTao5q8Fh2li3MH/Rs3AaGDuyYFsAtFgAvgCd2Cxaj1GNzEQc5S/TUsHgfJMn6z
23Jo1sogh3TkR8XiH0qs6mTNEq64Nka0nz2592XeSQxqOcGqbJcMwGmcAHOz7jDY071pivIs
9jXoDhM+ZvDqrUiAo2yAhDngLhJCAe7VfY8H+pkk314IAAAAAAAA
--------------ms050801040100020302010508--


From nobody Thu Mar 10 09:07:15 2016
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 3574C12DAD7 for ; Thu, 10 Mar 2016 09:07:13 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 BCCVphtDlu52 for ; Thu, 10 Mar 2016 09:07:11 -0800 (PST)
Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 591EC12D75E for ; Thu, 10 Mar 2016 09:02:22 -0800 (PST)
Received: by mail-ob0-x22f.google.com with SMTP id ts10so87053279obc.1 for ; Thu, 10 Mar 2016 09:02:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a7UUj4Ig4ihli7TmXg0hoN0+XC4uyIRToXi+xiQ26eE=; b=ZT7sZ6SdunEZd4RgDcCubPtRngmHH2to2SltDNJIK4G7/g72sVMzS6oTwj4AmqRflC ZAVwQmsIqiROgE33XLcnSGHB9zI9FjSlIwACtXFvILCSSi6cJ1SsAj0EyXNzAC97wQct uvL4RkCIkAKFKivty8gKyMfeeg2rwgLncP8l8nzu4VGHd3y4BDtt778FFQ77pao3UpL7 /XscyuGa3njCHFT2pwr/dAdZaSqJ9VURaZ+DjdtJA89ZTJtRpYPZ5Dm6Ns9ZrTJxyRDy tBnpA04QYfGBp0IR0HEMYu9XyGbAZ3y7K4dPePasPku0RJ5PPRta49cjZMzceuVtQPZY 5WCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a7UUj4Ig4ihli7TmXg0hoN0+XC4uyIRToXi+xiQ26eE=; b=cHTHfP6wunaIEqIp/rDynaEAtgDAcL0mox0KAJ/rhhIUCUmjKdNacjguy96QBi/lx2 zLvxPeQDkaMJVVRCwfhKQJOWaPmK994AEJzIeypuaukvZzo7RvTBhE7hfGalH4mQ3CIg 3+wYOA4tFnEBL0h3x+zg9/hkj5PJIcgjhOyPsFC7u5vpO+6Tgf7ocOsQldZFue99SYaB b2UN9VmBdOLRTdVt+9KZAg4fe50Y/Et1AMUsQV8FEVr+7sO8AcNtJXaj1QzLiPR58NLv dlS7ZqnEQSas80B/OqTPFxN13CoW59OctjP2P5Gyia2Wnz2LJWMBOlVY6YDBIgG12JGh bmvQ==
X-Gm-Message-State: AD7BkJKJeZFBdjHE1aqSX6wJVfIPh7Hlp27LP7CyZ8Rtevvp75k1DG/ApF7WE5ZCc8vC8ZTccv52LNc+naCMHHBn
X-Received: by 10.182.247.67 with SMTP id yc3mr2667166obc.57.1457629341683; Thu, 10 Mar 2016 09:02:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.79.233 with HTTP; Thu, 10 Mar 2016 09:02:02 -0800 (PST)
In-Reply-To: 
References: <56C5C9D5.6040703@gmx.net> 
From: William Denniss 
Date: Thu, 10 Mar 2016 09:02:02 -0800
Message-ID: 
To: Roland Hedberg 
Content-Type: multipart/alternative; boundary=089e0158b2542056e3052db4c764
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 17:07:13 -0000

--089e0158b2542056e3052db4c764
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I support the document moving forward, and agree with the proposal to
rename it to "OAuth 2.0 Authorization Server Discovery Metadata".

Personally I was fine with re-using 'openid-configuration' for
compatibility, but I suppose it's not a big burden for everyone who is
already using that to setup an alias, as long as the AS metadata and OIDC
discovery specs remain compatible which I expect they will.

On Thu, Mar 10, 2016 at 5:04 AM, Roland Hedberg 
wrote:

> I support this document being moved forward with these two changes:
>
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
> proposed by Brian and
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>
> > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  >:
> >
> > Hi all,
> >
> > This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> >
> > Since this document was only adopted recently we are running this last
> > call for **3 weeks**.
> >
> > Please have your comments in no later than March 10th.
> >
> > Ciao
> > Hannes & Derek
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> =E2=80=94 Roland
>
> =E2=80=9DEverybody should be quiet near a little stream and listen."
> From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--089e0158b2542056e3052db4c764
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I support the document moving forward, and agree with the =
proposal to rename it to "OAuth 2.0 Authorization Server Discovery Met=
adata".

    Personally I was fine with re-using 'op=
enid-configuration' for compatibility, but I suppose it's not a big=
 burden for everyone who is already using that to setup an alias, as long a=
s the AS metadata and OIDC discovery specs remain compatible which I expect=
 they will.

    On=
 Thu, Mar 10, 2016 at 5:04 AM, Roland Hedberg <roland.hedberg@umu.se> wrote:
    I support this document being move=
d forward with these two changes:
    

    
- change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=
=E2=80=9D as proposed by Brian and
    
- use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 inst=
ead of =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
    


    
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <    hannes.tschofenig@gmx.net>=
;:
    
>
    
> Hi all,
    
>
    
> This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery spec=
ification:
    
> https://tools.ietf.org/html/draft-ietf=
-oauth-discovery-01
    
>
    
> Since this document was only adopted recently we are running this last=

    
> call for **3 weeks**.
    
>
    
> Please have your comments in no later than March 10th.
    
>
    
> Ciao
    
> Hannes & Derek
    
>
    

    > _______________________________________________
    
> OAuth mailing list
    
> OAuth@ietf.org=

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

    
    =E2=80=94 Roland
    

    
=E2=80=9DEverybody should be quiet near a little stream and listen."
>From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
    

    

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


    

--089e0158b2542056e3052db4c764--


From nobody Thu Mar 10 09:12:56 2016
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 DB4E912DB5C for ; Thu, 10 Mar 2016 09:12:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 D9CdW9FnrOK0 for ; Thu, 10 Mar 2016 09:12:53 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 A87B012DB0A for ; Thu, 10 Mar 2016 09:09:24 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2AH9LRu031826 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Mar 2016 17:09:22 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2AH9LsE011396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Mar 2016 17:09:21 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2AH9KnM006691; Thu, 10 Mar 2016 17:09:20 GMT
Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Mar 2016 09:09:20 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-EE9219B2-D9C6-4310-B9C8-8AEB82F817AA
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: <56E19B6D.6060509@connect2id.com>
Date: Thu, 10 Mar 2016 09:09:18 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com>
To: Vladimir Dzhuvinov 
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Mar 2016 17:12:56 -0000

--Apple-Mail-EE9219B2-D9C6-4310-B9C8-8AEB82F817AA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I strongly oppose. 2 major issues.=20

This is not service discovery this is configuration lookup. The client must h=
ave already discovered the oauth issuer uri and the resource uri.=20

The objective was to provide a method to ensure the client has a valid set o=
f endpoints to prevent mitm of endpoints like the token endpoint to the reso=
urce server.=20

The draft does not address the issue of a client being given a bad endpoint f=
or an rs. What we end up with is a promiscuous authz service giving out toke=
ns to an unwitting client.=20

Phil

> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  wr=
ote:
>=20
> +1 to move forward with these
>=20
>> On 10/03/16 17:35, Brian Campbell wrote:
>> +1
>>=20
>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
>> wrote:
>>=20
>>> I support this document being moved forward with these two changes:
>>>=20
>>> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metad=
ata=E2=80=9D as
>>> proposed by Brian and
>>> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 i=
nstead of
>>> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>>>=20
>>>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig >>> :
>>>>=20
>>>> Hi all,
>>>>=20
>>>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>>> specification:
>>>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>>>=20
>>>> Since this document was only adopted recently we are running this last
>>>> call for **3 weeks**.
>>>>=20
>>>> Please have your comments in no later than March 10th.
>>>>=20
>>>> Ciao
>>>> Hannes & Derek
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> =E2=80=94 Roland
>>>=20
>>> =E2=80=9DEverybody should be quiet near a little stream and listen."
>>> =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-EE9219B2-D9C6-4310-B9C8-8AEB82F817AA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    I strongly oppose. 2 major issues.&nbs=
p;

    This is not service discovery this is configuration lookup. The client m=
ust have already discovered the oauth issuer uri and the resource uri. =


    The objective was to provide a method to ensure the client has a valid set=
 of endpoints to prevent mitm of endpoints like the token endpoint to the re=
source server. 

    The draft does not address the issue of a client being g=
iven a bad endpoint for an rs. What we end up with is a promiscuous authz se=
rvice giving out tokens to an unwitting client. 

    Phil
    =

    On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

    
 =20
    
 =20
 =20
    +1 to move forward with these
    
    
    
    
    On 10/03/16 17:35, Brian Campbell
      wrote:
    
    
    
    
    
      
    +1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
wrote:


    
      
    
        
    I support this document being moved forward with thes=
e two changes:

- change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=E2=
=80=9D as
proposed by Brian and
- use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 inste=
ad of
=E2=80=99openid-configuration=E2=80=99 as proposed by Justin.


    
        
    
          
    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <<=
a class=3D"moz-txt-link-abbreviated" href=3D"mailto:hannes.tschofenig@gmx.ne=
t">hannes.tschofenig@gmx.net
:

Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery

    
        
    
        
    specification:

    
        
    
          
    https://tools.ietf.org/ht=
ml/draft-ietf-oauth-discovery-01

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek

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

    
        
    
        
    =E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


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



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

    
    
    
 =20


    =

--Apple-Mail-EE9219B2-D9C6-4310-B9C8-8AEB82F817AA--


From nobody Thu Mar 10 18:25:04 2016
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 AA06412DC51 for ; Thu, 10 Mar 2016 18:25:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 j63xzhE1Vyz5 for ; Thu, 10 Mar 2016 18:25:01 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 AC89D12DD49 for ; Thu, 10 Mar 2016 18:25:00 -0800 (PST)
Received: by mail-qg0-x232.google.com with SMTP id t4so87683765qge.0 for ; Thu, 10 Mar 2016 18:25:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tzr2JOinMPzKM9Y6WnelGghsYQlWP4e6pxsslspuHnY=; b=WEbrSbnEjRRCGVX+H11xMclsfOiLbI0TQhuBeKBjZP9q7o1KIeVa6/mLh008TlZytp TXGEFh8arBKlr8fVqF/a2yHYMIWaAJZDREAq1ihNM8vwkE/iqhSMMM2U8Jn8ZEFjtl9w O+e6Haqm1NRZkObRhTygaZVzBecvWOSvf/xH5GmprytNxHSHA43bdmb2PTSa2dRdA90Y XWi4DEJ7YZtRpFqgvzCYSuKvtHRtNGP4KG7gEMbwcqJPjTRPiHPmzQ5MbGBIIwjyYlp0 Oqf91WtRNiBwGve+BzI8mJVP9KETFZIHqkbD5hJCqF4NTHSum9vGBikNsjn5tFK+QkOo eHRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tzr2JOinMPzKM9Y6WnelGghsYQlWP4e6pxsslspuHnY=; b=RSXvad78AUZjUgqxzGY7ZVBohWrtesXB1Vh/tPUOI84HymkcXk07iGmmaJgRPboRTL fOv0xjmTSVPIuVReT12UVPZawDJKYV5HEfwMHQ7a4ZhFV3qrGUfYMdyjwrlh/7xpYPvb RMrz42znRtIv1dJn8siDzBKCAj8YbQVhgC3HWn9nWjdVDjvEjqYh8NOAW7geH9jziyRl 7xuzWIMZOpjh/iI+T5TeaEjkOVXpmbORQo6xocQOLml9AywpT4KhCeDD+oFMjRc840I0 sLKjTgdMMkz6q/h/M8VRXSsyCQy84PRsZRiRe6KnvM647nCKbQMcnXcVu75VKLmB2cdm vhaQ==
X-Gm-Message-State: AD7BkJKhZXn8wkpaJjDilL39mX61TP9thzsEE++fWpTJV4o9eTW4a7MpmM8vM7pp8yW2iabit15WyCgX0enWaw==
MIME-Version: 1.0
X-Received: by 10.140.225.6 with SMTP id v6mr9218183qhb.0.1457663099786; Thu, 10 Mar 2016 18:24:59 -0800 (PST)
Received: by 10.55.24.203 with HTTP; Thu, 10 Mar 2016 18:24:59 -0800 (PST)
In-Reply-To: <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>
Date: Fri, 11 Mar 2016 11:24:59 +0900
Message-ID: 
From: Nat Sakimura 
To: "Phil Hunt (IDM)" 
Content-Type: multipart/alternative; boundary=001a1138f42843e20d052dbca3fb
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 02:25:03 -0000

--001a1138f42843e20d052dbca3fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Phil,

Right. So what my conditional approvals (11 conditions in total) said was
to drop the word "discovery" from everywhere. This is not a discovery spec.
This is a configuration lookup spec as you correctly points out. So, I am
with you here.

Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be able to
express the AS-RS relationships. I have been preaching this in the other
thread for so many times as you know so I thought I pointed it out, but
missed apparently in my previous comment. So, I would add my 12th
condition:

12. A way to express a list of valid RSs for this AS needs to be added to
section 2.

Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :

> I strongly oppose. 2 major issues.
>
> This is not service discovery this is configuration lookup. The client
> must have already discovered the oauth issuer uri and the resource uri.
>
> The objective was to provide a method to ensure the client has a valid se=
t
> of endpoints to prevent mitm of endpoints like the token endpoint to the
> resource server.
>
> The draft does not address the issue of a client being given a bad
> endpoint for an rs. What we end up with is a promiscuous authz service
> giving out tokens to an unwitting client.
>
> Phil
>
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
> wrote:
>
> +1 to move forward with these
>
> On 10/03/16 17:35, Brian Campbell wrote:
>
> +1
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg  <=
roland.hedberg@umu.se>
> wrote:
>
>
> I support this document being moved forward with these two changes:
>
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
> proposed by Brian and
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>
>
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  :
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery
>
> specification:
>
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
> =E2=80=94 Roland
>
> =E2=80=9DEverybody should be quiet near a little stream and listen."
> From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
> _______________________________________________
> 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
>
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--001a1138f42843e20d052dbca3fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Phil,=C2=A0

    Right. So what my condition=
al approvals (11 conditions in total) said was to drop the word "disco=
very" from everywhere. This is not a discovery spec. This is a configu=
ration lookup spec as you correctly points out. So, I am with you here.=C2=
=A0

    Also, my 2nd conditiion is essentially saying =
to drop section 3.=C2=A0

    One thing that I overlook=
ed and am with you is that we need to be able to express the AS-RS relation=
ships. I have been preaching this in the other thread for so many times as =
you know so I thought I pointed it out, but missed apparently in my previou=
s comment. So, I would add my 12th condition:=C2=A0

    12. A way to express a list of valid RSs for this AS needs to be added to=
 section 2.=C2=A0

    Best,=C2=A0

    =

    Nat

    2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com=
>:
    I str=
ongly oppose. 2 major issues.=C2=A0

    This is not se=
rvice discovery this is configuration lookup. The client must have already =
discovered the oauth issuer uri and the resource uri.=C2=A0

    <=
/div>
    The objective was to provide a method to ensure the client has a =
valid set of endpoints to prevent mitm of endpoints like the token endpoint=
 to the resource server.=C2=A0

    The draft does not =
address the issue of a client being given a bad endpoint for an rs. What we=
 end up with is a promiscuous authz service giving out tokens to an unwitti=
ng client.=C2=A0

    Phil=


    On Mar 10, 2016, at 08:=
06, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

    
 =20
   =20
 =20
 =20
    +1 to move forward with these
    
    
    
    
    On 10/03/16 17:35, Brian Campbell
      wrote:
    
    
    
    
    
      
    +1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
wrote:


    
      
    
        
    I support this document being moved forward with these two cha=
nges:

- change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=
=E2=80=9D as
proposed by Brian and
- use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 inst=
ead of
=E2=80=99openid-configuration=E2=80=99 as proposed by Justin.


    
        
    
          
    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.=
net
:

Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery

    
        
    
        
    specification:

    
        
    
          
    https://tools.ietf.org/html/draft-ietf-oauth-di=
scovery-01

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek

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

    
        
    
        
    =E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
>From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


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



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

    
    
    
 =20



    __________________________________=
_____________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    




    -- 
    Nat Sakimura (=3Dnat)
    Chairman, OpenID Foundatio=
n
    http://nat.saki=
mura.org/
    @_nat_en
    

    

--001a1138f42843e20d052dbca3fb--


From nobody Thu Mar 10 19:07:34 2016
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 9C55112DABB for ; Thu, 10 Mar 2016 19:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.013
X-Spam-Level: 
X-Spam-Status: No, score=-0.013 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 brwA0R1zK0AD for ; Thu, 10 Mar 2016 19:07:30 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22CD12DD00 for ; Thu, 10 Mar 2016 19:07:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Osynop77SN0n7OE4pho9pEMcU8n9ifjL8vb3m2mnylw=; b=hovrSp06G0ty6zF4756H11+uRx97M1G5eTrrFAK94HE3oTva+RY6YqUj/zI0fuhePlac0JNtvNJjWYEtueoQH9ww3E5aY1XVbZyWo2JlCwVploXyF3AIq/1xpsl+nW+qCNMzZ0XLsSUfnzS7H+2gxa4LDjgICcL0QpTtWY1Z53o=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 11 Mar 2016 03:07:27 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0427.020; Fri, 11 Mar 2016 03:07:27 +0000
From: Anthony Nadalin 
To: Nat Sakimura , "Phil Hunt (IDM)" 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH06DIAQfC9O0686lpsTuUfK59Sxh0AgAAqNQCAAAiJgIAAEaoAgACbQYCAAAsN0A==
Date: Fri, 11 Mar 2016 03:07:27 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.46.126.7]
x-ms-office365-filtering-correlation-id: c642202f-8703-4114-bc5a-08d3495a4716
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:oo3PvmGG9SgGOiAkaqzIkhuvzsnCQbYYRSmViANJqZv9TZAT1MJM1mdw0MvnnLi2rOh4xSuyJ51Hy2yMcZjN6Vni6uqFT9vu/3aLHctIGhEBx5FL1G9cz72run78lYINMzigbSE6DWasMNLB/RNQXA==; 24:i6mzEUt/QzQJT+eORSrjXmPJ/lZuZuV8gwi7dbMZsGescjEln0oUXrk5VTjD+ckTQDx8U0UG6AGrCPCfblhjeKoqJNf+IjuL2pyCNAwvZx0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 087894CD3C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(479174004)(24454002)(377454003)(377424004)(81166005)(10400500002)(5003600100002)(10290500002)(92566002)(3660700001)(93886004)(3280700002)(5005710100001)(77096005)(2950100001)(2900100001)(3846002)(586003)(1096002)(790700001)(6116002)(1220700001)(102836003)(15975445007)(86612001)(50986999)(4326007)(5002640100001)(19300405004)(10090500001)(5001770100001)(2906002)(189998001)(19609705001)(5008740100001)(86362001)(54356999)(33656002)(66066001)(19580405001)(19617315012)(76176999)(19580395003)(11100500001)(106116001)(99286002)(76576001)(19625215002)(122556002)(87936001)(74316001)(16236675004)(5004730100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234BFC8070FAC8CD5B3135FA6B50BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 03:07:27.5272 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 03:07:32 -0000

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

VGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEFTIGFuZCBSUyBuZWVkIHRvIGJlIHNjb3BlZCB0byDi
gJxkb2VzIHRoaXMgUlMgYWNjZXB0IHRva2VucyBmcm9tIHRoaXMgQVPigJ0gYXMgYSBsaXN0IGlz
IHRvbyBtdWNoIGluZm9ybWF0aW9uIHRoYXQgY291bGQgYmUgdXNlZCBpbiB0aGUgd3Jvbmcgd2F5
DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIE5hdCBTYWtpbXVyYQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2IDY6MjUgUE0N
ClRvOiBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6IG9hdXRoIDxv
YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFz
dCBDYWxsIG9uIE9BdXRoIDIuMCBEaXNjb3ZlcnkNCg0KUGhpbCwNCg0KUmlnaHQuIFNvIHdoYXQg
bXkgY29uZGl0aW9uYWwgYXBwcm92YWxzICgxMSBjb25kaXRpb25zIGluIHRvdGFsKSBzYWlkIHdh
cyB0byBkcm9wIHRoZSB3b3JkICJkaXNjb3ZlcnkiIGZyb20gZXZlcnl3aGVyZS4gVGhpcyBpcyBu
b3QgYSBkaXNjb3Zlcnkgc3BlYy4gVGhpcyBpcyBhIGNvbmZpZ3VyYXRpb24gbG9va3VwIHNwZWMg
YXMgeW91IGNvcnJlY3RseSBwb2ludHMgb3V0LiBTbywgSSBhbSB3aXRoIHlvdSBoZXJlLg0KDQpB
bHNvLCBteSAybmQgY29uZGl0aWlvbiBpcyBlc3NlbnRpYWxseSBzYXlpbmcgdG8gZHJvcCBzZWN0
aW9uIDMuDQoNCk9uZSB0aGluZyB0aGF0IEkgb3Zlcmxvb2tlZCBhbmQgYW0gd2l0aCB5b3UgaXMg
dGhhdCB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gZXhwcmVzcyB0aGUgQVMtUlMgcmVsYXRpb25zaGlw
cy4gSSBoYXZlIGJlZW4gcHJlYWNoaW5nIHRoaXMgaW4gdGhlIG90aGVyIHRocmVhZCBmb3Igc28g
bWFueSB0aW1lcyBhcyB5b3Uga25vdyBzbyBJIHRob3VnaHQgSSBwb2ludGVkIGl0IG91dCwgYnV0
IG1pc3NlZCBhcHBhcmVudGx5IGluIG15IHByZXZpb3VzIGNvbW1lbnQuIFNvLCBJIHdvdWxkIGFk
ZCBteSAxMnRoIGNvbmRpdGlvbjoNCg0KMTIuIEEgd2F5IHRvIGV4cHJlc3MgYSBsaXN0IG9mIHZh
bGlkIFJTcyBmb3IgdGhpcyBBUyBuZWVkcyB0byBiZSBhZGRlZCB0byBzZWN0aW9uIDIuDQoNCkJl
c3QsDQoNCk5hdA0KDQoyMDE2LTAzLTExIDI6MDkgR01UKzA5OjAwIFBoaWwgSHVudCAoSURNKSA8
cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj46DQpJIHN0
cm9uZ2x5IG9wcG9zZS4gMiBtYWpvciBpc3N1ZXMuDQoNClRoaXMgaXMgbm90IHNlcnZpY2UgZGlz
Y292ZXJ5IHRoaXMgaXMgY29uZmlndXJhdGlvbiBsb29rdXAuIFRoZSBjbGllbnQgbXVzdCBoYXZl
IGFscmVhZHkgZGlzY292ZXJlZCB0aGUgb2F1dGggaXNzdWVyIHVyaSBhbmQgdGhlIHJlc291cmNl
IHVyaS4NCg0KVGhlIG9iamVjdGl2ZSB3YXMgdG8gcHJvdmlkZSBhIG1ldGhvZCB0byBlbnN1cmUg
dGhlIGNsaWVudCBoYXMgYSB2YWxpZCBzZXQgb2YgZW5kcG9pbnRzIHRvIHByZXZlbnQgbWl0bSBv
ZiBlbmRwb2ludHMgbGlrZSB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gdGhlIHJlc291cmNlIHNlcnZl
ci4NCg0KVGhlIGRyYWZ0IGRvZXMgbm90IGFkZHJlc3MgdGhlIGlzc3VlIG9mIGEgY2xpZW50IGJl
aW5nIGdpdmVuIGEgYmFkIGVuZHBvaW50IGZvciBhbiBycy4gV2hhdCB3ZSBlbmQgdXAgd2l0aCBp
cyBhIHByb21pc2N1b3VzIGF1dGh6IHNlcnZpY2UgZ2l2aW5nIG91dCB0b2tlbnMgdG8gYW4gdW53
aXR0aW5nIGNsaWVudC4NCg0KUGhpbA0KDQpPbiBNYXIgMTAsIDIwMTYsIGF0IDA4OjA2LCBWbGFk
aW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBj
b25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KKzEgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlc2UNCk9u
IDEwLzAzLzE2IDE3OjM1LCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCg0KKzENCg0KDQoNCk9uIFRo
dSwgTWFyIDEwLCAyMDE2IGF0IDY6MDQgQU0sIFJvbGFuZCBIZWRiZXJnIDxyb2xhbmQuaGVkYmVy
Z0B1bXUuc2U+PG1haWx0bzpyb2xhbmQuaGVkYmVyZ0B1bXUuc2U+DQoNCndyb3RlOg0KDQoNCg0K
SSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgYmVpbmcgbW92ZWQgZm9yd2FyZCB3aXRoIHRoZXNlIHR3
byBjaGFuZ2VzOg0KDQoNCg0KLSBjaGFuZ2UgbmFtZSB0byDigJxPQXV0aCAyLjAgQXV0aG9yaXph
dGlvbiBTZXJ2ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCdIGFzDQoNCnByb3Bvc2VkIGJ5IEJyaWFu
IGFuZA0KDQotIHVzZSB0aGUgVVJJIHBhdGggc3VmZml4IOKAmW9hdXRoLWF1dGhvcml6YXRpb24t
c2VydmVy4oCZIGluc3RlYWQgb2YNCg0K4oCZb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgYXMgcHJv
cG9zZWQgYnkgSnVzdGluLg0KDQoNCg0KMTggZmViIDIwMTYga2wuIDE0OjQwIHNrcmV2IEhhbm5l
cyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNj
aG9mZW5pZ0BnbXgubmV0Pg0KDQo6DQoNCg0KDQpIaSBhbGwsDQoNCg0KDQpUaGlzIGlzIGEgTGFz
dCBDYWxsIGZvciBjb21tZW50cyBvbiB0aGUgIE9BdXRoIDIuMCBEaXNjb3ZlcnkNCg0Kc3BlY2lm
aWNhdGlvbjoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt
ZGlzY292ZXJ5LTAxPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv
bS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi1v
YXV0aC1kaXNjb3ZlcnktMDEmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20l
N2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT13MyUyYmlpYVdvbjgxTEpDVSUyYjJtQ1BSbUElMmJyRUNC
SGdxeVJyME9ncWlXU0hVJTNkPg0KDQoNCg0KU2luY2UgdGhpcyBkb2N1bWVudCB3YXMgb25seSBh
ZG9wdGVkIHJlY2VudGx5IHdlIGFyZSBydW5uaW5nIHRoaXMgbGFzdA0KDQpjYWxsIGZvciAqKjMg
d2Vla3MqKi4NCg0KDQoNClBsZWFzZSBoYXZlIHlvdXIgY29tbWVudHMgaW4gbm8gbGF0ZXIgdGhh
biBNYXJjaCAxMHRoLg0KDQoNCg0KQ2lhbw0KDQpIYW5uZXMgJiBEZXJlaw0KDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGlu
ZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9y
ZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6
SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQrigJQgUm9sYW5kDQoNCg0KDQri
gJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0
ZW4uIg0KDQo+RnJvbSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEty
YXVzcw0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0
cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRh
PTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1
MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRh
PXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZD4N
Cg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl
M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAx
JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhk
MzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXRO
Q2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZD4NCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9y
ZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6
SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVy
YSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVy
YS5vcmcvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHAlM2ElMmYlMmZuYXQuc2FraW11cmEub3JnJTJmJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl
NDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9NkZWbWRON2FkMFl6b1lLU05G
JTJmRE8lMmZmRzJFRjFoYWo1YU9IaU1pZDZVTUklM2Q+DQpAX25hdF9lbg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs
IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h
bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpi
DQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh
bWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U
aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gQVMgYW5kIFJTIG5lZWQgdG8gYmUgc2NvcGVkIHRvIOKA
nGRvZXMgdGhpcyBSUyBhY2NlcHQgdG9rZW5zIGZyb20gdGhpcyBBU+KAnSBhcyBhIGxpc3QgaXMg
dG9vIG11Y2ggaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBiZSB1c2VkIGluIHRoZSB3cm9uZyB3YXk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp
bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmF0IFNha2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+
IFRodXJzZGF5LCBNYXJjaCAxMCwgMjAxNiA2OjI1IFBNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1
bnQgKElETSkgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1
dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI
LVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbCwmbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJpZ2h0LiBTbyB3aGF0IG15IGNvbmRp
dGlvbmFsIGFwcHJvdmFscyAoMTEgY29uZGl0aW9ucyBpbiB0b3RhbCkgc2FpZCB3YXMgdG8gZHJv
cCB0aGUgd29yZCAmcXVvdDtkaXNjb3ZlcnkmcXVvdDsgZnJvbSBldmVyeXdoZXJlLiBUaGlzIGlz
IG5vdCBhIGRpc2NvdmVyeSBzcGVjLiBUaGlzIGlzIGEgY29uZmlndXJhdGlvbiBsb29rdXAgc3Bl
YyBhcyB5b3UgY29ycmVjdGx5IHBvaW50cyBvdXQuIFNvLCBJIGFtIHdpdGggeW91IGhlcmUuJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkFsc28sIG15IDJuZCBjb25kaXRpaW9uIGlzIGVzc2VudGlhbGx5IHNheWluZyB0byBkcm9wIHNl
Y3Rpb24gMy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T25lIHRoaW5nIHRoYXQgSSBvdmVybG9va2VkIGFuZCBhbSB3aXRoIHlvdSBp
cyB0aGF0IHdlIG5lZWQgdG8gYmUgYWJsZSB0byBleHByZXNzIHRoZSBBUy1SUyByZWxhdGlvbnNo
aXBzLiBJIGhhdmUgYmVlbiBwcmVhY2hpbmcgdGhpcyBpbiB0aGUgb3RoZXIgdGhyZWFkIGZvciBz
byBtYW55IHRpbWVzIGFzIHlvdSBrbm93IHNvIEkgdGhvdWdodCBJIHBvaW50ZWQgaXQgb3V0LCBi
dXQgbWlzc2VkIGFwcGFyZW50bHkNCiBpbiBteSBwcmV2aW91cyBjb21tZW50LiBTbywgSSB3b3Vs
ZCBhZGQgbXkgMTJ0aCBjb25kaXRpb246Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEyLiBBIHdheSB0byBleHByZXNzIGEgbGlzdCBv
ZiB2YWxpZCBSU3MgZm9yIHRoaXMgQVMgbmVlZHMgdG8gYmUgYWRkZWQgdG8gc2VjdGlvbiAyLiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5CZXN0LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+MjAxNi0wMy0xMSAyOjA5IEdNVCYjNDM7MDk6MDAgUGhpbCBIdW50IChJRE0p
ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5r
Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu
Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdHJvbmdseSBvcHBvc2Uu
IDIgbWFqb3IgaXNzdWVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIG5vdCBzZXJ2aWNlIGRpc2NvdmVyeSB0aGlzIGlz
IGNvbmZpZ3VyYXRpb24gbG9va3VwLiBUaGUgY2xpZW50IG11c3QgaGF2ZSBhbHJlYWR5IGRpc2Nv
dmVyZWQgdGhlIG9hdXRoIGlzc3VlciB1cmkgYW5kIHRoZSByZXNvdXJjZSB1cmkuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBv
YmplY3RpdmUgd2FzIHRvIHByb3ZpZGUgYSBtZXRob2QgdG8gZW5zdXJlIHRoZSBjbGllbnQgaGFz
IGEgdmFsaWQgc2V0IG9mIGVuZHBvaW50cyB0byBwcmV2ZW50IG1pdG0gb2YgZW5kcG9pbnRzIGxp
a2UgdGhlIHRva2VuIGVuZHBvaW50IHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFm
dCBkb2VzIG5vdCBhZGRyZXNzIHRoZSBpc3N1ZSBvZiBhIGNsaWVudCBiZWluZyBnaXZlbiBhIGJh
ZCBlbmRwb2ludCBmb3IgYW4gcnMuIFdoYXQgd2UgZW5kIHVwIHdpdGggaXMgYSBwcm9taXNjdW91
cyBhdXRoeiBzZXJ2aWNlIGdpdmluZyBvdXQgdG9rZW5zIHRvIGFuIHVud2l0dGluZyBjbGllbnQu
Jm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNz
PSJob2VuemIiPlBoaWw8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxicj4NCk9uIE1hciAxMCwgMjAxNiwgYXQgMDg6MDYsIFZsYWRpbWlyIER6aHV2
aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9
Il9ibGFuayI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij4mIzQzOzEgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlc2U8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMC8wMy8xNiAxNzozNSwg
QnJpYW4gQ2FtcGJlbGwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4mIzQz
OzE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5P
biBUaHUsIE1hciAxMCwgMjAxNiBhdCA2OjA0IEFNLCBSb2xhbmQgSGVkYmVyZyA8YSBocmVmPSJt
YWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3JvbGFuZC5o
ZWRiZXJnQHVtdS5zZSZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+d3JvdGU6PG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5JIHN1cHBv
cnQgdGhpcyBkb2N1bWVudCBiZWluZyBtb3ZlZCBmb3J3YXJkIHdpdGggdGhlc2UgdHdvIGNoYW5n
ZXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
LSBjaGFuZ2UgbmFtZSB0byDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292
ZXJ5IE1ldGFkYXRh4oCdIGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+cHJvcG9zZWQgYnkgQnJp
YW4gYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+LSB1c2UgdGhlIFVSSSBwYXRoIHN1ZmZpeCDi
gJlvYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAmSBpbnN0ZWFkIG9mPG86cD48L286cD48L3By
ZT4NCjxwcmU+4oCZb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgYXMgcHJvcG9zZWQgYnkgSnVzdGlu
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
MTggZmViIDIwMTYga2wuIDE0OjQwIHNrcmV2IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVm
PSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5l
cy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+OjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkhpIGFsbCw8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGlz
IGEgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiB0aGUmbmJzcDsgT0F1dGggMi4wIERpc2NvdmVy
eTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPnNwZWNpZmljYXRpb246PG86
cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy
b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJm
aHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxJmFtcDtkYXRhPTAxJTdjMDElN2N0
b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1Yzcy
JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT13MyUyYmlp
YVdvbjgxTEpDVSUyYjJtQ1BSbUElMmJyRUNCSGdxeVJyME9ncWlXU0hVJTNkIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292
ZXJ5LTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPlNpbmNlIHRoaXMgZG9jdW1lbnQgd2FzIG9ubHkgYWRvcHRlZCByZWNlbnRseSB3ZSBh
cmUgcnVubmluZyB0aGlzIGxhc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jYWxsIGZvciAqKjMg
d2Vla3MqKi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5QbGVhc2UgaGF2ZSB5b3VyIGNvbW1lbnRzIGluIG5vIGxhdGVyIHRoYW4gTWFyY2ggMTB0
aC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5D
aWFvPG86cD48L286cD48L3ByZT4NCjxwcmU+SGFubmVzICZhbXA7IERlcmVrPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5P
QXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4l
MmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0
LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFh
ZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3
UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8cHJlPuKAlCBSb2xhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT7igJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5l
YXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxw
cmU+Jmd0O0Zyb20g4oCZT3BlbiBIb3VzZSBmb3IgQnV0dGVyZmxpZXPigJkgYnkgUnV0aCBLcmF1
c3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcg
bGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv
bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm
b2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFl
NmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmYW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZr
JTJicVI5bTVXZ0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0
PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0
YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+
PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91
cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0
aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQx
YjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3
JTdjMSZhbXA7c2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJx
UjltNVdnQTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48
YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUy
Zm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVh
ZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx
MWRiNDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJm
ayUyYnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRh
dGlvbjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZuYXQuc2FraW11cmEub3JnJTJmJmFtcDtkYXRhPTAx
JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhk
MzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0
YT02RlZtZE43YWQwWXpvWUtTTkYlMmZETyUyZmZHMkVGMWhhajVhT0hpTWlkNlVNSSUzZCIgdGFy
Z2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_BN3PR0301MB1234BFC8070FAC8CD5B3135FA6B50BN3PR0301MB1234_--


From nobody Thu Mar 10 19:18:16 2016
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 80F0812DFD2 for ; Thu, 10 Mar 2016 19:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 NW2Oli3sAaos for ; Thu, 10 Mar 2016 19:18:06 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 A74BD12DEF4 for ; Thu, 10 Mar 2016 19:18:06 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2B3I4U7030905 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2016 03:18:05 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2B3I4AO025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2016 03:18:04 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2B3I4v5016565; Fri, 11 Mar 2016 03:18:04 GMT
Received: from [25.168.182.215] (/72.143.226.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Mar 2016 19:18:03 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-54E62AAE-06F5-4E34-AE93-A05C74478DCA
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Thu, 10 Mar 2016 19:17:59 -0800
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com> 
To: Nat Sakimura 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 03:18:14 -0000

--Apple-Mail-54E62AAE-06F5-4E34-AE93-A05C74478DCA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Nat,

Agree with your points.=20

Regarding the last, I am not sure an AS should release the set of valid rs's=
. I think the returned data has to be limited somehow. Maybe by aud uri or m=
aybe just a yes/no to a uri the client provides. This needs discussion.=20

Am worried about the resource side discovery and how much we can intrude her=
e. It may have similar issues disclosing approved ASs.=20

Finally since we might not control rs discovery it may be possible that the d=
iscovery is fake. Maybe this is where something like software statements com=
es into play as it would at least prevent a mitm from changing the assertion=
s in its discovery. It would not have the RS's private key and this signed s=
tatements might build trust. =20

Phil

> On Mar 10, 2016, at 18:24, Nat Sakimura  wrote:
>=20
> Phil,=20
>=20
> Right. So what my conditional approvals (11 conditions in total) said was t=
o drop the word "discovery" from everywhere. This is not a discovery spec. T=
his is a configuration lookup spec as you correctly points out. So, I am wit=
h you here.=20
>=20
> Also, my 2nd conditiion is essentially saying to drop section 3.=20
>=20
> One thing that I overlooked and am with you is that we need to be able to e=
xpress the AS-RS relationships. I have been preaching this in the other thre=
ad for so many times as you know so I thought I pointed it out, but missed a=
pparently in my previous comment. So, I would add my 12th condition:=20
>=20
> 12. A way to express a list of valid RSs for this AS needs to be added to s=
ection 2.=20
>=20
> Best,=20
>=20
> Nat
>=20
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>> I strongly oppose. 2 major issues.=20
>>=20
>> This is not service discovery this is configuration lookup. The client mu=
st have already discovered the oauth issuer uri and the resource uri.=20
>>=20
>> The objective was to provide a method to ensure the client has a valid se=
t of endpoints to prevent mitm of endpoints like the token endpoint to the r=
esource server.=20
>>=20
>> The draft does not address the issue of a client being given a bad endpoi=
nt for an rs. What we end up with is a promiscuous authz service giving out t=
okens to an unwitting client.=20
>>=20
>> Phil
>>=20
>>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  w=
rote:
>>>=20
>>> +1 to move forward with these
>>>=20
>>>> On 10/03/16 17:35, Brian Campbell wrote:
>>>> +1
>>>>=20
>>>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg =

>>>> wrote:
>>>>=20
>>>>> I support this document being moved forward with these two changes:
>>>>>=20
>>>>> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Met=
adata=E2=80=9D as
>>>>> proposed by Brian and
>>>>> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99=
 instead of
>>>>> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>>>>>=20
>>>>>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig >>>>> :
>>>>>>=20
>>>>>> Hi all,
>>>>>>=20
>>>>>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>>>>> specification:
>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>>>>>=20
>>>>>> Since this document was only adopted recently we are running this las=
t
>>>>>> call for **3 weeks**.
>>>>>>=20
>>>>>> Please have your comments in no later than March 10th.
>>>>>>=20
>>>>>> Ciao
>>>>>> Hannes & Derek
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> =E2=80=94 Roland
>>>>>=20
>>>>> =E2=80=9DEverybody should be quiet near a little stream and listen."
>>>>> =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=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
>=20
>=20
>=20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

--Apple-Mail-54E62AAE-06F5-4E34-AE93-A05C74478DCA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Nat,

    Agree with your points. 

    R=
egarding the last, I am not sure an AS should release the set of valid rs's.=
 I think the returned data has to be limited somehow. Maybe by aud uri or ma=
ybe just a yes/no to a uri the client provides. This needs discussion. =


    Am worried about the resource side discovery and how much we can intrude h=
ere. It may have similar issues disclosing approved ASs. 

    Finally since w=
e might not control rs discovery it may be possible that the discovery is fa=
ke. Maybe this is where something like software statements comes into play a=
s it would at least prevent a mitm from changing the assertions in its disco=
very. It would not have the RS's private key and this signed statements migh=
t build trust.  

    Phil
    =


    On Mar 10, 2016, at 18:24, Nat Sakimura <sakimura@gmail.com> wrote:

    Phil, 

    Right. So w=
hat my conditional approvals (11 conditions in total) said was to drop the w=
ord "discovery" from everywhere. This is not a discovery spec. This is a con=
figuration lookup spec as you correctly points out. So, I am with you here.&=
nbsp;

    Also, my 2nd conditiion is essentially saying=
 to drop section 3. 

    One thing that I overlook=
ed and am with you is that we need to be able to express the AS-RS relations=
hips. I have been preaching this in the other thread for so many times as yo=
u know so I thought I pointed it out, but missed apparently in my previous c=
omment. So, I would add my 12th condition: 

    12=
. A way to express a list of valid RSs for this AS needs to be added to sect=
ion 2. 

    Best, 

    N=
at

    2016=
-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
    I strongly oppose=
. 2 major issues. 

    This is not service discove=
ry this is configuration lookup. The client must have already discovered the=
 oauth issuer uri and the resource uri. 

    The o=
bjective was to provide a method to ensure the client has a valid set of end=
points to prevent mitm of endpoints like the token endpoint to the resource s=
erver. 

    The draft does not address the issue o=
f a client being given a bad endpoint for an rs. What we end up with is a pr=
omiscuous authz service giving out tokens to an unwitting client. 

    Phil

    On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov &=
lt;vladimir@con=
nect2id.com> wrote:

    
 =20
   =20
 =20
 =20
    +1 to move forward with these
    
    
    
    
    On 10/03/16 17:35, Brian Campbell
      wrote:
    
    
    
    
    
      
    +1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
wrote:


    
      
    
        
    I support this document being moved forward with these two chan=
ges:

- change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=E2=
=80=9D as
proposed by Brian and
- use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 inste=
ad of
=E2=80=99openid-configuration=E2=80=99 as proposed by Justin.


    
        
    
          
    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.ne=
t
:

Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery

    
        
    
        
    specification:

    
        
    
          
    https://tools.ietf.org/html/draft-ietf-oauth-disc=
overy-01

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/oauth

    
        
    
        
    =E2=80=94 Roland

=E2=80=9DEverybody should be quiet near a little stream and listen."
=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss


_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/oauth



    
      
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/oauth

    
    
    
 =20



    ___________________________________=
____________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    




    -- 
    Nat Sakimura (=3Dnat)
    Chairman, OpenID Foundation<=
br>http://nat.sakimur=
a.org/
    @_nat_en
    

=

--Apple-Mail-54E62AAE-06F5-4E34-AE93-A05C74478DCA--


From nobody Fri Mar 11 01:47:13 2016
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 4B37512DD34 for ; Fri, 11 Mar 2016 01:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 sZwW25HM4g7q for ; Fri, 11 Mar 2016 01:47:10 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B904512DBFA for ; Fri, 11 Mar 2016 01:47:09 -0800 (PST)
Received: from [192.168.10.140] ([138.232.236.15]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MCxfb-1aVHNx1rYR-009gej; Fri, 11 Mar 2016 10:47:06 +0100
To: "Barroco, Michael" , "oauth@ietf.org" 
References: 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56E29419.70602@gmx.net>
Date: Fri, 11 Mar 2016 10:47:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a01s9nd5ch1p79qECHEt6NdGXBh3AnWD5"
X-Provags-ID: V03:K0:AQxTDqf7d1Q6RELFIVTY4TKdx493zKk4L8f9FYlkuhq7clvlTa2 fx2YS8wrBD5W7eiNLPoS0QXA6TJOP1tU0mBTzwXnWiS2E3jCJw1yjAOBRDezQtqEZWoGyM9 bI1oP/Ua5w/SsLeqKn/RIGChiynJwW5/029o/r6K1nVfI4G5D8rNP45EeCcUIRLMRPb6KZA DaMjS/8FEtA2AUtZvtp3w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:klvGLCWpW1k=:LlCZdq6EIuFXU+7foyPkDz dwC5JlMBlUsqRuWhtcADtNAO0UYLPOSbP+E0W5kWURgGTuxPA+so4y/eyPvCOws/5rUI0k1Gv EJUPOllQu0hiHrOOnBhOHYrnrB65SxMtHBDuG4sZUp5oDg6otnKercvhkF6HR9jGybdNH1CSx T3iCJK3kQ4zzvBfvCUJWu3ThH/dhivw4THikORR7aKZPyivGeFpJNBPXSf1utd5YV5HHDOHAN uu5+w5IUN1+Yahuqt1I6/NHiv5sTHgUAuQbpeIqliungjM9nO5PQodJEMQkqtQGL+2gHjEpiU X7/FxQWgebFwS+UE0X56ZhmuUnKNnCqDMubbO4JdyblXuaErth24+YQmxSlUfzmqUhvYJOZJB fz0mkz7fATNN0EDCPyYLdc6xcVWISkEX1zMNuhHtpjPJ+eBwjD7K9iTuQOWe58oRHRhaqbwBo 9FYCeptF7lUJOyQds9u6lBw4BEvyKXC4J+EpOGe+AGqUoVc35d0DuPCRADHod6jU9/yawE481 gzRTwOP3oJLwffDTkTacX6v8rc2p+s1t8W8YGsuAs76EL0KMd9/kp6dNgZlrItxXJNo6cy/YG Ef/ojQtiUOot+EkwESxoDGS59FZF4+5L5M4WPrzo09MU7f9MxwFv9ks+rcDbfLJ1uTANqvYvK CU+5G7yxrh5zDNhXew4Th6Ta0K82NGUNNrv7iGOOaGzA/C1H8ALt/YMTvpIOKUMGdsTFEnrYT 2/0MXjh5gxkH++AKRIA5PhgEAYVR2NkYmNNx/iJJPFQdJ9dE6aG27Rclxt4=
Archived-At: 
Cc: "tvp-cpa@list.ebu.ch" 
Subject: Re: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 09:47:12 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--a01s9nd5ch1p79qECHEt6NdGXBh3AnWD5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Michael,

thanks for dropping us a note since I was not aware of the EBU work.
It is always intesting to hear from other communities who have been able
to make use of OAuth for their use cases.

I will take a look at your specification to better understand what you
have been doing in your working group.

Ciao
Hannes

On 03/07/2016 09:43 AM, Barroco, Michael wrote:
> Dear all,
>=20
>=20
> We are contacting you because we noticed that you recently restarted
> the work on OAuth 2.0 Device Flow. We are in the process of
> publishing an ETSI standard [1] specifying a protocol with very
> similar goals. This has been developed by an EBU (European
> Broadcasting Union) working group involving broadcasters, such as
> BBC, SRG-RTS, VRT, RTVE, TVP, Global Radio UK, and device
> manufacturers.
>=20
>=20
> Our work on the =93Cross Platform Authentication=94 protocol targets
> media devices, such as connected TVs and radio receivers. It is based
> on the early OAuth 2.0 Device Flow draft, but includes additional
> features driven by broadcast industry requirements. These include:
> dynamic registration of clients, dynamic discovery of the
> authorization provider, and issuing of access tokens without
> requiring association with a user account in order to provide
> device-based authentication that does not require user sign-in or
> pairing. Our draft protocol specification is available here [2].
>=20
>=20
> Cross Platform Authentication also specifies several aspects left
> open to implementers in OAuth 2.0, such as endpoint URL paths, to
> facilitate interoperability. Also note that reference implementations
> are available [3].
>=20
>=20
> We would be very interested in working together with you to explain
> our design requirements and try to align our protocol designs.
>=20
>=20
> With best regards,
>=20
>=20
> The EBU Cross Platform Authentication group
>=20
> https://tech.ebu.ch/cpa
>=20
>=20
>=20
> [1]
> https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=3D=
47970
>
>=20
>=20
> [2] https://tech.ebu.ch/docs/tech/tech3366.pdf
>=20
> [3] https://tech.ebu.ch/code/cpa=20
> -----------------------------------------------------------------------=
-------
>
>  ************************************************** This email and
> any files transmitted with it are confidential and intended solely
> for the use of the individual or entity to whom they are addressed.=20
> If you have received this email in error, please notify the system
> manager. This footnote also confirms that this email message has been
> swept by the mailgateway=20
> **************************************************
>=20
> _______________________________________________ OAuth mailing list=20
> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
>=20


--a01s9nd5ch1p79qECHEt6NdGXBh3AnWD5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW4pQZAAoJEGhJURNOOiAtN6sIAI2QrVy9h73aXFVjZNO1xtHH
uVo8/pH/klabxPYwVggPJhhd0Z+O2fI/ebQMozkPTKqPeD7KJLvQ150DoDz0VL0G
tFMwzNiJ7u+Q8TsxKOy9989blH4EpVGpjZPTbQUrTdE+SoAdMdSoZSs93Eu84WUw
jMDQiwpYB3mZg8phBWgd0+mCV2efGUOvefbKgu+tkzy02MuHqp/ZKjWo278cHQbn
VJs9NkZHuGDkz0DvW2bRimVz8BicjUJcbRIGWnnf/I40f3xTuZhJJlBWYfWkwI6Z
HX2mVIVnyMJdXJGzpRwYSRx8ibbQWGvi5M/pe4jYndfBWdNV8nvqwX+d6+QAkuo=
=GNQk
-----END PGP SIGNATURE-----

--a01s9nd5ch1p79qECHEt6NdGXBh3AnWD5--


From nobody Fri Mar 11 01:54:48 2016
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 9929E12D5D4 for ; Fri, 11 Mar 2016 01:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 0sGSCVGGiWPm for ; Fri, 11 Mar 2016 01:54:45 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C0912D5CE for ; Fri, 11 Mar 2016 01:54:44 -0800 (PST)
Received: from [192.168.10.140] ([138.232.236.15]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MfVzj-1aT6Yk4B1H-00P6f7; Fri, 11 Mar 2016 10:54:42 +0100
To: William Denniss , "oauth@ietf.org" 
References: 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56E295E1.9030409@gmx.net>
Date: Fri, 11 Mar 2016 10:54:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vmSqTc2bH2RrvxcBvsJ6lSgK6po6vUqfm"
X-Provags-ID: V03:K0:KTyYg3K8Xnq6HGD/j8ndicWUW83BI5dOb8wlctXBJzZTd9/5XIN wsWxJeh1nH3Z+P9Fvx5FUczSHj8FK07ehum9W5V5I0UbFQHW++jtUOR/n9AqspAnTnoPf4T x+NXMSni/SVdE7TlFx7Gj7sg6isiyfuUOabkKdngu03Kai1cc7rUonHoXQYH7EAabI61iSy I2GyoT4Ru0LchUwquRuSw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:KtjjhclL1DM=:DOTGWOfhmO6JGSXom4V5hS 2xDHhF1qMnBfIjnEo3/RpS95kHD6vCl23AGboUWSM3X3Yr1C88XsMT3WpmdEbywsCfLQevIsm c/HR9xLZklGXavcdrBVQ4KyX5P5x9x4lT/9jEJ3JMUm22V5RF7veA0/5z3Glc+9c2fBuY4pgV ICsslO4vPLWK29RceRJOL8NECbfrrcpb4aajLf98teOMpG47m5DCYW0gIavpBE4XNlikfiPhl QSVG2AyBiSTreC1u2540jaLk6E0a3TCvBGW53B2mUHxYPuBuEFca9AYeiCnWU54bWS9yh+EEX dJGev4aJjH0SEtpTlGr4e3nJW+7Ynlo5CfrpLjq9LhbNswDKc7/rWEGFUM7+PbhF8Xf/gqRGS 8vatdoz5GxFfWjncpnhZyCKRwNaC5wHNnLIqlsfpWzxeyhHNybY5Gwu/QJ0lV4TQjc2dONR0h sVD2SMwAPdQDW0Gg0pgjqk+iHk1NeVrKhK0s7b0Byqv5chrE4aTms3JPgI8aENMVnTeA0zwhO KdcvZ+Yj9RSfftTBmMcr9zhsQFceB4bOIjSfj55q4jxl92O0lBHdweBnsiRGjnT6yi0i0YW1J pRI/E3p/SjK+s1b+LhT+YWAvMq/ryS7RvBpw6sm7Be635iximu3qU+S8dzBN/QxV7P+XFFoaq tZ2rVpWTsAeWTUGKstHN4kg7rgcFDn399JGQMtiPRxldhFKqgiTCDFPZeHQf31bTKYatxm556 8gsFFL4Qo4luy8g/ZTUgzy45tpUFDbLKINmSdbFgjThNWjMalR+Pq32E8V0=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries for Android and iOS now available
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 09:54:46 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vmSqTc2bH2RrvxcBvsJ6lSgK6po6vUqfm
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi William,

sorry for the late response but I just wanted to note that I really
appreciate your efforts around making code available for specifications
we are developing. The implementation efforts that take place currently
with specification writing have always provided a lot of valuable feedbac=
k.

I will take a look at your libraries in the near future since I am
interested in using those myself for the IoT environment.

Ciao
Hannes


On 02/26/2016 08:30 PM, William Denniss wrote:
> The Google Identity team this week open sourced AppAuth for Android and=

> iOS. AppAuth is a client library for OAuth that enables native Android
> and iOS apps to perform authorization flows in a secure and usable way
> using in-app browser tabs (Custom Tabs on Android,
> SFSafariViewController on iOS), fully supporting the draft best practic=
e
>  for
> performing standards-based auth in native apps.
>=20
> The libraries are opinionated and follow the draft best practice
> completely. Low-level protocol APIs are exposed allowing customizabilit=
y
> including the ability to support OAuth extensions and custom parameters=
=2E
> Higher level convenience APIs are also provided to assist with auth
> state management, and encapsulate common requests like exchanging the
> authorization code and making API calls with fresh tokens.
>=20
> You can grab the code here:
> https://openid.github.io/AppAuth-Android
> https://openid.github.io/AppAuth-iOS
>=20
> The library should work with any Authorization Server that supports
> public clients with custom URI scheme and/or app-claimed HTTPS redirect=
s
> (custom URI schemes are still required for full backwards compatibility=

> support, though on newer systems app-claimed HTTPS links are viable =96=

> both are supported by the library). We have verified interop with the
> Google and PingFederate OAuth implementations.
>=20
> Please give it a spin, and let me know how it works with your own
> implementations!
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--vmSqTc2bH2RrvxcBvsJ6lSgK6po6vUqfm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW4pXhAAoJEGhJURNOOiAtXWQH/jGV9ELJA1isePr3BMx7CfTd
0T5JAeDlj3MXqLGibyKvIVtd8K9r7gHaWiNDs/QTu+bP1tYuUsO++EpLHtssBv71
vlyDjgY6MoPJPOCWxFVJ4CIQNHJh79t1Visd6RcA+D3u9zNRgePX3kSrQCW/bKBv
wJoi++WteaJFhAQu7pJDx74IiENYerzepBkJ6yrVc1wH51o74uUzcFyNyRkxLt0G
0a7KuGquvEi75tB6Msgs3TXcVUbv+mJUHs4fHmJUPXnpPG8QPxd9wG2sWeNoRiDD
dy8F8SRNfu+cBseb+wNUnpot6qwAeyK3zON8p4Ajd3MUbIOCIc68x7QC5ZAvr6I=
=/z/F
-----END PGP SIGNATURE-----

--vmSqTc2bH2RrvxcBvsJ6lSgK6po6vUqfm--


From nobody Fri Mar 11 03:21:57 2016
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 D5A5C12D5EF for ; Fri, 11 Mar 2016 03:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 4Z9WYkaYTIlR for ; Fri, 11 Mar 2016 03:21:54 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 3360212D50C for ; Fri, 11 Mar 2016 03:21:54 -0800 (PST)
Received: by mail-lb0-x234.google.com with SMTP id k15so152653891lbg.0 for ; Fri, 11 Mar 2016 03:21:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5pGYoLjrimof6t2TZoF0g0nSMyWOsa3VbjGTXhxPYbg=; b=YwzzOthvLwFMNvzn1TnLJkSuHo+LtKGAiOdeWLWFY+qnW3ozAb1+ECteu8SCUqXDEh Xo1cF4L3qkQ3F+3pfFFzRB7eNlGXM1KU30nttmmeidWRAaryMvXzBIlA+iUAxsDt+WBl qZGbKGAZAm5lP5NEEamOubHuosMxZW/eJIjxsw3AU1TdE2COQYn45FDQ3xKIUEZ1xR2x 5CyDZ4yAjiCUPo+BVQQz8y6Td6Ft3TOkGUD6adFfxqsVfmRlp3Pest7LawPYV6hSQdus 6WLmceGaOphqW8zimoByoz0PDDyBpayHNtlIGdvfxXgOPnsrafF7WofW+SMtlvaG6HXO BH5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5pGYoLjrimof6t2TZoF0g0nSMyWOsa3VbjGTXhxPYbg=; b=byzXw05oCDWaEBxVVQU3b+gWOIIvcsYPaqbuwNvUUhJEKxcwzelKDlDPWLZU3j3wQa gUH7LiT8ApbHA5FD9cq6zIeb0VhrLimSnH3lWEA2CC6vQuSw1KwBmWivc5FlscdsmwKM 7mwjk0WO+5aazOua1/EmoPH4cpZNtucLSDSkev7pBJM/OsQIM/huwnQOc+31QuEprLLs CvSb4C9Itzd/aR/o5KISaAP6vb3DVXmICJR8mvVp/iXjklgQUTinEfozyO98eLBxgcXl 4UkUkjSgjfUJ1LA4ILy8qn/7CppS6EuT5aOp7yT0FOHR/NKz3xVOha2NLAe/gWLkvfkR VAsQ==
X-Gm-Message-State: AD7BkJJ8zUtsJf58mZHFwhiVZnCJ147v2bEx4Bcl0lvij87HxWrjYcF9BaducNKNzKaTnzwscnfP8yeYHDNptQ==
MIME-Version: 1.0
X-Received: by 10.112.129.169 with SMTP id nx9mr3049633lbb.96.1457695312302; Fri, 11 Mar 2016 03:21:52 -0800 (PST)
Received: by 10.112.85.3 with HTTP; Fri, 11 Mar 2016 03:21:52 -0800 (PST)
In-Reply-To: <56C5C9D5.6040703@gmx.net>
References: <56C5C9D5.6040703@gmx.net>
Date: Fri, 11 Mar 2016 12:21:52 +0100
Message-ID: 
From: Melvin Carvalho 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=047d7b3441da47da0b052dc42374
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 11:21:57 -0000

--047d7b3441da47da0b052dc42374
Content-Type: text/plain; charset=UTF-8

On 18 February 2016 at 14:40, Hannes Tschofenig 
wrote:

> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>

Just finished reviewing this.  Since it's 1 day past the comments dealine,
I'll just leave some high level thoughts, based on how I may implement some
of this.  No need to respond.

1. I'd like to see a path supporting the increasingly popular w3c REC, JSON
LD.

2. General feedback I've had since the inception of webfinger was that it's
had decreasing adoption.  Perhaps an idea to remove reference.  Usage stats
would be interesting if public.

3. I feel the mandatory-ness of TLS/SSL slightly over the top.  I dont
think we are at HTTPS everywhere yet, and it's still a pain for the long
tail of developers.

Ill be interested to see this work in action.

>
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--047d7b3441da47da0b052dc42374
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On 18 February 2016 at 14:40, Hannes Tschofenig <<=
a href=3D"mailto:hannes.tschofenig@gmx.net" target=3D"_blank">hannes.tschof=
enig@gmx.net> wrote:
    Hi all=
,
    

    
This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery specifica=
tion:
    
https://tools.ietf.org/html/draft-ietf-oa=
uth-discovery-01
    

    
Since this document was only adopted recently we are running this last
    
call for **3 weeks**.
    

    
Please have your comments in no later than March 10th.

    Just finished reviewing this.=C2=A0 Since it's 1 day pa=
st the comments dealine, I'll just leave some high level thoughts, base=
d on how I may implement some of this.=C2=A0 No need to respond.

    1. I'd like to see a path supporting the increasingly popular w=
3c REC, JSON LD.=C2=A0 

    2. General feedback I've had =
since the inception of webfinger was that it's had decreasing adoption.=
=C2=A0 Perhaps an idea to remove reference.=C2=A0 Usage stats would be inte=
resting if public.

    3. I feel the mandatory-ness of TLS/SS=
L slightly over the top.=C2=A0 I dont think we are at HTTPS everywhere yet,=
 and it's still a pain for the long tail of developers.

    Il=
l be interested to see this work in action.
    =C2=A0
    

    
Ciao
    
Hannes & Derek
    

    

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


    

--047d7b3441da47da0b052dc42374--


From nobody Fri Mar 11 06:29:34 2016
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 C014912D768 for ; Fri, 11 Mar 2016 06:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 lszpm6_hm7Db for ; Fri, 11 Mar 2016 06:29:30 -0800 (PST)
Received: from omr-m015e.mx.aol.com (omr-m015e.mx.aol.com [204.29.186.15]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47D412D743 for ; Fri, 11 Mar 2016 06:29:28 -0800 (PST)
Received: from mtaout-aac02.mx.aol.com (mtaout-aac02.mx.aol.com [172.27.2.34]) by omr-m015e.mx.aol.com (Outbound Mail Relay) with ESMTP id CDACC380005A; Fri, 11 Mar 2016 09:29:27 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aac02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4697338000087; Fri, 11 Mar 2016 09:29:27 -0500 (EST)
To: Nat Sakimura , Roland Hedberg , Hannes Tschofenig 
References: <56C5C9D5.6040703@gmx.net>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E2D647.5080007@aol.com>
Date: Fri, 11 Mar 2016 09:29:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060809010002010804000206"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1457706567; bh=2YyWpnsFUnnE4xWKWfQQ2VCQ9hPIaiMvby4Y2ilFE0Y=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=qNelHFR+n8o0JAivXqYuKRvEy5NNZPJSfcP46N7JDRv/J4ANF5rwZcj0z9VXwRDne mD0zD5qeUZ9bgMLXvCmd2FwnbKfPE0aS+13EnFUbKuJtwK1SgDIb/3qMymgCQKKhAj CQj41fm0Jbb8S98g44YpLOJj7ErFprIjSorzH2N4=
x-aol-sid: 3039ac1b022256e2d64739ce
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 14:29:33 -0000

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

+1 for these changes and finishing the doc

On 3/10/16 10:45 AM, Nat Sakimura wrote:
> +1 in proceeding with the following changes:
>
>  1. Change name to "*OAuth 2.0 Authorization Server Metadata*",
>     aligning with section 2.
>  2. Have the AS dictate the URI path suffix through link header in the
>     HEAD response to AS or OOB mechanism.
>  3. Align the title of section 3 to section 2 so that it will be
>     "Obtaining Authorization Server Metadata"
>  4. Align the title of section 3.1 to section 2 so that it will be
>     "Authorization Server Metadata Request"
>  5. Align the title of section 3.2 to section 2 so that it will be
>     "Authorization Server Metadata Response"
>  6. Align the title of section 3.3 to section 2 so that it will be
>     "Authorization Server Metadata Validation"
>  7. Align the title of section 7.1 to section 2 so that it will be
>     "*OAuth Authorization Server Metadata Registry*"
>  8. Change all the occurrence of "authorization server discovery
>     metadata" to "authorization server metadata".
>  9. Change all the occurrence of "discovery metadata" to
>     "authorization server metadata" in a not-case-sensitive way but
>     preserving the original case.
> 10. Change "supporting discovery" to "supporting this specification".
> 11. Change abbrev="OAuth 2.0 Discovery" to abbrev="OAuth 2.0 AS Metadata"
>
> Best,
>
> Nat Sakimura
>
> 2016年3月10日(木) 22:05 Roland Hedberg  >:
>
>     I support this document being moved forward with these two changes:
>
>     - change name to “OAuth 2.0 Authorization Server Discovery
>     Metadata†as proposed by Brian and
>     - use the URI path suffix ’oauth-authorization-server’ instead of
>     ’openid-configuration’ as proposed by Justin.
>
>     > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig
>     >:
>     >
>     > Hi all,
>     >
>     > This is a Last Call for comments on the  OAuth 2.0 Discovery
>     specification:
>     > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>     >
>     > Since this document was only adopted recently we are running
>     this last
>     > call for **3 weeks**.
>     >
>     > Please have your comments in no later than March 10th.
>     >
>     > Ciao
>     > Hannes & Derek
>     >
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>     — Roland
>
>     â€Everybody should be quiet near a little stream and listen."
>     >From ’Open House for Butterflies’ by Ruth Krauss
>
>     _______________________________________________
>     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

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    +1 for these changes and
      finishing the doc
    
    
    
    
    On 3/10/16 10:45 AM, Nat Sakimura
      wrote:
    
    
    
    
    
      
    +1 in proceeding with the following changes: 
        
    
          
      
            
    1. Change name to "OAuth
                  2.0 Authorization Server Metadata", aligning with
                section 2. 
      
            
      2. 
            
    2. Have the AS dictate the
                URI path suffix through link header in the HEAD response
                to AS or OOB mechanism. 
      
            
      3. 
            
    3. Align the title of section
                3 to section 2 so that it will be "Obtaining
                  Authorization Server Metadata"
      
              
      4. 
            
    4. Align the title of section 3.1
                  to section 2 so that it will be "Authorization
                    Server Metadata Request"
      
                
      5. 
            
    5. Align
                    the title of section 3.2 to section 2 so that it
                    will be "Authorization
                      Server Metadata Response"
      
                  
      6. 
            
    6. Align the title of section
                      3.3 to section 2 so that it will be "Authorization
                          Server Metadata Validation"
      
                    
      7. 
            
    7. Align the title of section 7.1 to section 2 so that it
              will be "OAuth Authorization Server Metadata Registry"
      8. 
            
    8. Change all the occurrence
                of "authorization server discovery metadata" to
                "authorization server metadata". 
      9. 
            
    9. Change all the occurrence
              of "discovery metadata" to "authorization server metadata"
              in a not-case-sensitive way but preserving the original
              case. 
      10. 
            
    10. Change "supporting discovery" to "supporting this
              specification". 
      11. 
            
    11. Change abbrev="OAuth 2.0
                Discovery" to abbrev="OAuth 2.0 AS Metadata"
      12. 
          
    
          
    Best, 
    
        
    
        

    
        
    
        
    Nat Sakimura
    
      
    
      
    
      
    
        
    2016年3月10日(木) 22:05 Roland Hedberg <roland.hedberg@umu.se>:
    
        
    
        
    I support
          this document being moved forward with these two changes:
    
          
    
          - change name to “OAuth 2.0 Authorization Server Discovery
          Metadata†as proposed by Brian and
    
          - use the URI path suffix ’oauth-authorization-server’ instead
          of ’openid-configuration’ as proposed by Justin.
    
          
    
          > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net>:
    
          >
    
          > Hi all,
    
          >
    
          > This is a Last Call for comments on the  OAuth 2.0
          Discovery specification:
    
          > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
    
          >
    
          > Since this document was only adopted recently we are
          running this last
    
          > call for **3 weeks**.
    
          >
    
          > Please have your comments in no later than March 10th.
    
          >
    
          > Ciao
    
          > Hannes & Derek
    
          >
    
          > _______________________________________________
    
          > OAuth mailing list
    
          > OAuth@ietf.org
    
          > https://www.ietf.org/mailman/listinfo/oauth
    
          
    
          — Roland
    
          
    
          â€Everybody should be quiet near a little stream and listen."
    
          >From ’Open House for Butterflies’ by Ruth Krauss
    
          
    
          _______________________________________________
    
          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

    
    
    
    
    
    
    -- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

    
  


--------------060809010002010804000206--


From nobody Fri Mar 11 06:37:19 2016
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 ACCFD12D7AD for ; Fri, 11 Mar 2016 06:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 hKQDZNwnA1lf for ; Fri, 11 Mar 2016 06:37:16 -0800 (PST)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D8E12D55A for ; Fri, 11 Mar 2016 06:36:07 -0800 (PST)
Received: from mtaout-aac01.mx.aol.com (mtaout-aac01.mx.aol.com [172.27.2.33]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 7E0043800115; Fri, 11 Mar 2016 09:36:06 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4E92F38000095; Fri, 11 Mar 2016 09:36:05 -0500 (EST)
To: "Phil Hunt (IDM)" , Nat Sakimura 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E2D7D5.6070101@aol.com>
Date: Fri, 11 Mar 2016 09:36:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070600090802050801020505"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1457706966; bh=VIXuutmGQpoAd6lkRV6vvTT44EW9yYQSt45HW4OqG20=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=vQs22kTuqAuSFvQ9VySvZ48xAHqINMKYCuVN5m8kwuR8R3hIWYjpt1fKsXI/uHZRr R90Xu9eIVd48PKVaAYlmTZ7YIS8rj7aE4fY8AdIrOTs6viX3JoIw2K7R3mtpd0xiwu +T+gTcsAfbGfDnSUml5zU7+yYtj+teG/ebyCQOkw=
x-aol-sid: 3039ac1b022156e2d7d53797
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 14:37:18 -0000

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

I am strongly against requiring the AS to know about RS URIs and 
managing that based on a client request for a token. I've stated my 
reasons previously.

Happy to agree to disagree:)

Thanks,
George

On 3/10/16 10:17 PM, Phil Hunt (IDM) wrote:
> Nat,
>
> Agree with your points.
>
> Regarding the last, I am not sure an AS should release the set of 
> valid rs's. I think the returned data has to be limited somehow. Maybe 
> by aud uri or maybe just a yes/no to a uri the client provides. This 
> needs discussion.
>
> Am worried about the resource side discovery and how much we can 
> intrude here. It may have similar issues disclosing approved ASs.
>
> Finally since we might not control rs discovery it may be possible 
> that the discovery is fake. Maybe this is where something like 
> software statements comes into play as it would at least prevent a 
> mitm from changing the assertions in its discovery. It would not have 
> the RS's private key and this signed statements might build trust.
>
> Phil
>
> On Mar 10, 2016, at 18:24, Nat Sakimura  > wrote:
>
>> Phil,
>>
>> Right. So what my conditional approvals (11 conditions in total) said 
>> was to drop the word "discovery" from everywhere. This is not a 
>> discovery spec. This is a configuration lookup spec as you correctly 
>> points out. So, I am with you here.
>>
>> Also, my 2nd conditiion is essentially saying to drop section 3.
>>
>> One thing that I overlooked and am with you is that we need to be 
>> able to express the AS-RS relationships. I have been preaching this 
>> in the other thread for so many times as you know so I thought I 
>> pointed it out, but missed apparently in my previous comment. So, I 
>> would add my 12th condition:
>>
>> 12. A way to express a list of valid RSs for this AS needs to be 
>> added to section 2.
>>
>> Best,
>>
>> Nat
>>
>> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) > >:
>>
>>     I strongly oppose. 2 major issues.
>>
>>     This is not service discovery this is configuration lookup. The
>>     client must have already discovered the oauth issuer uri and the
>>     resource uri.
>>
>>     The objective was to provide a method to ensure the client has a
>>     valid set of endpoints to prevent mitm of endpoints like the
>>     token endpoint to the resource server.
>>
>>     The draft does not address the issue of a client being given a
>>     bad endpoint for an rs. What we end up with is a promiscuous
>>     authz service giving out tokens to an unwitting client.
>>
>>     Phil
>>
>>     On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov
>>     > wrote:
>>
>>>     +1 to move forward with these
>>>
>>>     On 10/03/16 17:35, Brian Campbell wrote:
>>>>     +1
>>>>
>>>>     On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
>>>>     wrote:
>>>>
>>>>>     I support this document being moved forward with these two changes:
>>>>>
>>>>>     - change name to “OAuth 2.0 Authorization Server Discovery Metadata†as
>>>>>     proposed by Brian and
>>>>>     - use the URI path suffix ’oauth-authorization-server’ instead of
>>>>>     ’openid-configuration’ as proposed by Justin.
>>>>>
>>>>>>     18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
>>>>>>     :
>>>>>>
>>>>>>     Hi all,
>>>>>>
>>>>>>     This is a Last Call for comments on the  OAuth 2.0 Discovery
>>>>>     specification:
>>>>>>     https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>>>>>
>>>>>>     Since this document was only adopted recently we are running this last
>>>>>>     call for **3 weeks**.
>>>>>>
>>>>>>     Please have your comments in no later than March 10th.
>>>>>>
>>>>>>     Ciao
>>>>>>     Hannes & Derek
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OAuth mailing list
>>>>>>     OAuth@ietf.org 
>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>     — Roland
>>>>>
>>>>>     â€Everybody should be quiet near a little stream and listen."
>>>>>      From ’Open House for Butterflies’ by Ruth Krauss
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     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
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    I am strongly against
      requiring the AS to know about RS URIs and managing that based on
      a client request for a token. I've stated my reasons previously. 
    
      
    
      Happy to agree to disagree:)
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/10/16 10:17 PM, Phil Hunt (IDM)
      wrote:
    
    
    
    
    
      
      
    Nat,
    
      

    
      
    
      
    Agree with your points. 
    
      

    
      
    
      
    Regarding the last, I am not sure an
        AS should release the set of valid rs's. I think the returned
        data has to be limited somehow. Maybe by aud uri or maybe just a
        yes/no to a uri the client provides. This needs discussion. 
    
      

    
      
    
      
    Am worried about the resource side
        discovery and how much we can intrude here. It may have similar
        issues disclosing approved ASs. 
    
      

    
      
    
      
    Finally since we might not control rs
        discovery it may be possible that the discovery is fake. Maybe
        this is where something like software statements comes into play
        as it would at least prevent a mitm from changing the assertions
        in its discovery. It would not have the RS's private key and
        this signed statements might build trust.  
    
      
    
      

    
        Phil
    
      

    
        On Mar 10, 2016, at 18:24, Nat Sakimura <sakimura@gmail.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
    Phil, 
            

    
            
    
            
    Right. So what my conditional approvals (11 conditions
              in total) said was to drop the word "discovery" from
              everywhere. This is not a discovery spec. This is a
              configuration lookup spec as you correctly points out. So,
              I am with you here. 
    
            

    
            
    
            
    Also, my 2nd conditiion is essentially saying to drop
              section 3. 
    
            

    
            
    
            
    One thing that I overlooked and am with you is that we
              need to be able to express the AS-RS relationships. I have
              been preaching this in the other thread for so many times
              as you know so I thought I pointed it out, but missed
              apparently in my previous comment. So, I would add my 12th
              condition: 
    
            

    
            
    
            
    12. A way to express a list of valid RSs for this AS
              needs to be added to section 2. 
    
            

    
            
    
            
    Best, 
    
            

    
            
    
            
    Nat
    
          
    
          

    
            
    2016-03-11 2:09 GMT+09:00 Phil Hunt
              (IDM) <phil.hunt@oracle.com>:
    
              
    
                
    
                  
    I strongly oppose. 2 major issues. 
    
                  

    
                  
    
                  
    This is not service discovery this is
                    configuration lookup. The client must have already
                    discovered the oauth issuer uri and the resource
                    uri. 
    
                  

    
                  
    
                  
    The objective was to provide a method to ensure
                    the client has a valid set of endpoints to prevent
                    mitm of endpoints like the token endpoint to the
                    resource server. 
    
                  

    
                  
    
                  
    The draft does not address the issue of a client
                    being given a bad endpoint for an rs. What we end up
                    with is a promiscuous authz service giving out
                    tokens to an unwitting client. 
    
                        
    
                        Phil
    
                  
    
                    
    
                      

    
                        On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov
                        <vladimir@connect2id.com>
                        wrote:
    
                        
    
                      
    
                      
    
                      
    
                        
     +1 to move forward with these
    
                          
    
                          
    On 10/03/16 17:35, Brian Campbell wrote:
    
                          
    
                          
    
                            
    +1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
wrote:


    
                            
    
                              
    I support this document being moved forward with these two changes:

- change name to “OAuth 2.0 Authorization Server Discovery Metadata†as
proposed by Brian and
- use the URI path suffix ’oauth-authorization-server’ instead of
’openid-configuration’ as proposed by Justin.


    
                              
    
                                
    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net
:

Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery

    
                              
    
                              
    specification:

    
                              
    
                                
    https://tools.ietf.org/html/draft-ietf-oauth-discovery-01

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek

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

    
                              
    
                              
    — Roland

â€Everybody should be quiet near a little stream and listen."
>From ’Open House for Butterflies’ by Ruth Krauss


_______________________________________________
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

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

    
            
    
            -- 
    
            
    Nat Sakimura (=nat)
              
    Chairman, OpenID Foundation
    
                http://nat.sakimura.org/
    
                @_nat_en
    
            
    
          
    
        
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  


--------------070600090802050801020505--


From nobody Fri Mar 11 06:52:05 2016
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 8831812D7BF for ; Fri, 11 Mar 2016 06:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level: 
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 mM-D5QpQr0k8 for ; Fri, 11 Mar 2016 06:51:59 -0800 (PST)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 67BD812D6BE for ; Fri, 11 Mar 2016 06:51:59 -0800 (PST)
Received: by mail-qg0-x22e.google.com with SMTP id t4so99737966qge.0 for ; Fri, 11 Mar 2016 06:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ud4A4NcdmzvdGS+cPGzRFuRyLVAEqRIulUXdcB0FZe0=; b=0VO4/pG+tZZuGLqXoG7V7A4Cn7cZipSPL7DNhQ/kl15IS0KAB8izbQ5wR4wnPNn5WX wR1LWbo2NuD2V6qahRfb5qYM8JB9OcxA8utVseVkAl7McQeEO7AoeXgLzyFIApj9IhbD Fx0bSV/c/LTpDA4sQHv1HJCi1poxsDHfWoeN8a6LkQ2T3uNjB1baSjLfSR6RpNGKKTxe jzxTz3fbAfdE/tRKzaE2HpfKzdiaqxP+5NG6pR+WAMqPvlXorXlTPZwDEwlrrnhqRvQa CeqBRNn/u+5n6wVpIsouBKcHdUbqXHbSyE6JIvaxaBOY7kDPeFvFOTBVIAmYhrbuh4VK 8QrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ud4A4NcdmzvdGS+cPGzRFuRyLVAEqRIulUXdcB0FZe0=; b=QHkScQSkFnbkx0El0DcbwNci4PaoKHqWDfQ415OI4PLfUrRHMWQqo/aD6ez2zK87Ba fBjdgsASjyIeNH5APAqEg/ptXC5pprWgeEhGUu2Wxqz8yKQGUcHn96bIP7qcO/rN4M8z sBDjodbjaP8kshdhhZipurkgJj03MEw/Tshq0qysv2tz5gtFjQk06UUTLbb8X+HykzzF e4YoAdudYCnndGXse5inhaTxr8Wv3NUKA41TdUyiaQ33VwY/y1KLxEFheV+vhVbRm8lV ZROfTuESACOvA5klKhVUdxNwsDDhgfXiEP2wt8G4Sr8v2yQ+KeF22UHv0Ijd8vPWn+Ob 0HXQ==
X-Gm-Message-State: AD7BkJIoplhAMApOCysIPyI5Kj5AUuq+e/h+krBDm7w3z6ggSuw4B8IBTlh219v/+7YDtQ==
X-Received: by 10.140.97.69 with SMTP id l63mr12064645qge.91.1457707918397; Fri, 11 Mar 2016 06:51:58 -0800 (PST)
Received: from [192.168.8.101] ([181.202.152.189]) by smtp.gmail.com with ESMTPSA id q69sm4140229qki.11.2016.03.11.06.51.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Mar 2016 06:51:57 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5A4BD786-117D-4843-A914-B74B5926E893"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 11 Mar 2016 11:51:52 -0300
Message-Id: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>  
To: Anthony Nadalin 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 14:52:03 -0000

--Apple-Mail=_5A4BD786-117D-4843-A914-B74B5926E893
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2A6B59B9-E615-40D6-A541-0C83CED17749"


--Apple-Mail=_2A6B59B9-E615-40D6-A541-0C83CED17749
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think Phil is proposing something different.   Should the client send =
a token from this AS to that RS. =20

His goal is to prevent man in the middle attacks where a bad RS gets a =
AT that is audianced to/accepted by another RS.

That is separate from the question of if a RS accepts tokens from a good =
AS.   A bad AS would always say yes.

We need to be careful of what if anything the RS provides to the client =
as meta-data without validation.

Currently the client can provide a list of scopes required to get =
access.   I personally feel it would be useful to also include in the =
unauthenticated error response an indication of what API the resource =
supports.  Say =E2=80=9Cscim2=E2=80=9D as an example.   I don=E2=80=99t =
think adding that is however a high priority as most if all clients know =
what API they expect.   It might be useful if at some point in the =
future if a client were to be given a RS URI it could check to see if it =
is a protocol that it supports before bothering with OAuth.    I expect =
that a lot of people will want that left to the API definition.   I =
think we can talk about it but rate this low priority.

I agree that the RS giving out a list of AS that it trusts is a =
generally bad idea.  I hope that is not on the table.

I don=E2=80=99t think that preventing a client from sending a token to =
the wrong RS is part of a AS meta-data discovery problem.

I do however think that it is important.

We have been discussing this as a separate problem to AS meta-data =
discovery where the endpoints of the AS and it=E2=80=99s configuration =
are discovery.   Sorry for perhaps stating the obvious, but the RS is =
explicitly not part of the AS in OAuth 2.   Starting in WAP that was a =
core principal.

So we have a number of options to address the RS token leakage via MiTM =
attacks.

1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS =
or Token binding they cannot be replayed.  Signed messages where the =
signing covers the RS Host and path components,  also would work.

2) Have the AS audience restrict the resources the AT is good at. (AT =
should be doing that now)=20
In the token response include the list of audience/s the token is =
presentable at.  The client would throw an error if the RS it intends to =
send the token to is not on the list.   The RS the token is good at =
might change based on scopes, client_id and resource owner.   This is =
the place where all of that comes together.   In some cases the RS and =
AS might not have a pre-established relationship.   The client should =
send the RS base URI to the AS as part of the request.  The AS can use =
that to audience restrict the AT and issue the AT or refuse to issue the =
AT based on policy.
It can also use the audience in the request to down audience the AT if =
the default is to have multiple audiences.    We may want to use a term =
other than audience for this like resource or destination.  It is a =
audience but that term might confuse people with AT.

We did talk about breaking audience out of POP key distribution, and =
Brian Campbell did a draft =
https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt.  =20

To do this we could take dst4jwt and add another spec that adds a new =
dst parameter to the token and authorization endpoints requests That =
would be a space separated list of dst values.  and in the response from =
the token endpoint would be a JSON array of dst values.

3) Have the AS always return all the list of all RS the token can be =
used at (basically Nat's link relationship proposal).  It needs a way to =
handle=20
down destinationing of AT and to allow for un-configured RS that it =
might issue a token for.  So could be combined with dst from 2.  =
Basically returning the acceptable destinations as link headers vs JS in =
the response is mostly a style issue that other people can bike shed.


4) Trying to add all the RS to the AS discovery document.  This seems =
impractical as there would be multiple protocols and doesn=E2=80=99t =
address un-configured RS.

5) Some new AS endpoint that the client could introspect the RS URI and =
get back metadata about if the client should send tokens there.
    A couple of problems with this.  The first is that it would not =
support un-configured RS unless you add dst to the token and =
authorization endpoints.   The other is that the introspection endpoint =
doesn=E2=80=99t have the context of the RO and client_id unless you also =
pass the code/RT and client_id, and probably client credentials.    =
Basically this is trying to introspect the AT to determine the =
audiance/dst.   By the time you build a new introspection endpoint =
securely it is going to look like the token endpoint with a bit more =
meta data about the token beyond expiry and scopes.


I think we should go a head with the renamed "OAuth 2.0 Authorization =
Server Discovery Metadata=E2=80=9D=20
I am also fine with making the default document 'openid-configuration=E2=80=
=99  as long as we allow for protocol specific variation so that SCIM2 =
could define a file name.    If people want we could do a API  to file =
name registry so that protocol specific ones can be defined.

We are all-ready working on option 1 to secure AT, we need a spec like I =
propose in 2 for bearer tokens.  We can add one request parameter and a =
bit more token meta-data to the token response and that takes care of =
the problem.   Honestly we probably should have separated scope and =
destination in the first place and returned both dst and scope in the =
response all along, so this is update that is consistent with the =
eisting architecture of OAuth 2.

Lets keep the two issues separate.

John B.
=20



> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin  =
wrote:
>=20
> The relationship between AS and RS need to be scoped to =E2=80=9Cdoes =
this RS accept tokens from this AS=E2=80=9D as a list is too much =
information that could be used in the wrong way
> =C2=A0 <>
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
> Sent: Thursday, March 10, 2016 6:25 PM
> To: Phil Hunt (IDM) 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
> =20
> Phil,=20
> =20
> Right. So what my conditional approvals (11 conditions in total) said =
was to drop the word "discovery" from everywhere. This is not a =
discovery spec. This is a configuration lookup spec as you correctly =
points out. So, I am with you here.=20
> =20
> Also, my 2nd conditiion is essentially saying to drop section 3.=20
> =20
> One thing that I overlooked and am with you is that we need to be able =
to express the AS-RS relationships. I have been preaching this in the =
other thread for so many times as you know so I thought I pointed it =
out, but missed apparently in my previous comment. So, I would add my =
12th condition:=20
> =20
> 12. A way to express a list of valid RSs for this AS needs to be added =
to section 2.=20
> =20
> Best,=20
> =20
> Nat
> =20
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) >:
> I strongly oppose. 2 major issues.=20
> =20
> This is not service discovery this is configuration lookup. The client =
must have already discovered the oauth issuer uri and the resource uri.=20=

> =20
> The objective was to provide a method to ensure the client has a valid =
set of endpoints to prevent mitm of endpoints like the token endpoint to =
the resource server.=20
> =20
> The draft does not address the issue of a client being given a bad =
endpoint for an rs. What we end up with is a promiscuous authz service =
giving out tokens to an unwitting client.=20
>=20
> Phil
>=20
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov > wrote:
>=20
> +1 to move forward with these
>=20
> On 10/03/16 17:35, Brian Campbell wrote:
> +1
> =20
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg =
 
> wrote:
> =20
> I support this document being moved forward with these two changes:
> =20
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery =
Metadata=E2=80=9D as
> proposed by Brian and
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 =
instead of
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
> =20
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig =

> :
> =20
> Hi all,
> =20
> This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 =

> =20
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
> =20
> Please have your comments in no later than March 10th.
> =20
> Ciao
> Hannes & Derek
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

> =E2=80=94 Roland
> =20
> =E2=80=9DEverybody should be quiet near a little stream and listen."
> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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

>=20
>=20
> =20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ =

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


--Apple-Mail=_2A6B59B9-E615-40D6-A541-0C83CED17749
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I think Phil is proposing something different.   Should =
the client send a token from this AS to that RS.  
    His goal is to prevent man in the =
middle attacks where a bad RS gets a AT that is audianced to/accepted by =
another RS.

    That=
 is separate from the question of if a RS accepts tokens from a good AS. =
  A bad AS would always say yes.

    We need to be careful of what if =
anything the RS provides to the client as meta-data without =
validation.

    Currently the client can provide a list of scopes required to =
get access.   I personally feel it would be useful to also include =
in the unauthenticated error response an indication of what API the =
resource supports.  Say =E2=80=9Cscim2=E2=80=9D as an example. =
  I don=E2=80=99t think adding that is however a high priority as =
most if all clients know what API they expect.   It might be useful =
if at some point in the future if a client were to be given a RS URI it =
could check to see if it is a protocol that it supports before bothering =
with OAuth.    I expect that a lot of people will want that =
left to the API definition.   I think we can talk about it but rate =
this low priority.

    I agree that the RS giving out a list of AS that it trusts is =
a generally bad idea.  I hope that is not on the table.

    I don=E2=80=99t think =
that preventing a client from sending a token to the wrong RS is part of =
a AS meta-data discovery problem.

    I do however think that it is =
important.

    We =
have been discussing this as a separate problem to AS meta-data =
discovery where the endpoints of the AS and it=E2=80=99s configuration =
are discovery.   Sorry for perhaps stating the obvious, but the RS =
is explicitly not part of the AS in OAuth 2.   Starting in WAP that =
was a core principal.

    So we have a number of options to address the RS token =
leakage via MiTM attacks.

    1) PoP bound tokens.  If they are bound to the TLS =
channel by mutual TLS or Token binding they cannot be replayed. =
 Signed messages where the signing covers the RS Host and path =
components,  also would work.

    2) Have the AS audience restrict the =
resources the AT is good at. (AT should be doing that =
now) 
    In the token response include the list =
of audience/s the token is presentable at.  The client would throw =
an error if the RS it intends to send the token to is not on the list. =
  The RS the token is good at might change based on scopes, =
client_id and resource owner.   This is the place where all of that =
comes together.   In some cases the RS and AS might not have a =
pre-established relationship.   The client should send the RS base =
URI to the AS as part of the request.  The AS can use that to =
audience restrict the AT and issue the AT or refuse to issue the AT =
based on policy.
    It can also use the audience in =
the request to down audience the AT if the default is to have multiple =
audiences.    We may want to use a term other than audience =
for this like resource or destination.  It is a audience but that =
term might confuse people with AT.

    We did talk about breaking audience out =
of POP key distribution, and Brian Campbell did a draft https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt. =
  

    To =
do this we could take dst4jwt and add another spec that adds a new dst =
parameter to the token and authorization endpoints requests That would =
be a space separated list of dst values.  and in the response from =
the token endpoint would be a JSON array of dst values.

    3) Have the AS always =
return all the list of all RS the token can be used at (basically Nat's =
link relationship proposal).  It needs a way to =
handle 
    down destinationing of AT and to allow =
for un-configured RS that it might issue a token for.  So could be =
combined with dst from 2.  Basically returning the acceptable =
destinations as link headers vs JS in the response is mostly a style =
issue that other people can bike shed.


    4) =
Trying to add all the RS to the AS discovery document.  This seems =
impractical as there would be multiple protocols and doesn=E2=80=99t =
address un-configured RS.

    5) Some new AS endpoint that the client could introspect the =
RS URI and get back metadata about if the client should send tokens =
there.
        A couple of problems with =
this.  The first is that it would not support un-configured RS =
unless you add dst to the token and authorization endpoints.   The =
other is that the introspection endpoint doesn=E2=80=99t have the =
context of the RO and client_id unless you also pass the code/RT and =
client_id, and probably client credentials.    Basically this =
is trying to introspect the AT to determine the audiance/dst.   By =
the time you build a new introspection endpoint securely it is going to =
look like the token endpoint with a bit more meta data about the token =
beyond expiry and scopes.


    I think we should go a =
head with the renamed "OAuth 2.0 Authorization Server Discovery =
Metadata=E2=80=9D 
    I am also fine with making =
the default document 'openid-configuration=E2=80=99  as long as we =
allow for protocol specific variation so that SCIM2 could define a file =
name.    If people want we could do a API  to file name =
registry so that protocol specific ones can be defined.

    We are all-ready working =
on option 1 to secure AT, we need a spec like I propose in 2 for bearer =
tokens.  We can add one request parameter and a bit more token =
meta-data to the token response and that takes care of the problem. =
  Honestly we probably should have separated scope and destination =
in the first place and returned both dst and scope in the response all =
along, so this is update that is consistent with the eisting =
architecture of OAuth 2.

    Lets keep the two issues separate.

    John B.
     



    On =
Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

    The relationship between =
AS and RS need to be scoped to =E2=80=9Cdoes this RS accept tokens from =
this AS=E2=80=9D as a list is too much information that could be used in =
the wrong way
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of Nat Sakimura
    Sent: Thursday, March 10, 2016 =
6:25 PM
    To: Phil Hunt (IDM) <phil.hunt@oracle.com>
    Cc: oauth=
 <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] Working =
Group Last Call on OAuth 2.0 Discovery
     
    Phil, 
     
    Right. So what my conditional approvals (11 =
conditions in total) said was to drop the word "discovery" from =
everywhere. This is not a discovery spec. This is a configuration lookup =
spec as you correctly points out. So, I am with you here. 
     
    Also, my 2nd conditiion is essentially =
saying to drop section 3. 
     
    One thing that I overlooked and am with you is that =
we need to be able to express the AS-RS relationships. I have been =
preaching this in the other thread for so many times as you know so I =
thought I pointed it out, but missed apparently in my previous comment. =
So, I would add my 12th condition: 
     
    12. A way to express a list of valid RSs =
for this AS needs to be added to section 2. 
     
    Best, 
     
    Nat
     
    2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) =
<phil.hunt@oracle.com>:
    I strongly oppose. 2 major issues. 
     
    This is not service discovery this is =
configuration lookup. The client must have already discovered the oauth =
issuer uri and the resource uri. 
     
    The objective was to provide a method to =
ensure the client has a valid set of endpoints to prevent mitm of =
endpoints like the token endpoint to the resource server. 
     
    The draft does not address the issue of a =
client being given a bad endpoint for an rs. What we end up with is a =
promiscuous authz service giving out tokens to an unwitting =
client. 

    Phil

    On=
 Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
    +1 to move forward with these
    On 10/03/16 17:35, Brian Campbell wrote:
    +1
     
    On Thu, Mar 10, =
2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
    wrote:
     
    I support this =
document being moved forward with these two changes:
     
    - change name =
to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=E2=80=9D =
as
    proposed by =
Brian and
    - use =
the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 instead =
of
    =E2=80=99openid-configuration=E2=80=99 as proposed by =
Justin.
     
    18 feb 2016 kl. =
14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net
    :
     
    Hi all,
     
    This is a Last Call for comments on the  =
OAuth 2.0 Discovery
    specification:
    https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
     
    Since this =
document was only adopted recently we are running this last
    call for **3 =
weeks**.
     
    Please have =
your comments in no later than March 10th.
     
    Ciao
    Hannes & Derek
     
    _______________________________________________
    OAuth mailing =
list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    =E2=80=94=
 Roland
     
    =E2=80=9DEverybod=
y should be quiet near a little stream and listen."
    >=46rom =
=E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
     
     
    _______________________________________________
    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
    <=
p class=3D"MsoNormal" style=3D"margin: 0in 0in 12pt; font-size: 12pt; =
font-family: 'Times New Roman', serif;">
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


     
    -- 
    Nat Sakimura (=3Dnat)
    Chairman, OpenID =
Foundation
    http://nat.sakimura.org/
    @_nat_en
    _______________________________________________
    OAuth mailing =
list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    =

--Apple-Mail=_2A6B59B9-E615-40D6-A541-0C83CED17749--

--Apple-Mail=_5A4BD786-117D-4843-A914-B74B5926E893
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTExNDUxNTNaMCMGCSqGSIb3DQEJBDEWBBTQ6Q7Gc+9BGi7gaHojlpGu
BYzsYTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBTM721uY5jvArfzgitDHxdL2iKE6lGi532JRCAMFAQhcGJehvmOkwU
lB7Z6glbBclO/5LitZF9PyHhPip5ge842ZB0SrU22Mrxrd9E0Fql/JdqK236ARV/dHSPd+8EjI1B
DaGuh2x95TNzDu66E/JNbugAQGWwc/7TT/XozUkZnHgvipYDhNihphowS7den0XaDPrY7tGNIsQ1
emVcK0i+5l9rPyNiC3N5yBzkV6Oz/ClGIpRzu4IYF1f3cbBTgWo6WCZB0MemdpxSagmeHVGdTRui
CJMPgNW7HK+kKJKXCYqAXC9bHBARWSodhFtKvVp13fyCiehR8vSy2e+0PmL4AAAAAAAA
--Apple-Mail=_5A4BD786-117D-4843-A914-B74B5926E893--


From nobody Fri Mar 11 07:13:15 2016
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 590FF12D74F for ; Fri, 11 Mar 2016 07:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level: 
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 l-TsGaAeGa-n for ; Fri, 11 Mar 2016 07:13:10 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 8C65E12D7A5 for ; Fri, 11 Mar 2016 07:13:09 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2BFD4R5031972 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Mar 2016 15:13:04 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2BFD3uN028320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2016 15:13:03 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2BFD3Gu003629; Fri, 11 Mar 2016 15:13:03 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Mar 2016 07:13:02 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-BB61F413-A765-4D98-B2F6-7AD007E16BBB
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Fri, 11 Mar 2016 07:13:00 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com>
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>   
To: John Bradley 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 15:13:13 -0000

--Apple-Mail-BB61F413-A765-4D98-B2F6-7AD007E16BBB
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

John

In many case all the AS has to check is the domain name component to check f=
or mitm.=20

POP and the other solns are dramatically more complex than a simple check.=20=


I see it as part of the discovery(bad name aside) problem because we discuss=
ed that if a client finds app.example.com how do we ensure it gets a complet=
e set of oauth endpoints as a valid set of endpoints--that a hacker has not i=
nserted one of their own endpoints. The most important endpoint to get right=
 is ensuring the resource server (and optionally the path) is the correct on=
e. We can't really define resource discovery but we can validate it to some d=
egree.=20

I am not stuck on webfinger or well-known. Because this is config maybe it s=
hould be an oauth endpoint.=20

Phil

> On Mar 11, 2016, at 06:51, John Bradley  wrote:
>=20
> I think Phil is proposing something different.   Should the client send a t=
oken from this AS to that RS. =20
>=20
> His goal is to prevent man in the middle attacks where a bad RS gets a AT t=
hat is audianced to/accepted by another RS.
>=20
> That is separate from the question of if a RS accepts tokens from a good A=
S.   A bad AS would always say yes.
>=20
> We need to be careful of what if anything the RS provides to the client as=
 meta-data without validation.
>=20
> Currently the client can provide a list of scopes required to get access. =
  I personally feel it would be useful to also include in the unauthenticate=
d error response an indication of what API the resource supports.  Say =E2=80=
=9Cscim2=E2=80=9D as an example.   I don=E2=80=99t think adding that is howe=
ver a high priority as most if all clients know what API they expect.   It m=
ight be useful if at some point in the future if a client were to be given a=
 RS URI it could check to see if it is a protocol that it supports before bo=
thering with OAuth.    I expect that a lot of people will want that left to t=
he API definition.   I think we can talk about it but rate this low priority=
.
>=20
> I agree that the RS giving out a list of AS that it trusts is a generally b=
ad idea.  I hope that is not on the table.
>=20
> I don=E2=80=99t think that preventing a client from sending a token to the=
 wrong RS is part of a AS meta-data discovery problem.
>=20
> I do however think that it is important.
>=20
> We have been discussing this as a separate problem to AS meta-data discove=
ry where the endpoints of the AS and it=E2=80=99s configuration are discover=
y.   Sorry for perhaps stating the obvious, but the RS is explicitly not par=
t of the AS in OAuth 2.   Starting in WAP that was a core principal.
>=20
> So we have a number of options to address the RS token leakage via MiTM at=
tacks.
>=20
> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS o=
r Token binding they cannot be replayed.  Signed messages where the signing c=
overs the RS Host and path components,  also would work.
>=20
> 2) Have the AS audience restrict the resources the AT is good at. (AT shou=
ld be doing that now)=20
> In the token response include the list of audience/s the token is presenta=
ble at.  The client would throw an error if the RS it intends to send the to=
ken to is not on the list.   The RS the token is good at might change based o=
n scopes, client_id and resource owner.   This is the place where all of tha=
t comes together.   In some cases the RS and AS might not have a pre-establi=
shed relationship.   The client should send the RS base URI to the AS as par=
t of the request.  The AS can use that to audience restrict the AT and issue=
 the AT or refuse to issue the AT based on policy.
> It can also use the audience in the request to down audience the AT if the=
 default is to have multiple audiences.    We may want to use a term other t=
han audience for this like resource or destination.  It is a audience but th=
at term might confuse people with AT.
>=20
> We did talk about breaking audience out of POP key distribution, and Brian=
 Campbell did a draft https://tools.ietf.org/html/draft-campbell-oauth-dst4j=
wt.  =20
>=20
> To do this we could take dst4jwt and add another spec that adds a new dst p=
arameter to the token and authorization endpoints requests That would be a s=
pace separated list of dst values.  and in the response from the token endpo=
int would be a JSON array of dst values.
>=20
> 3) Have the AS always return all the list of all RS the token can be used a=
t (basically Nat's link relationship proposal).  It needs a way to handle=20=

> down destinationing of AT and to allow for un-configured RS that it might i=
ssue a token for.  So could be combined with dst from 2.  Basically returnin=
g the acceptable destinations as link headers vs JS in the response is mostl=
y a style issue that other people can bike shed.
>=20
>=20
> 4) Trying to add all the RS to the AS discovery document.  This seems impr=
actical as there would be multiple protocols and doesn=E2=80=99t address un-=
configured RS.
>=20
> 5) Some new AS endpoint that the client could introspect the RS URI and ge=
t back metadata about if the client should send tokens there.
>     A couple of problems with this.  The first is that it would not suppor=
t un-configured RS unless you add dst to the token and authorization endpoin=
ts.   The other is that the introspection endpoint doesn=E2=80=99t have the c=
ontext of the RO and client_id unless you also pass the code/RT and client_i=
d, and probably client credentials.    Basically this is trying to introspec=
t the AT to determine the audiance/dst.   By the time you build a new intros=
pection endpoint securely it is going to look like the token endpoint with a=
 bit more meta data about the token beyond expiry and scopes.
>=20
>=20
> I think we should go a head with the renamed "OAuth 2.0 Authorization Serv=
er Discovery Metadata=E2=80=9D=20
> I am also fine with making the default document 'openid-configuration=E2=80=
=99  as long as we allow for protocol specific variation so that SCIM2 could=
 define a file name.    If people want we could do a API  to file name regis=
try so that protocol specific ones can be defined.
>=20
> We are all-ready working on option 1 to secure AT, we need a spec like I p=
ropose in 2 for bearer tokens.  We can add one request parameter and a bit m=
ore token meta-data to the token response and that takes care of the problem=
.   Honestly we probably should have separated scope and destination in the f=
irst place and returned both dst and scope in the response all along, so thi=
s is update that is consistent with the eisting architecture of OAuth 2.
>=20
> Lets keep the two issues separate.
>=20
> John B.
> =20
>=20
>=20
>=20
>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin  wro=
te:
>>=20
>> The relationship between AS and RS need to be scoped to =E2=80=9Cdoes thi=
s RS accept tokens from this AS=E2=80=9D as a list is too much information t=
hat could be used in the wrong way
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
>> Sent: Thursday, March 10, 2016 6:25 PM
>> To: Phil Hunt (IDM) 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>> =20
>> Phil,=20
>> =20
>> Right. So what my conditional approvals (11 conditions in total) said was=
 to drop the word "discovery" from everywhere. This is not a discovery spec.=
 This is a configuration lookup spec as you correctly points out. So, I am w=
ith you here.=20
>> =20
>> Also, my 2nd conditiion is essentially saying to drop section 3.=20
>> =20
>> One thing that I overlooked and am with you is that we need to be able to=
 express the AS-RS relationships. I have been preaching this in the other th=
read for so many times as you know so I thought I pointed it out, but missed=
 apparently in my previous comment. So, I would add my 12th condition:=20
>> =20
>> 12. A way to express a list of valid RSs for this AS needs to be added to=
 section 2.=20
>> =20
>> Best,=20
>> =20
>> Nat
>> =20
>> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>> I strongly oppose. 2 major issues.=20
>> =20
>> This is not service discovery this is configuration lookup. The client mu=
st have already discovered the oauth issuer uri and the resource uri.=20
>> =20
>> The objective was to provide a method to ensure the client has a valid se=
t of endpoints to prevent mitm of endpoints like the token endpoint to the r=
esource server.=20
>> =20
>> The draft does not address the issue of a client being given a bad endpoi=
nt for an rs. What we end up with is a promiscuous authz service giving out t=
okens to an unwitting client.=20
>>=20
>> Phil
>>=20
>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  w=
rote:
>>=20
>> +1 to move forward with these
>>=20
>> On 10/03/16 17:35, Brian Campbell wrote:
>> +1
>> =20
>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
>> wrote:
>> =20
>> I support this document being moved forward with these two changes:
>> =20
>> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
>> proposed by Brian and
>> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
>> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>> =20
>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig > :
>> =20
>> Hi all,
>> =20
>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>> specification:
>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>> =20
>> Since this document was only adopted recently we are running this last
>> call for **3 weeks**.
>> =20
>> Please have your comments in no later than March 10th.
>> =20
>> Ciao
>> Hannes & Derek
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =E2=80=94 Roland
>> =20
>> =E2=80=9DEverybody should be quiet near a little stream and listen."
>> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>> =20
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> =20
>> =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
>>=20
>>=20
>>=20
>> =20
>> --=20
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-BB61F413-A765-4D98-B2F6-7AD007E16BBB
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    John

    In many case all the AS has to c=
heck is the domain name component to check for mitm. 

    POP and the othe=
r solns are dramatically more complex than a simple check. 

    I see it a=
s part of the discovery(bad name aside) problem because we discussed that if=
 a client finds app.example.com how d=
o we ensure it gets a complete set of oauth endpoints as a valid set of endp=
oints--that a hacker has not inserted one of their own endpoints. The most i=
mportant endpoint to get right is ensuring the resource server (and optional=
ly the path) is the correct one. We can't really define resource discovery b=
ut we can validate it to some degree. 

    I am not stuck on webfinger or w=
ell-known. Because this is config maybe it should be an oauth endpoint. =
;

    Phil

    On Mar 11, 2016, at 06:51, John Bradley <ve7jtb@ve7jtb.com> wrote:

    I think Phil is proposing something different. &=
nbsp; Should the client send a token from this AS to that RS.  

    His goal is to prevent man in t=
he middle attacks where a bad RS gets a AT that is audianced to/accepted by a=
nother RS.

    That is=
 separate from the question of if a RS accepts tokens from a good AS.  =
 A bad AS would always say yes.

    We need to be careful of what if anything the RS provides to t=
he client as meta-data without validation.

    Currently the client can provide a list of scopes r=
equired to get access.   I personally feel it would be useful to also i=
nclude in the unauthenticated error response an indication of what API the r=
esource supports.  Say =E2=80=9Cscim2=E2=80=9D as an example.   I d=
on=E2=80=99t think adding that is however a high priority as most if all cli=
ents know what API they expect.   It might be useful if at some point i=
n the future if a client were to be given a RS URI it could check to see if i=
t is a protocol that it supports before bothering with OAuth.    I=
 expect that a lot of people will want that left to the API definition. &nbs=
p; I think we can talk about it but rate this low priority.

    I agree that the RS giving out a lis=
t of AS that it trusts is a generally bad idea.  I hope that is not on t=
he table.

    I don=E2=
=80=99t think that preventing a client from sending a token to the wrong RS i=
s part of a AS meta-data discovery problem.

    I do however think that it is important.

    We have been discussing this a=
s a separate problem to AS meta-data discovery where the endpoints of the AS=
 and it=E2=80=99s configuration are discovery.   Sorry for perhaps stat=
ing the obvious, but the RS is explicitly not part of the AS in OAuth 2. &nb=
sp; Starting in WAP that was a core principal.

    So we have a number of options to address the R=
S token leakage via MiTM attacks.

    =

    1) PoP bound tokens.  If they are bound to the TLS chan=
nel by mutual TLS or Token binding they cannot be replayed.  Signed mes=
sages where the signing covers the RS Host and path components,  also w=
ould work.

    2) Have=
 the AS audience restrict the resources the AT is good at. (AT should be doi=
ng that now) 
    In the token response include the li=
st of audience/s the token is presentable at.  The client would throw a=
n error if the RS it intends to send the token to is not on the list.  =
 The RS the token is good at might change based on scopes, client_id and res=
ource owner.   This is the place where all of that comes together. &nbs=
p; In some cases the RS and AS might not have a pre-established relationship=
.   The client should send the RS base URI to the AS as part of the req=
uest.  The AS can use that to audience restrict the AT and issue the AT=
 or refuse to issue the AT based on policy.
    It can also=
 use the audience in the request to down audience the AT if the default is t=
o have multiple audiences.    We may want to use a term other than=
 audience for this like resource or destination.  It is a audience but t=
hat term might confuse people with AT.

    <=
/div>
    We did talk about breaking audience out of POP key dist=
ribution, and Brian Campbell did a draft https://tools.ietf.org/htm=
l/draft-campbell-oauth-dst4jwt.   

    To do this we could take dst4jwt and add anot=
her spec that adds a new dst parameter to the token and authorization endpoi=
nts requests That would be a space separated list of dst values.  and i=
n the response from the token endpoint would be a JSON array of dst values.<=
/div>

    3) Have the AS alw=
ays return all the list of all RS the token can be used at (basically Nat's l=
ink relationship proposal).  It needs a way to handle 
    down destinationing of AT and to allow for un-configured RS that i=
t might issue a token for.  So could be combined with dst from 2.  =
;Basically returning the acceptable destinations as link headers vs JS in th=
e response is mostly a style issue that other people can bike shed.


    4) Trying to add all the RS to the AS discovery document.  Th=
is seems impractical as there would be multiple protocols and doesn=E2=80=99=
t address un-configured RS.

    5) Some new AS endpoint that the client could introspect the RS UR=
I and get back metadata about if the client should send tokens there.
    <=
div class=3D"">    A couple of problems with this.  The first=
 is that it would not support un-configured RS unless you add dst to the tok=
en and authorization endpoints.   The other is that the introspection e=
ndpoint doesn=E2=80=99t have the context of the RO and client_id unless you a=
lso pass the code/RT and client_id, and probably client credentials.   &=
nbsp;Basically this is trying to introspect the AT to determine the audiance=
/dst.   By the time you build a new introspection endpoint securely it i=
s going to look like the token endpoint with a bit more meta data about the t=
oken beyond expiry and scopes.


    I think we should go a hea=
d with the renamed "OAuth 2.0 Authorization Server Discovery Metadata=E2=80=9D=
 
    I am also fine with making the default document '=
openid-configuration=E2=80=99  as long as we allow for protocol specifi=
c variation so that SCIM2 could define a file name.    If people w=
ant we could do a API  to file name registry so that protocol specific o=
nes can be defined.

    We are all-ready working on option 1 to secure AT, we need a spec like I p=
ropose in 2 for bearer tokens.  We can add one request parameter and a b=
it more token meta-data to the token response and that takes care of the pro=
blem.   Honestly we probably should have separated scope and destinatio=
n in the first place and returned both dst and scope in the response all alo=
ng, so this is update that is consistent with the eisting architecture of OA=
uth 2.

    Lets keep t=
he two issues separate.

    John B.
     



    =

    On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

    The relationship between A=
S and RS need to be scoped to =E2=80=9Cdoes this RS accept tokens from this A=
S=E2=80=9D as a list is too much information that could be used in the wrong=
 way
     <=
/div>
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
    Sent: Thursday, M=
arch 10, 2016 6:25 PM
    To: Phil Hunt (IDM) <phil.hunt@oracle.com>
    Cc: oauth <=
oauth@ietf.org>
    Subject: =
Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
    &=
nbsp;
    Phil, =

    =
 
    Right. So what my conditional approvals (11 conditions in total)=
 said was to drop the word "discovery" from everywhere. This is not a discov=
ery spec. This is a configuration lookup spec as you correctly points out. S=
o, I am with you here. 
     
    Also, my 2nd conditiion is ess=
entially saying to drop section 3. 
     
    One thing that I o=
verlooked and am with you is that we need to be able to express the AS-RS re=
lationships. I have been preaching this in the other thread for so many time=
s as you know so I thought I pointed it out, but missed apparently in my pre=
vious comment. So, I would add my 12th condition: 
     
    12.=
 A way to express a list of valid RSs for this AS needs to be added to secti=
on 2. 
     
    Best, 
     
    Nat
     
    2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
    =

    =

    I strongly oppose. 2 major issues. 
     
    This is not service discovery this is configuration lookup. The=
 client must have already discovered the oauth issuer uri and the resource u=
ri. 
     
    The objective was to provide a method to ensure th=
e client has a valid set of endpoints to prevent mitm of endpoints like the t=
oken endpoint to the resource server. 
     
    The draft does n=
ot address the issue of a client being given a bad endpoint for an rs. What w=
e end up with is a promiscuous authz service giving out tokens to an unwitti=
ng client. 

    Phil

    On Mar 10, 2016, at 08:06, Vladim=
ir Dzhuvinov <vladimir@c=
onnect2id.com> wrote:
    +1 to move forward with these
    On 10/03/16 17:35, B=
rian Campbell wrote:
    +1
     
    On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
    wrote:<=
/pre>
     
    I s=
upport this document being moved forward with these two changes:
     
    pr=
oposed by Brian and
    - use th=
e URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 instead of
    =E2=80=99openid-configuration=E2=
=80=99 as proposed by Justin.
     
    18 feb 2016 kl. 14:40 skr=
ev Hannes Tschofenig <=
hannes.tschofenig@gmx.net
    :
     
    Hi all,
     
    This is a L=
ast Call for comments on the  OAuth 2.0 Discovery=

    specification:<=
/pre>
    <=
pre style=3D"margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courie=
r New';" class=3D"">https://tools.ietf.org/html/draft-iet=
f-oauth-discovery-01
     
    Since this document was o=
nly adopted recently we are running this last
    call for **3 weeks**.
     
    Please have=
 your comments in no later than March 10th.
    Ciao
    Hannes & Derek
     
    OAuth mailing list<=
/pre>
    OAuth@ietf=
.org
    https://www=
.ietf.org/mailman/listinfo/oauth
    =E2=80=94 Roland
     
    =E2=80=9DEv=
erybody should be quiet near a little stream and listen."
    >=46rom =E2=80=99Open House for Butterflies=
=E2=80=99 by Ruth Krauss
     
     
    _____________________________________________=
__
    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/oaut=
h

    ___________________=
____________________________
    OAuth mailing list
    =
OAuth@ietf.org
    https://www.ie=
tf.org/mailman/listinfo/oauth


     
    --<=
span class=3D"Apple-converted-space"> 
    Nat Sakimura (=3Dnat)
    Chairm=
an, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en
    _______________________________________________<=
br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; orphans: aut=
o; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cla=
ss=3D"">OAuth mailing lis=
t
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oau=
th

    =

--Apple-Mail-BB61F413-A765-4D98-B2F6-7AD007E16BBB--


From nobody Fri Mar 11 08:01:38 2016
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 EAB8D12D777 for ; Fri, 11 Mar 2016 08:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.013
X-Spam-Level: 
X-Spam-Status: No, score=-0.013 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 PGawf6l6dTnB for ; Fri, 11 Mar 2016 08:01:34 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92C812D71B for ; Fri, 11 Mar 2016 08:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Un2+yrCyhXvh6eTsjOclZtrfgjaoEIoA2qZi2nKUxCM=; b=ePWdlIsHDyZl+ovMCiGRZn7W0vRXavsbQEvIm/9ng+v5eY9PsY3Apu4p2aiNcN33hiY7ty4wBsyE9cdKyrSYXKaYV5xLawig6Sf7Gcrwz8jIKCzLsfS1gG9r+z7VXSwCS169sMyb2ChSedQDHZS6OTusnNbXqO/SYg+FQUz+f8A=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 11 Mar 2016 16:01:31 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0427.020; Fri, 11 Mar 2016 16:01:31 +0000
From: Anthony Nadalin 
To: "Phil Hunt (IDM)" , Vladimir Dzhuvinov 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH06DIAQfC9O0686lpsTuUfK59Sxh0AgAAqNQCAAAiJgIAAEaoAgAF+WvA=
Date: Fri, 11 Mar 2016 16:01:31 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>
In-Reply-To: <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:4::9b]
x-ms-office365-filtering-correlation-id: 34f81fd0-e51b-4def-28b4-08d349c669ec
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 5:iwLVAhXp8mYpRN7RBj2DlW+CQNhbesVRYmosf2n1pvxkfYjaw5wGsdwnHJhz3TXvV1S/erbEWzMdmTpDcJ/gDEJYuQyt4JnnMbEtO1HzC9SFk81F9e+hRgYjMj0kNQiunDikUE/tdFoFxCb5JVEmsQ==; 24:D+4ZuHqQireEybHbYgTOU8MNYAxXJ1cDTS4PspBD1XvdfoK/8GWgXldzcZoBg90Fd8l5vSleaaIPbSX57NZzaF6T4gggLMqfhEiKUNq1bzE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; 
x-forefront-prvs: 087894CD3C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(24454002)(377454003)(53754006)(479174004)(77096005)(15975445007)(5001770100001)(586003)(86362001)(6116002)(790700001)(74316001)(5008740100001)(92566002)(86612001)(102836003)(10090500001)(3280700002)(5003600100002)(10290500002)(3660700001)(189998001)(8990500004)(4326007)(2906002)(5002640100001)(5005710100001)(2900100001)(2950100001)(10400500002)(76576001)(122556002)(19609705001)(19617315012)(81166005)(93886004)(16236675004)(19300405004)(19625215002)(19580405001)(87936001)(5004730100002)(33656002)(76176999)(1220700001)(50986999)(54356999)(19580395003)(106116001)(99286002)(1096002)(11100500001)(3826002)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234677D30C6A37A8DF95004A6B50BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 16:01:31.6308 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 16:01:37 -0000

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

VGhlcmUgaGF2ZSBiZWVuIHdheSB0b28gbWFueSBpc3N1ZXMsIGNvbmZ1c2VkIGNvbnZlcnNhdGlv
bnMgYW5kIGRpc2N1c3Npb25zIG9uIGFuZCBvZmYgbGlzdCB0byBoYXZlIHRoaXMgZG9jdW1lbnQg
bW92ZSBmb3J3YXJkLCBzdWdnZXN0IHRoYXQgdGhpcyBiZSBvbmUgb2YgdGhlIG1haW4gaXRlbXMg
b24gdGhlIGFnZW5kYSBmb3Igd2hlbiB3ZSBtZWV0Lg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQgKElETSkNClNlbnQ6
IFRodXJzZGF5LCBNYXJjaCAxMCwgMjAxNiA5OjA5IEFNDQpUbzogVmxhZGltaXIgRHpodXZpbm92
IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDog
UmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2Nv
dmVyeQ0KDQpJIHN0cm9uZ2x5IG9wcG9zZS4gMiBtYWpvciBpc3N1ZXMuDQoNClRoaXMgaXMgbm90
IHNlcnZpY2UgZGlzY292ZXJ5IHRoaXMgaXMgY29uZmlndXJhdGlvbiBsb29rdXAuIFRoZSBjbGll
bnQgbXVzdCBoYXZlIGFscmVhZHkgZGlzY292ZXJlZCB0aGUgb2F1dGggaXNzdWVyIHVyaSBhbmQg
dGhlIHJlc291cmNlIHVyaS4NCg0KVGhlIG9iamVjdGl2ZSB3YXMgdG8gcHJvdmlkZSBhIG1ldGhv
ZCB0byBlbnN1cmUgdGhlIGNsaWVudCBoYXMgYSB2YWxpZCBzZXQgb2YgZW5kcG9pbnRzIHRvIHBy
ZXZlbnQgbWl0bSBvZiBlbmRwb2ludHMgbGlrZSB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gdGhlIHJl
c291cmNlIHNlcnZlci4NCg0KVGhlIGRyYWZ0IGRvZXMgbm90IGFkZHJlc3MgdGhlIGlzc3VlIG9m
IGEgY2xpZW50IGJlaW5nIGdpdmVuIGEgYmFkIGVuZHBvaW50IGZvciBhbiBycy4gV2hhdCB3ZSBl
bmQgdXAgd2l0aCBpcyBhIHByb21pc2N1b3VzIGF1dGh6IHNlcnZpY2UgZ2l2aW5nIG91dCB0b2tl
bnMgdG8gYW4gdW53aXR0aW5nIGNsaWVudC4NCg0KUGhpbA0KDQpPbiBNYXIgMTAsIDIwMTYsIGF0
IDA4OjA2LCBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0
bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KKzEgdG8gbW92ZSBmb3J3YXJkIHdp
dGggdGhlc2UNCk9uIDEwLzAzLzE2IDE3OjM1LCBCcmlhbiBDYW1wYmVsbCB3cm90ZToNCg0KKzEN
Cg0KDQoNCk9uIFRodSwgTWFyIDEwLCAyMDE2IGF0IDY6MDQgQU0sIFJvbGFuZCBIZWRiZXJnIDxy
b2xhbmQuaGVkYmVyZ0B1bXUuc2U+PG1haWx0bzpyb2xhbmQuaGVkYmVyZ0B1bXUuc2U+DQoNCndy
b3RlOg0KDQoNCg0KSSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgYmVpbmcgbW92ZWQgZm9yd2FyZCB3
aXRoIHRoZXNlIHR3byBjaGFuZ2VzOg0KDQoNCg0KLSBjaGFuZ2UgbmFtZSB0byDigJxPQXV0aCAy
LjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCdIGFzDQoNCnByb3Bv
c2VkIGJ5IEJyaWFuIGFuZA0KDQotIHVzZSB0aGUgVVJJIHBhdGggc3VmZml4IOKAmW9hdXRoLWF1
dGhvcml6YXRpb24tc2VydmVy4oCZIGluc3RlYWQgb2YNCg0K4oCZb3BlbmlkLWNvbmZpZ3VyYXRp
b27igJkgYXMgcHJvcG9zZWQgYnkgSnVzdGluLg0KDQoNCg0KMTggZmViIDIwMTYga2wuIDE0OjQw
IHNrcmV2IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0
bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pg0KDQo6DQoNCg0KDQpIaSBhbGwsDQoNCg0KDQpU
aGlzIGlzIGEgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiB0aGUgIE9BdXRoIDIuMCBEaXNjb3Zl
cnkNCg0Kc3BlY2lmaWNhdGlvbjoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJm
ZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2NhZWVmZjBjZjBiNWQ0NGQ4YWRlODA4ZDM0OTA3M2I1ZCU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1DZGtWdmZOQnJNaG8wRmhmcmk5SjNX
WHp0Y2pjVzJqSVBJN3l2JTJmN2hmNkElM2Q+DQoNCg0KDQpTaW5jZSB0aGlzIGRvY3VtZW50IHdh
cyBvbmx5IGFkb3B0ZWQgcmVjZW50bHkgd2UgYXJlIHJ1bm5pbmcgdGhpcyBsYXN0DQoNCmNhbGwg
Zm9yICoqMyB3ZWVrcyoqLg0KDQoNCg0KUGxlYXNlIGhhdmUgeW91ciBjb21tZW50cyBpbiBubyBs
YXRlciB0aGFuIE1hcmNoIDEwdGguDQoNCg0KDQpDaWFvDQoNCkhhbm5lcyAmIERlcmVrDQoNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0
aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEw
MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3
LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9u
eW5hZCU0MG1pY3Jvc29mdC5jb20lN2NhZWVmZjBjZjBiNWQ0NGQ4YWRlODA4ZDM0OTA3M2I1ZCU3
YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT11bTZBNU5YZ3lwdk5F
ZEFHQkVhdG0xc0toRzd5aU9FZnNEQWdXdmdqakM0JTNkPg0KDQrigJQgUm9sYW5kDQoNCg0KDQri
gJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0
ZW4uIg0KDQpGcm9tIOKAmU9wZW4gSG91c2UgZm9yIEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3Jh
dXNzDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw
cyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9
MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYWVlZmYwY2YwYjVkNDRkOGFkZTgw
OGQzNDkwNzNiNWQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9
dW02QTVOWGd5cHZORWRBR0JFYXRtMXNLaEc3eWlPRWZzREFnV3ZnampDNCUzZD4NCg0KDQoNCg0K
DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBz
Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm
JTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAx
JTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NhZWVmZjBjZjBiNWQ0NGQ4YWRlODA4ZDM0OTA3
M2I1ZCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT11bTZBNU5Y
Z3lwdk5FZEFHQkVhdG0xc0toRzd5aU9FZnNEQWdXdmdqakM0JTNkPg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs
IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h
bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFBy
ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
VGhlcmUgaGF2ZSBiZWVuIHdheSB0b28gbWFueSBpc3N1ZXMsIGNvbmZ1c2VkIGNvbnZlcnNhdGlv
bnMgYW5kIGRpc2N1c3Npb25zIG9uIGFuZCBvZmYgbGlzdCB0byBoYXZlIHRoaXMgZG9jdW1lbnQg
bW92ZSBmb3J3YXJkLCBzdWdnZXN0IHRoYXQgdGhpcyBiZSBvbmUgb2YgdGhlIG1haW4gaXRlbXMg
b24NCiB0aGUgYWdlbmRhIGZvciB3aGVuIHdlIG1lZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQgKElETSk8YnI+
DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2IDk6MDkgQU08YnI+DQo8Yj5U
bzo8L2I+IFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7dmxhZGltaXJAY29ubmVjdDJpZC5jb20mZ3Q7
PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg
c3Ryb25nbHkgb3Bwb3NlLiAyIG1ham9yIGlzc3Vlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1
cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBub3Qgc2VydmljZSBkaXNjb3Zlcnkg
dGhpcyBpcyBjb25maWd1cmF0aW9uIGxvb2t1cC4gVGhlIGNsaWVudCBtdXN0IGhhdmUgYWxyZWFk
eSBkaXNjb3ZlcmVkIHRoZSBvYXV0aCBpc3N1ZXIgdXJpIGFuZCB0aGUgcmVzb3VyY2UgdXJpLiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb2Jq
ZWN0aXZlIHdhcyB0byBwcm92aWRlIGEgbWV0aG9kIHRvIGVuc3VyZSB0aGUgY2xpZW50IGhhcyBh
IHZhbGlkIHNldCBvZiBlbmRwb2ludHMgdG8gcHJldmVudCBtaXRtIG9mIGVuZHBvaW50cyBsaWtl
IHRoZSB0b2tlbiBlbmRwb2ludCB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxl
TWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgZG9lcyBub3Qg
YWRkcmVzcyB0aGUgaXNzdWUgb2YgYSBjbGllbnQgYmVpbmcgZ2l2ZW4gYSBiYWQgZW5kcG9pbnQg
Zm9yIGFuIHJzLiBXaGF0IHdlIGVuZCB1cCB3aXRoIGlzIGEgcHJvbWlzY3VvdXMgYXV0aHogc2Vy
dmljZSBnaXZpbmcgb3V0IHRva2VucyB0byBhbiB1bndpdHRpbmcgY2xpZW50LiZuYnNwOzxicj4N
Cjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWFyIDEwLCAyMDE2
LCBhdCAwODowNiwgVmxhZGltaXIgRHpodXZpbm92ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGlt
aXJAY29ubmVjdDJpZC5jb20iPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9hPiZndDsgd3JvdGU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+JiM0MzsxIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRo
ZXNlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTAvMDMv
MTYgMTc6MzUsIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwcmU+JiM0MzsxPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+T24gVGh1LCBNYXIgMTAsIDIwMTYgYXQgNjowNCBBTSwgUm9sYW5kIEhlZGJlcmcg
PGEgaHJlZj0ibWFpbHRvOnJvbGFuZC5oZWRiZXJnQHVtdS5zZSI+Jmx0O3JvbGFuZC5oZWRiZXJn
QHVtdS5zZSZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+d3JvdGU6PG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5JIHN1cHBvcnQgdGhp
cyBkb2N1bWVudCBiZWluZyBtb3ZlZCBmb3J3YXJkIHdpdGggdGhlc2UgdHdvIGNoYW5nZXM6PG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LSBjaGFu
Z2UgbmFtZSB0byDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ5IE1l
dGFkYXRh4oCdIGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+cHJvcG9zZWQgYnkgQnJpYW4gYW5k
PG86cD48L286cD48L3ByZT4NCjxwcmU+LSB1c2UgdGhlIFVSSSBwYXRoIHN1ZmZpeCDigJlvYXV0
aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAmSBpbnN0ZWFkIG9mPG86cD48L286cD48L3ByZT4NCjxw
cmU+4oCZb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgYXMgcHJvcG9zZWQgYnkgSnVzdGluLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+MTggZmVi
IDIwMTYga2wuIDE0OjQwIHNrcmV2IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWls
dG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT46PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+SGkgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgaXMgYSBMYXN0IENhbGwgZm9yIGNvbW1l
bnRzIG9uIHRoZSZuYnNwOyBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48L286cD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwcmU+c3BlY2lmaWNhdGlvbjo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
PjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi1vYXV0
aC1kaXNjb3ZlcnktMDEmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29t
JTdjYWVlZmYwY2YwYjVkNDRkOGFkZTgwOGQzNDkwNzNiNWQlN2M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUNka1Z2Zk5Cck1obzBGaGZyaTlKM1dYenRjamNX
MmpJUEk3eXYlMmY3aGY2QSUzZCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll
dGYtb2F1dGgtZGlzY292ZXJ5LTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNpbmNlIHRoaXMgZG9jdW1lbnQgd2FzIG9ubHkgYWRvcHRl
ZCByZWNlbnRseSB3ZSBhcmUgcnVubmluZyB0aGlzIGxhc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5jYWxsIGZvciAqKjMgd2Vla3MqKi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2UgaGF2ZSB5b3VyIGNvbW1lbnRzIGluIG5vIGxhdGVy
IHRoYW4gTWFyY2ggMTB0aC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5DaWFvPG86cD48L286cD48L3ByZT4NCjxwcmU+SGFubmVzICZhbXA7IERl
cmVrPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUy
Zmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjYWVlZmYwY2YwYjVkNDRkOGFkZTgwOGQzNDkwNzNiNWQlN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXVtNkE1TlhneXB2TkVkQUdCRWF0bTFzS2hH
N3lpT0Vmc0RBZ1d2Z2pqQzQlM2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+4oCUIFJv
bGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PuKAnUV2ZXJ5Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBhIGxpdHRsZSBzdHJlYW0gYW5kIGxp
c3Rlbi4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tIOKAmU9wZW4gSG91c2UgZm9y
IEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUy
Zmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjYWVlZmYwY2YwYjVkNDRkOGFkZTgwOGQzNDkwNzNiNWQlN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXVtNkE1TlhneXB2TkVkQUdCRWF0bTFzS2hH
N3lpT0Vmc0RBZ1d2Z2pqQzQlM2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlz
dGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20l
N2NhZWVmZjBjZjBiNWQ0NGQ4YWRlODA4ZDM0OTA3M2I1ZCU3YzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9dW02QTVOWGd5cHZORWRBR0JFYXRtMXNLaEc3eWlP
RWZzREFnV3ZnampDNCUzZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BN3PR0301MB1234677D30C6A37A8DF95004A6B50BN3PR0301MB1234_--


From nobody Fri Mar 11 08:34:10 2016
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 4CFD812D923 for ; Fri, 11 Mar 2016 08:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level: 
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 922KcUcgkL80 for ; Fri, 11 Mar 2016 08:34:06 -0800 (PST)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 59DF212D8CF for ; Fri, 11 Mar 2016 08:08:11 -0800 (PST)
Received: by mail-qg0-x236.google.com with SMTP id u110so101723844qge.3 for ; Fri, 11 Mar 2016 08:08:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=NLRA4hDS1azhNFolzhOcHQSWTKnFkjJN7e9A5P88rB8=; b=FHWSCcJ8g3vgKhDEocw2C23bpo9ubZ/PVF4MjtWx48rOZtTd0lUiyy0s7XrDbvbR/N dDa6CE3BUqn2oKhDvNnIBLAXuldU+qVZmU0NzFYUpqNVA/WHWoeg05k8Rou+W5QMzHYW xkONlD8X4rRYBB++g41gnuHLczA/CUvdQ4W36zrIqM57Pl44U7/wzS6IU75TArX6Cc6y BTgmTiIuX8Y1spdsxT5iHFm7UPMBtywh59KZ0NZTAwIcTMPu41GFUQRD+mXHNlY/mDnn Ugq+nye3Nh03uOxrZZ90RkyicTmUtmRfDp1o2J5vpA366rW4Jdt90PwyBBr9630tnnmM dm5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NLRA4hDS1azhNFolzhOcHQSWTKnFkjJN7e9A5P88rB8=; b=P87eH/oen9dzyQ6ZROezNqKU0XNt5brNe5A1FGkcAI77iYTdOSm7pLXyXwZVq6a5c6 GqagKHtvQSCdGNBTXlLVXwxpXHQpV3IKd2z656JCgaG6mpedU5+pWbgNWtTvqcDt3vSQ /ZZk0zDK7Y8aENy5NsJ4Pi7kv7a9k12L1cgSlDjn4+0UuxVpI0WFkxVOlfdieEXufrH7 rCNbuTmCzIUZqlSy1tvwQKOvfSy0MIAC3NoYmVSySaQySYYf79NUHKupKna+N/HkJGQr t3zWKwNddkslGunwv9rVpQdnwdeCuEo7uc07hli7c827KQAKNeBTEKdxEQ5sFFnJ9zqW Rhiw==
X-Gm-Message-State: AD7BkJJ9sw7gf/ds44Y0RmHswBAJE7jrDIMHfptlffCK7xAFAKPWYAixzFoS4lgSdMIxCg==
X-Received: by 10.140.34.170 with SMTP id l39mr5576138qgl.52.1457712490335; Fri, 11 Mar 2016 08:08:10 -0800 (PST)
Received: from [192.168.8.101] ([181.202.152.189]) by smtp.gmail.com with ESMTPSA id c190sm4244260qkb.27.2016.03.11.08.08.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Mar 2016 08:08:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BB67A04D-B302-494D-8972-659B1C8DD1D6"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com>
Date: Fri, 11 Mar 2016 13:08:04 -0300
Message-Id: <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com>
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 16:34:09 -0000

--Apple-Mail=_BB67A04D-B302-494D-8972-659B1C8DD1D6
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D9C0A4A5-853D-4760-B47D-24D4FD6752D0"


--Apple-Mail=_D9C0A4A5-853D-4760-B47D-24D4FD6752D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Inline
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM)  =
wrote:
>=20
> John
>=20
> In many case all the AS has to check is the domain name component to =
check for mitm.=20
>=20
> POP and the other solns are dramatically more complex than a simple =
check.=20

I was proposing ding that check at the authorization endpoint or token =
endpoint as part of AT issuance.=20

It is up to the AS how much of the path to validate and or put in the =
aud or dst.=20


>=20
> I see it as part of the discovery(bad name aside) problem because we =
discussed that if a client finds app.example.com =
 how do we ensure it gets a complete set of =
oauth endpoints as a valid set of endpoints--that a hacker has not =
inserted one of their own endpoints. The most important endpoint to get =
right is ensuring the resource server (and optionally the path) is the =
correct one. We can't really define resource discovery but we can =
validate it to some degree.=20
>=20
I think it is part of core protocol security and should/must not require =
discovery.=20

What is app.example.com ?=20

If it is the resource then the client would be preconfigured for it=E2=80=99=
s AS out of band or optionally would do discovery on the issuer uri that =
you admit needs to be configured out of band some way (note discovery is =
optional)

In the AS meta-data draft it would do a get on a well known file that =
would have configuration for the AS, but not the RS, though some API may =
optionally list a API endpoint like connect has. =20

The client then makes a authorization request (after registering out of =
band or dynamically). =20
As part of the authorization request for implicit it could provide the =
aud/dst that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed =
and time to live for the token (one extra thing returned)

This doesn=E2=80=99t require any discovery (yes there is a optional AS =
meta-data discovery but not required)

I prefer to fix the RS man in the middle issue as part of the protocol =
and not part of discovery that should remain optional.

I honestly don=E2=80=99t quite know how the client learns about this bad =
RS and starts talking to it, so this may be a solution to a problem that =
doesn=E2=80=99t yet exist.   The one place this is posable is if the =
registration for the client is compromised.  However we are discussing =
other mitigations for that that also explicitly do not require =
discovery.

John B.


> I am not stuck on webfinger or well-known. Because this is config =
maybe it should be an oauth endpoint.=20
>=20
> Phil
>=20
> On Mar 11, 2016, at 06:51, John Bradley > wrote:
>=20
>> I think Phil is proposing something different.   Should the client =
send a token from this AS to that RS. =20
>>=20
>> His goal is to prevent man in the middle attacks where a bad RS gets =
a AT that is audianced to/accepted by another RS.
>>=20
>> That is separate from the question of if a RS accepts tokens from a =
good AS.   A bad AS would always say yes.
>>=20
>> We need to be careful of what if anything the RS provides to the =
client as meta-data without validation.
>>=20
>> Currently the client can provide a list of scopes required to get =
access.   I personally feel it would be useful to also include in the =
unauthenticated error response an indication of what API the resource =
supports.  Say =E2=80=9Cscim2=E2=80=9D as an example.   I don=E2=80=99t =
think adding that is however a high priority as most if all clients know =
what API they expect.   It might be useful if at some point in the =
future if a client were to be given a RS URI it could check to see if it =
is a protocol that it supports before bothering with OAuth.    I expect =
that a lot of people will want that left to the API definition.   I =
think we can talk about it but rate this low priority.
>>=20
>> I agree that the RS giving out a list of AS that it trusts is a =
generally bad idea.  I hope that is not on the table.
>>=20
>> I don=E2=80=99t think that preventing a client from sending a token =
to the wrong RS is part of a AS meta-data discovery problem.
>>=20
>> I do however think that it is important.
>>=20
>> We have been discussing this as a separate problem to AS meta-data =
discovery where the endpoints of the AS and it=E2=80=99s configuration =
are discovery.   Sorry for perhaps stating the obvious, but the RS is =
explicitly not part of the AS in OAuth 2.   Starting in WAP that was a =
core principal.
>>=20
>> So we have a number of options to address the RS token leakage via =
MiTM attacks.
>>=20
>> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual =
TLS or Token binding they cannot be replayed.  Signed messages where the =
signing covers the RS Host and path components,  also would work.
>>=20
>> 2) Have the AS audience restrict the resources the AT is good at. (AT =
should be doing that now)=20
>> In the token response include the list of audience/s the token is =
presentable at.  The client would throw an error if the RS it intends to =
send the token to is not on the list.   The RS the token is good at =
might change based on scopes, client_id and resource owner.   This is =
the place where all of that comes together.   In some cases the RS and =
AS might not have a pre-established relationship.   The client should =
send the RS base URI to the AS as part of the request.  The AS can use =
that to audience restrict the AT and issue the AT or refuse to issue the =
AT based on policy.
>> It can also use the audience in the request to down audience the AT =
if the default is to have multiple audiences.    We may want to use a =
term other than audience for this like resource or destination.  It is a =
audience but that term might confuse people with AT.
>>=20
>> We did talk about breaking audience out of POP key distribution, and =
Brian Campbell did a draft =
https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt =
.  =20
>>=20
>> To do this we could take dst4jwt and add another spec that adds a new =
dst parameter to the token and authorization endpoints requests That =
would be a space separated list of dst values.  and in the response from =
the token endpoint would be a JSON array of dst values.
>>=20
>> 3) Have the AS always return all the list of all RS the token can be =
used at (basically Nat's link relationship proposal).  It needs a way to =
handle=20
>> down destinationing of AT and to allow for un-configured RS that it =
might issue a token for.  So could be combined with dst from 2.  =
Basically returning the acceptable destinations as link headers vs JS in =
the response is mostly a style issue that other people can bike shed.
>>=20
>>=20
>> 4) Trying to add all the RS to the AS discovery document.  This seems =
impractical as there would be multiple protocols and doesn=E2=80=99t =
address un-configured RS.
>>=20
>> 5) Some new AS endpoint that the client could introspect the RS URI =
and get back metadata about if the client should send tokens there.
>>     A couple of problems with this.  The first is that it would not =
support un-configured RS unless you add dst to the token and =
authorization endpoints.   The other is that the introspection endpoint =
doesn=E2=80=99t have the context of the RO and client_id unless you also =
pass the code/RT and client_id, and probably client credentials.    =
Basically this is trying to introspect the AT to determine the =
audiance/dst.   By the time you build a new introspection endpoint =
securely it is going to look like the token endpoint with a bit more =
meta data about the token beyond expiry and scopes.
>>=20
>>=20
>> I think we should go a head with the renamed "OAuth 2.0 Authorization =
Server Discovery Metadata=E2=80=9D=20
>> I am also fine with making the default document =
'openid-configuration=E2=80=99  as long as we allow for protocol =
specific variation so that SCIM2 could define a file name.    If people =
want we could do a API  to file name registry so that protocol specific =
ones can be defined.
>>=20
>> We are all-ready working on option 1 to secure AT, we need a spec =
like I propose in 2 for bearer tokens.  We can add one request parameter =
and a bit more token meta-data to the token response and that takes care =
of the problem.   Honestly we probably should have separated scope and =
destination in the first place and returned both dst and scope in the =
response all along, so this is update that is consistent with the =
eisting architecture of OAuth 2.
>>=20
>> Lets keep the two issues separate.
>>=20
>> John B.
>> =20
>>=20
>>=20
>>=20
>>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin > wrote:
>>>=20
>>> The relationship between AS and RS need to be scoped to =E2=80=9Cdoes =
this RS accept tokens from this AS=E2=80=9D as a list is too much =
information that could be used in the wrong way
>>> =C2=A0 <>
>>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Nat Sakimura
>>> Sent: Thursday, March 10, 2016 6:25 PM
>>> To: Phil Hunt (IDM) >
>>> Cc: oauth >
>>> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 =
Discovery
>>> =20
>>> Phil,=20
>>> =20
>>> Right. So what my conditional approvals (11 conditions in total) =
said was to drop the word "discovery" from everywhere. This is not a =
discovery spec. This is a configuration lookup spec as you correctly =
points out. So, I am with you here.=20
>>> =20
>>> Also, my 2nd conditiion is essentially saying to drop section 3.=20
>>> =20
>>> One thing that I overlooked and am with you is that we need to be =
able to express the AS-RS relationships. I have been preaching this in =
the other thread for so many times as you know so I thought I pointed it =
out, but missed apparently in my previous comment. So, I would add my =
12th condition:=20
>>> =20
>>> 12. A way to express a list of valid RSs for this AS needs to be =
added to section 2.=20
>>> =20
>>> Best,=20
>>> =20
>>> Nat
>>> =20
>>> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) >:
>>> I strongly oppose. 2 major issues.=20
>>> =20
>>> This is not service discovery this is configuration lookup. The =
client must have already discovered the oauth issuer uri and the =
resource uri.=20
>>> =20
>>> The objective was to provide a method to ensure the client has a =
valid set of endpoints to prevent mitm of endpoints like the token =
endpoint to the resource server.=20
>>> =20
>>> The draft does not address the issue of a client being given a bad =
endpoint for an rs. What we end up with is a promiscuous authz service =
giving out tokens to an unwitting client.=20
>>>=20
>>> Phil
>>>=20
>>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov =
> wrote:
>>>=20
>>> +1 to move forward with these
>>>=20
>>> On 10/03/16 17:35, Brian Campbell wrote:
>>> +1
>>> =20
>>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg =
 
>>> wrote:
>>> =20
>>> I support this document being moved forward with these two changes:
>>> =20
>>> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery =
Metadata=E2=80=9D as
>>> proposed by Brian and
>>> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99=
 instead of
>>> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>>> =20
>>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig =

>>> :
>>> =20
>>> Hi all,
>>> =20
>>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>>> specification:
>>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 =

>>> =20
>>> Since this document was only adopted recently we are running this =
last
>>> call for **3 weeks**.
>>> =20
>>> Please have your comments in no later than March 10th.
>>> =20
>>> Ciao
>>> Hannes & Derek
>>> =20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>>> =E2=80=94 Roland
>>> =20
>>> =E2=80=9DEverybody should be quiet near a little stream and listen."
>>> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>>> =20
>>> =20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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

>>>=20
>>>=20
>>> =20
>>> --=20
>>> Nat Sakimura (=3Dnat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/ =

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



--Apple-Mail=_D9C0A4A5-853D-4760-B47D-24D4FD6752D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Inline
    On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) =
<phil.hunt@oracle.com> wrote:

    John

    In many case all the AS =
has to check is the domain name component to check for =
mitm. 

    POP =
and the other solns are dramatically more complex than a simple =
check. 

    I =
was proposing ding that check at the authorization endpoint or token =
endpoint as part of AT issuance. 

    It is up to the AS how much of the path to =
validate and or put in the aud or dst. 



    I see it as part of the =
discovery(bad name aside) problem because we discussed that if a client =
finds app.example.com =
how do we ensure it gets a complete set of oauth endpoints as a valid =
set of endpoints--that a hacker has not inserted one of their own =
endpoints. The most important endpoint to get right is ensuring the =
resource server (and optionally the path) is the correct one. We can't =
really define resource discovery but we can validate it to some =
degree. 

    I think it is part of =
core protocol security and should/must not require =
discovery. 

    What is app.example.com =
? 

    If it is the resource then =
the client would be preconfigured for it=E2=80=99s AS out of band or =
optionally would do discovery on the issuer uri that you admit needs to =
be configured out of band some way (note discovery is =
optional)

    In the AS meta-data draft =
it would do a get on a well known file that would have configuration for =
the AS, but not the RS, though some API may optionally list a API =
endpoint like connect has.  

    The =
client then makes a authorization request (after registering out of band =
or dynamically).  
    As part of the authorization request =
for implicit it could provide the aud/dst that it wants the token =
for.
    If that is not sent then the aud/dst are implicit in the =
scopes.

    The client gets back a AT =
with a list of scopes granted, aud/dst allowed and time to live for the =
token (one extra thing returned)

    This =
doesn=E2=80=99t require any discovery (yes there is a optional AS =
meta-data discovery but not required)

    I prefer to fix the RS man in the middle issue as =
part of the protocol and not part of discovery that should remain =
optional.

    I honestly don=E2=80=99t =
quite know how the client learns about this bad RS and starts talking to =
it, so this may be a solution to a problem that doesn=E2=80=99t yet =
exist.   The one place this is posable is if the registration for =
the client is compromised.  However we are discussing other =
mitigations for that that also explicitly do not require =
discovery.

    John B.


    I am not stuck =
on webfinger or well-known. Because this is config maybe it should be an =
oauth endpoint. 

    Phil

    On Mar 11, 2016, at 06:51, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    I think Phil is =
proposing something different.   Should the client send a token =
from this AS to that RS.  

    His goal is to prevent man in the middle attacks where a bad =
RS gets a AT that is audianced to/accepted by another RS.

    That is separate from =
the question of if a RS accepts tokens from a good AS.   A bad AS =
would always say yes.

    We need to be careful of what if anything the RS provides to =
the client as meta-data without validation.

    Currently the client can provide a list =
of scopes required to get access.   I personally feel it would be =
useful to also include in the unauthenticated error response an =
indication of what API the resource supports.  Say =E2=80=9Cscim2=E2=80=
=9D as an example.   I don=E2=80=99t think adding that is however a =
high priority as most if all clients know what API they expect.   =
It might be useful if at some point in the future if a client were to be =
given a RS URI it could check to see if it is a protocol that it =
supports before bothering with OAuth.    I expect that a lot =
of people will want that left to the API definition.   I think we =
can talk about it but rate this low priority.

    I agree that the RS giving out a list =
of AS that it trusts is a generally bad idea.  I hope that is not =
on the table.

    I =
don=E2=80=99t think that preventing a client from sending a token to the =
wrong RS is part of a AS meta-data discovery problem.

    I do however think that =
it is important.

    We have been discussing this as a separate problem to AS =
meta-data discovery where the endpoints of the AS and it=E2=80=99s =
configuration are discovery.   Sorry for perhaps stating the =
obvious, but the RS is explicitly not part of the AS in OAuth 2.   =
Starting in WAP that was a core principal.

    So we have a number of options to =
address the RS token leakage via MiTM attacks.

    1) PoP bound tokens.  If they are =
bound to the TLS channel by mutual TLS or Token binding they cannot be =
replayed.  Signed messages where the signing covers the RS Host and =
path components,  also would work.

    2) Have the AS audience restrict the =
resources the AT is good at. (AT should be doing that =
now) 
    In the token response include the list =
of audience/s the token is presentable at.  The client would throw =
an error if the RS it intends to send the token to is not on the list. =
  The RS the token is good at might change based on scopes, =
client_id and resource owner.   This is the place where all of that =
comes together.   In some cases the RS and AS might not have a =
pre-established relationship.   The client should send the RS base =
URI to the AS as part of the request.  The AS can use that to =
audience restrict the AT and issue the AT or refuse to issue the AT =
based on policy.
    It can also use the audience in =
the request to down audience the AT if the default is to have multiple =
audiences.    We may want to use a term other than audience =
for this like resource or destination.  It is a audience but that =
term might confuse people with AT.

    We did talk about breaking audience out =
of POP key distribution, and Brian Campbell did a draft https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt. =
  

    To =
do this we could take dst4jwt and add another spec that adds a new dst =
parameter to the token and authorization endpoints requests That would =
be a space separated list of dst values.  and in the response from =
the token endpoint would be a JSON array of dst values.

    3) Have the AS always =
return all the list of all RS the token can be used at (basically Nat's =
link relationship proposal).  It needs a way to =
handle 
    down destinationing of AT and to allow =
for un-configured RS that it might issue a token for.  So could be =
combined with dst from 2.  Basically returning the acceptable =
destinations as link headers vs JS in the response is mostly a style =
issue that other people can bike shed.


    4) =
Trying to add all the RS to the AS discovery document.  This seems =
impractical as there would be multiple protocols and doesn=E2=80=99t =
address un-configured RS.

    5) Some new AS endpoint that the client could introspect the =
RS URI and get back metadata about if the client should send tokens =
there.
        A couple of problems with =
this.  The first is that it would not support un-configured RS =
unless you add dst to the token and authorization endpoints.   The =
other is that the introspection endpoint doesn=E2=80=99t have the =
context of the RO and client_id unless you also pass the code/RT and =
client_id, and probably client credentials.    Basically this =
is trying to introspect the AT to determine the audiance/dst.   By =
the time you build a new introspection endpoint securely it is going to =
look like the token endpoint with a bit more meta data about the token =
beyond expiry and scopes.


    I think we should go a =
head with the renamed "OAuth 2.0 Authorization Server Discovery =
Metadata=E2=80=9D 
    I am also fine with making =
the default document 'openid-configuration=E2=80=99  as long as we =
allow for protocol specific variation so that SCIM2 could define a file =
name.    If people want we could do a API  to file name =
registry so that protocol specific ones can be defined.

    We are all-ready working =
on option 1 to secure AT, we need a spec like I propose in 2 for bearer =
tokens.  We can add one request parameter and a bit more token =
meta-data to the token response and that takes care of the problem. =
  Honestly we probably should have separated scope and destination =
in the first place and returned both dst and scope in the response all =
along, so this is update that is consistent with the eisting =
architecture of OAuth 2.

    Lets keep the two issues separate.

    John B.
     



    On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

    The relationship between =
AS and RS need to be scoped to =E2=80=9Cdoes this RS accept tokens from =
this AS=E2=80=9D as a list is too much information that could be used in =
the wrong way
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of Nat Sakimura
    Sent: Thursday, March 10, 2016 =
6:25 PM
    To: Phil Hunt (IDM) <phil.hunt@oracle.com>
    Cc: oauth=
 <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] Working =
Group Last Call on OAuth 2.0 Discovery
     
    Phil, 
     
    Right. So what my conditional approvals (11 =
conditions in total) said was to drop the word "discovery" from =
everywhere. This is not a discovery spec. This is a configuration lookup =
spec as you correctly points out. So, I am with you here. 
     
    Also, my 2nd conditiion is essentially =
saying to drop section 3. 
     
    One thing that I overlooked and am with you is that =
we need to be able to express the AS-RS relationships. I have been =
preaching this in the other thread for so many times as you know so I =
thought I pointed it out, but missed apparently in my previous comment. =
So, I would add my 12th condition: 
     
    12. A way to express a list of valid RSs =
for this AS needs to be added to section 2. 
     
    Best, 
     
    Nat
     
    2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) =
<phil.hunt@oracle.com>:
    I strongly oppose. 2 major issues. 
     
    This is not service discovery this is =
configuration lookup. The client must have already discovered the oauth =
issuer uri and the resource uri. 
     
    The objective was to provide a method to =
ensure the client has a valid set of endpoints to prevent mitm of =
endpoints like the token endpoint to the resource server. 
     
    The draft does not address the issue of a =
client being given a bad endpoint for an rs. What we end up with is a =
promiscuous authz service giving out tokens to an unwitting =
client. 

    Phil

    On=
 Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
    +1 to move forward with these
    On 10/03/16 17:35, Brian Campbell wrote:
    +1
     
    On Thu, Mar 10, =
2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
    wrote:
     
    I support this =
document being moved forward with these two changes:
     
    - change name =
to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=E2=80=9D =
as
    proposed by =
Brian and
    - use =
the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 instead =
of
    =E2=80=99openid-configuration=E2=80=99 as proposed by =
Justin.
     
    18 feb 2016 kl. =
14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net
    :
     
    Hi all,
     
    This is a Last Call for comments on the  =
OAuth 2.0 Discovery
    specification:
    https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
     
    Since this =
document was only adopted recently we are running this last
    call for **3 =
weeks**.
     
    Please have =
your comments in no later than March 10th.
     
    Ciao
    Hannes & Derek
     
    _______________________________________________
    OAuth mailing =
list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    =E2=80=94=
 Roland
     
    =E2=80=9DEverybod=
y should be quiet near a little stream and listen."
    >=46rom =
=E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
     
     
    _______________________________________________
    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
    <=
p class=3D"MsoNormal" style=3D"margin: 0in 0in 12pt; font-size: 12pt; =
font-family: 'Times New Roman', serif;">
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


     
    -- 
    Nat Sakimura (=3Dnat)
    Chairman, OpenID =
Foundation
    http://nat.sakimura.org/
    @_nat_en
    _______________________________________________
    OAuth mailing =
list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    =

--Apple-Mail=_D9C0A4A5-853D-4760-B47D-24D4FD6752D0--

--Apple-Mail=_BB67A04D-B302-494D-8972-659B1C8DD1D6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTExNjA4MDRaMCMGCSqGSIb3DQEJBDEWBBSLmdHpbSyOY2dwWHlW/M5P
hQi+QzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBGLwBQRv3RE/5AZsCzpoP1Uc1WQ37G6jZbd6YPPfyyzUbC0NdeN5ha
ziYmi5vkt9yTua2ushIlU1NlwTC0VW6JDTZtEZ6i7dk1koQwdtO43mZiiJW62T3H5GQnU/PrXZ3P
OwjbdBOCu+OjsAsvjBbeNYplwnQerxUeoCY+nK2epHZtRm9R99j56AoVOy84pIRQcJqR0RylOz0k
/3MeEWYY9K7KhTO/v3ixANMO+8Ewf/D3JXAEJ2BP3/fdR7qbbTb286gNdKeJoMRXRIZGcwVpqrlB
9IHmtWYf2mrgT+JR2syMjoXVBHayDZii5TpMN8KHTB6EzsJ9TAaw4AU3FJzeAAAAAAAA
--Apple-Mail=_BB67A04D-B302-494D-8972-659B1C8DD1D6--


From nobody Fri Mar 11 12:19:09 2016
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 282F512DB09 for ; Fri, 11 Mar 2016 12:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 aVbpKbcYK2kE for ; Fri, 11 Mar 2016 12:19:04 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6AE412DAE5 for ; Fri, 11 Mar 2016 12:19:03 -0800 (PST)
Received: from [192.168.10.140] ([195.149.223.22]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0gcI-1ZqdKN1Nd8-00usbS for ; Fri, 11 Mar 2016 21:19:01 +0100
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56E32835.4090702@gmx.net>
Date: Fri, 11 Mar 2016 21:19:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U0TvNnbJLlJvBsffsLO21qFRNwAwHJquU"
X-Provags-ID: V03:K0:AO2Lg7vwRzwUvKG7u0mIY9T1SUT4bfSEDly4RUiyu32CiP644Td QEbb5jJdvCIOBehj7Bf6aJ5P15JEYQU1SYwEld1wqUw5pPyS2pT3EVAikUarYiQ5LKp7EHa 1nLljfRCSawM/YJT6ScLM8p5G1iMYFlITGcUOFy+HZAZ+DF0K/MxTS5JI2yPSck8xXAM6bf TmbJwWHk+EhLfEBM7aLeg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:3qxkeHtZcN8=:Un99Z6++eM3LwjE7Oy1PBI 3F83jVSu+p46NFdktVYa0Z3BynElN2cNV2FUm2Qv3AwxFemuqIKWXYzKz+lDOuBW3iv+GlazE crGd1MKRrtKbZDPTWXBDJ+6IP2n5Ch3FL4+b19iN3HboPbaZDNj6nMoiqt+/jLDikLfgSG6vo Lvb5gh2Vr/0MP+VhcwotlIRHrc4V8gkyzOstPWwDDBoR7Ndl262poHJBNNFxkSxxC8KGhO2RO grXZxw1y93r9wmoMEKesicm+8sskjgDS1vhfNSkov4iPDjbT6vkVrGtK+K+BLHJRbkzcn8ZYY PxnFCDeJwked5ykw4/s45/rii+P2sOsXt5RVW9Fa58zG6ZQXPqJll72vqGOP79LjFZbWhFVOk O5PDgcNneDmF9qz3WmcSGojnePQE5fo7jn2cDAKJe+LeRuI4JFnnZ2aCkey8fCFFUOoeQgRqV KPjfmKiAPJZbCnEt8yFWQ0l2dX7hDdw7I7AAIAE9Uo6R16zTXsxeDNy5GHVyZWxpUHQtQLEbg I86bYxIGPl3yQPY/hX3zM2jQcU81sRTirsrGwI4N4N+o+hPM4eRw3HIKS8GQnNl9seiLoFdWs 4uqkVekEpBgsNag2nBV158s9/VUSUgzxLjJQASRBxxWFpM7NN8zDwNXz2tUusjr24h9YH9564 L5xa7W10mL21e6EAcWMYiPYigLJWIdRxhvlpyyI9WyWZzP4NHK+49E/RqIOSEa0bANM2TzT2x jveL1UtAQIOlHj+eD+8qc9uzhwJywo9CQ4Q+RPS1io0JQVXuufYWDsjt8E8=
Archived-At: 
Subject: [OAUTH-WG] Concluding the Call for Adoption of the Authorization Server Mix-Up Specification
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 20:19:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--U0TvNnbJLlJvBsffsLO21qFRNwAwHJquU
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

on February 19 I posted a note to the list asking the group to consider
a call for adoption of either 
or , see
https://www.ietf.org/mail-archive/web/oauth/current/msg15829.html

I gave time till early March to think about this topic and there was a
lot of feedback on the mailing list.

Here are key observations I made:

 (1) Most folks argued that they wanted
 as a starting point for a
solution (*).

 There are, however, various issues that surfaced:

    a) From the discussions I think the document needs to provide more
information about the attack (in addition to the reference to the
research paper).
=09
    b) William furthermore suggested to change the title of the document
to have a more positive tone, namely to focus on the use case it support
rather than the attack it mitigates. I am open to suggestions to hear
better document titles and abstracts.
=09
    c) Torsten argued that the code injection/copy and paste attack
should go into a separate document (instead of covering both type of
issues in the same document).
=09
 (2) There is some interest to explore a PKCE-based solution approach as
well. I believe we should survey the landscape extensively and also
consider this approach.

To acknowledge the work Nat has put into this topic with the work on
 and the discussion feedback I would like
to have him participate in the work of the working group item as a
co-author.

I would like to already now thank those who had spent time and energy in
exploring this topic. Big thanks also go to Roland, Brian and Hans for
their prototyping efforts.

Ciao
Hannes

PS: During the discussion some other issues surface, such as associating
the access tokens with a specific audience, and this is a topic we will
have to cover separately.



--U0TvNnbJLlJvBsffsLO21qFRNwAwHJquU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW4yg1AAoJEGhJURNOOiAt1bQH+wRytYali6mBP3UbH90tEPY6
s8XojHWQ/k2sBVKX7eGGC20QJ0cDB8cmT0PHjE63pg24nd9/sF2Eyq93VAFYDkjf
wW72ODJEUA9GbOQ1M9y9PA7VucMMCYcPZYhbH5hzfYgbReVsJQdQDC26nnYA43tx
J9q4ngpGiXjeQk7FObICBXyBBwk66yDiQc5io5pTSCEoci3jrY7uhKDTOpMUi7E1
41/XNtQ++/ZWN9ZgYvf9tQ5y+OihEIJiNNHZy559QLKETyB8LqD+CSD0YF6dW+C9
KS4OBKTILFK003gcddM4H7OT/SGnJ4Jg4g/IOCIFLtUf2GpgSzHdnPfgIr7IWO8=
=4bRW
-----END PGP SIGNATURE-----

--U0TvNnbJLlJvBsffsLO21qFRNwAwHJquU--


From nobody Fri Mar 11 15:16:03 2016
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 5FC8B12DDCC for ; Fri, 11 Mar 2016 15:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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=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 rUrdp_RJKQwB for ; Fri, 11 Mar 2016 15:15:55 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 BD4CC12DDC2 for ; Fri, 11 Mar 2016 15:11:49 -0800 (PST)
Received: by mail-ig0-x233.google.com with SMTP id ig19so23922092igb.0 for ; Fri, 11 Mar 2016 15:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PJ75ZyBZg0K0C+xIEwN/UNAus6hlBywM42ecaM0Vdd4=; b=UlqiUr//XrCfF8ejfqB917peO3wxCsGvI2DOgMCS4eFOQrKY2/bGpi6CMJD7syQLKw 6Umm3oLqVPIoVA4nh1xX+FgBUA6+solK4/C9rx/NPvDIJ7bM6AgRLExy0250NeJtWso3 4bUJ3DOOn5hlxecU+7LUqKBwT+kKwUg3rOYfw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PJ75ZyBZg0K0C+xIEwN/UNAus6hlBywM42ecaM0Vdd4=; b=Ya3jJgD289pbIDFMqrxaZAxlUjZj+2JQKXgKKEjL6cEjPgEBJMEcf32GLz/bWp8aLj Wfu4ic5v34G64sY6ZEdKzRKlLYtPt0Yu2yQy19/lJUqH6UKeG1b6Ysiu1SgdBeHq0rSZ PBUaFhuGmAPcaWnrRn5cWHD7GrWzDlxJ8+Aoc9APaLF6PQqQ8bNtNAGD6zpWfqpIke5b 0rR6sEH8tQzyhCot1RhaMjD/LyeCt3m9kFhhl99gVb4CIK0O0VAJTkoFS1VXgJDeOnti ip3AVGKDwjrgimMDsNFQF29v22nRfNA7VhqtP7TPqDFLI57WTcbcofSzHlkcLXUp1jXG aduQ==
X-Gm-Message-State: AD7BkJI5cxELw+iOIR7BrRPbxBtrNCQrafHGKdRA3vjgsviceyjckh9HH41tDrgxNOUrbinnAw+yNMnV7eiY171/
X-Received: by 10.50.85.14 with SMTP id d14mr6820179igz.49.1457737909040; Fri, 11 Mar 2016 15:11:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 11 Mar 2016 15:11:19 -0800 (PST)
In-Reply-To: <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>
From: Brian Campbell 
Date: Fri, 11 Mar 2016 16:11:19 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=089e013c71003ec3b2052dce0e57
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 23:16:00 -0000

--089e013c71003ec3b2052dce0e57
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I tend to agree with John that addressing the concerns Phil raises should
be part of (extension to) the core protocol.  And that those kinds of
concerns don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata"
should keep it's scope to the publishing of authorization server metadata.
The act of doing discovery is beyond its scope and so is trying to prevent
a client from presenting a token to someplace it shouldn't.



On Fri, Mar 11, 2016 at 9:08 AM, John Bradley  wrote:

> Inline
>
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
> wrote:
>
> John
>
> In many case all the AS has to check is the domain name component to chec=
k
> for mitm.
>
> POP and the other solns are dramatically more complex than a simple check=
.
>
>
> I was proposing ding that check at the authorization endpoint or token
> endpoint as part of AT issuance.
>
> It is up to the AS how much of the path to validate and or put in the aud
> or dst.
>
>
>
> I see it as part of the discovery(bad name aside) problem because we
> discussed that if a client finds app.example.com how do we ensure it gets
> a complete set of oauth endpoints as a valid set of endpoints--that a
> hacker has not inserted one of their own endpoints. The most important
> endpoint to get right is ensuring the resource server (and optionally the
> path) is the correct one. We can't really define resource discovery but w=
e
> can validate it to some degree.
>
> I think it is part of core protocol security and should/must not require
> discovery.
>
> What is app.example.com ?
>
> If it is the resource then the client would be preconfigured for it=E2=80=
=99s AS
> out of band or optionally would do discovery on the issuer uri that you
> admit needs to be configured out of band some way (note discovery is
> optional)
>
> In the AS meta-data draft it would do a get on a well known file that
> would have configuration for the AS, but not the RS, though some API may
> optionally list a API endpoint like connect has.
>
> The client then makes a authorization request (after registering out of
> band or dynamically).
> As part of the authorization request for implicit it could provide the
> aud/dst that it wants the token for.
> If that is not sent then the aud/dst are implicit in the scopes.
>
> The client gets back a AT with a list of scopes granted, aud/dst allowed
> and time to live for the token (one extra thing returned)
>
> This doesn=E2=80=99t require any discovery (yes there is a optional AS me=
ta-data
> discovery but not required)
>
> I prefer to fix the RS man in the middle issue as part of the protocol an=
d
> not part of discovery that should remain optional.
>
> I honestly don=E2=80=99t quite know how the client learns about this bad =
RS and
> starts talking to it, so this may be a solution to a problem that doesn=
=E2=80=99t
> yet exist.   The one place this is posable is if the registration for the
> client is compromised.  However we are discussing other mitigations for
> that that also explicitly do not require discovery.
>
> John B.
>
>
> I am not stuck on webfinger or well-known. Because this is config maybe i=
t
> should be an oauth endpoint.
>
> Phil
>
> On Mar 11, 2016, at 06:51, John Bradley  wrote:
>
> I think Phil is proposing something different.   Should the client send a
> token from this AS to that RS.
>
> His goal is to prevent man in the middle attacks where a bad RS gets a AT
> that is audianced to/accepted by another RS.
>
> That is separate from the question of if a RS accepts tokens from a good
> AS.   A bad AS would always say yes.
>
> We need to be careful of what if anything the RS provides to the client a=
s
> meta-data without validation.
>
> Currently the client can provide a list of scopes required to get access.
>   I personally feel it would be useful to also include in the
> unauthenticated error response an indication of what API the resource
> supports.  Say =E2=80=9Cscim2=E2=80=9D as an example.   I don=E2=80=99t t=
hink adding that is
> however a high priority as most if all clients know what API they expect.
> It might be useful if at some point in the future if a client were to be
> given a RS URI it could check to see if it is a protocol that it supports
> before bothering with OAuth.    I expect that a lot of people will want
> that left to the API definition.   I think we can talk about it but rate
> this low priority.
>
> I agree that the RS giving out a list of AS that it trusts is a generally
> bad idea.  I hope that is not on the table.
>
> I don=E2=80=99t think that preventing a client from sending a token to th=
e wrong
> RS is part of a AS meta-data discovery problem.
>
> I do however think that it is important.
>
> We have been discussing this as a separate problem to AS meta-data
> discovery where the endpoints of the AS and it=E2=80=99s configuration ar=
e
> discovery.   Sorry for perhaps stating the obvious, but the RS is
> explicitly not part of the AS in OAuth 2.   Starting in WAP that was a co=
re
> principal.
>
> So we have a number of options to address the RS token leakage via MiTM
> attacks.
>
> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS
> or Token binding they cannot be replayed.  Signed messages where the
> signing covers the RS Host and path components,  also would work.
>
> 2) Have the AS audience restrict the resources the AT is good at. (AT
> should be doing that now)
> In the token response include the list of audience/s the token is
> presentable at.  The client would throw an error if the RS it intends to
> send the token to is not on the list.   The RS the token is good at might
> change based on scopes, client_id and resource owner.   This is the place
> where all of that comes together.   In some cases the RS and AS might not
> have a pre-established relationship.   The client should send the RS base
> URI to the AS as part of the request.  The AS can use that to audience
> restrict the AT and issue the AT or refuse to issue the AT based on polic=
y.
> It can also use the audience in the request to down audience the AT if th=
e
> default is to have multiple audiences.    We may want to use a term other
> than audience for this like resource or destination.  It is a audience bu=
t
> that term might confuse people with AT.
>
> We did talk about breaking audience out of POP key distribution, and Bria=
n
> Campbell did a draft
> https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt.
>
> To do this we could take dst4jwt and add another spec that adds a new dst
> parameter to the token and authorization endpoints requests That would be=
 a
> space separated list of dst values.  and in the response from the token
> endpoint would be a JSON array of dst values.
>
> 3) Have the AS always return all the list of all RS the token can be used
> at (basically Nat's link relationship proposal).  It needs a way to handl=
e
> down destinationing of AT and to allow for un-configured RS that it might
> issue a token for.  So could be combined with dst from 2.  Basically
> returning the acceptable destinations as link headers vs JS in the respon=
se
> is mostly a style issue that other people can bike shed.
>
>
> 4) Trying to add all the RS to the AS discovery document.  This seems
> impractical as there would be multiple protocols and doesn=E2=80=99t addr=
ess
> un-configured RS.
>
> 5) Some new AS endpoint that the client could introspect the RS URI and
> get back metadata about if the client should send tokens there.
>     A couple of problems with this.  The first is that it would not
> support un-configured RS unless you add dst to the token and authorizatio=
n
> endpoints.   The other is that the introspection endpoint doesn=E2=80=99t=
 have the
> context of the RO and client_id unless you also pass the code/RT and
> client_id, and probably client credentials.    Basically this is trying t=
o
> introspect the AT to determine the audiance/dst.   By the time you build =
a
> new introspection endpoint securely it is going to look like the token
> endpoint with a bit more meta data about the token beyond expiry and scop=
es.
>
>
> I think we should go a head with the renamed "OAuth 2.0 Authorization
> Server Discovery Metadata=E2=80=9D
> I am also fine with making the default document 'openid-configuration=E2=
=80=99  as
> long as we allow for protocol specific variation so that SCIM2 could defi=
ne
> a file name.    If people want we could do a API  to file name registry s=
o
> that protocol specific ones can be defined.
>
> We are all-ready working on option 1 to secure AT, we need a spec like I
> propose in 2 for bearer tokens.  We can add one request parameter and a b=
it
> more token meta-data to the token response and that takes care of the
> problem.   Honestly we probably should have separated scope and destinati=
on
> in the first place and returned both dst and scope in the response all
> along, so this is update that is consistent with the eisting architecture
> of OAuth 2.
>
> Lets keep the two issues separate.
>
> John B.
>
>
>
>
> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin 
> wrote:
>
> The relationship between AS and RS need to be scoped to =E2=80=9Cdoes thi=
s RS
> accept tokens from this AS=E2=80=9D as a list is too much information tha=
t could be
> used in the wrong way
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O=
n
> Behalf Of *Nat Sakimura
> *Sent:* Thursday, March 10, 2016 6:25 PM
> *To:* Phil Hunt (IDM) 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
> Phil,
>
> Right. So what my conditional approvals (11 conditions in total) said was
> to drop the word "discovery" from everywhere. This is not a discovery spe=
c.
> This is a configuration lookup spec as you correctly points out. So, I am
> with you here.
>
> Also, my 2nd conditiion is essentially saying to drop section 3.
>
> One thing that I overlooked and am with you is that we need to be able to
> express the AS-RS relationships. I have been preaching this in the other
> thread for so many times as you know so I thought I pointed it out, but
> missed apparently in my previous comment. So, I would add my 12th
> condition:
>
> 12. A way to express a list of valid RSs for this AS needs to be added to
> section 2.
>
> Best,
>
> Nat
>
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>
> I strongly oppose. 2 major issues.
>
> This is not service discovery this is configuration lookup. The client
> must have already discovered the oauth issuer uri and the resource uri.
>
> The objective was to provide a method to ensure the client has a valid se=
t
> of endpoints to prevent mitm of endpoints like the token endpoint to the
> resource server.
>
> The draft does not address the issue of a client being given a bad
> endpoint for an rs. What we end up with is a promiscuous authz service
> giving out tokens to an unwitting client.
>
> Phil
>
>
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
> wrote:
>
> +1 to move forward with these
> On 10/03/16 17:35, Brian Campbell wrote:
>
> +1
>
>
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg  <=
roland.hedberg@umu.se>
>
> wrote:
>
>
>
> I support this document being moved forward with these two changes:
>
>
>
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
>
> proposed by Brian and
>
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
>
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>
>
>
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
> :
>
>
>
> Hi all,
>
>
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery
>
> specification:
>
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 
>
>
>
> Since this document was only adopted recently we are running this last
>
> call for **3 weeks**.
>
>
>
> Please have your comments in no later than March 10th.
>
>
>
> Ciao
>
> Hannes & Derek
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
>
> =E2=80=94 Roland
>
>
>
> =E2=80=9DEverybody should be quiet near a little stream and listen."
>
> >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>
>
>
>
>
> _______________________________________________
>
> 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 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> 
> @_nat_en
> _______________________________________________
> 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
>
>

--089e013c71003ec3b2052dce0e57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I tend to agree with John that addressing the concerns Phi=
l raises should be part of (extension to) the core protocol.=C2=A0 And that=
 those kinds of concerns don't manifest in the way OAuth is typically d=
eployed now. 

    The hopefully soon to be named "OAuth 2.0 Authori=
zation Server Metadata" should keep it's scope to the publishing o=
f authorization server metadata. The act of doing discovery is beyond its s=
cope and so is trying to prevent a client from presenting a token to somepl=
ace it shouldn't. 



    On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7j=
tb@ve7jtb.com> wrote:
    Inline



    I see it as part of the discovery(bad name aside) problem because we dis=
cussed that if a client finds     app.example.com how do we ensure it gets a complete set of oau=
th endpoints as a valid set of endpoints--that a hacker has not inserted on=
e of their own endpoints. The most important endpoint to get right is ensur=
ing the resource server (and optionally the path) is the correct one. We ca=
n't really define resource discovery but we can validate it to some deg=
ree.=C2=A0

    I think=
 it is part of core protocol security and should/must not require discovery=
.=C2=A0

    What is app.example.com ?=C2=A0

    If =
it is the resource then the client would be preconfigured for it=E2=80=99s =
AS out of band or optionally would do discovery on the issuer uri that you =
admit needs to be configured out of band some way (note discovery is option=
al)

    In the AS meta-data draft it would do a get on=
 a well known file that would have configuration for the AS, but not the RS=
, though some API may optionally list a API endpoint like connect has. =C2=
=A0

    The client then makes a authorization request =
(after registering out of band or dynamically). =C2=A0
    As part of=
 the authorization request for implicit it could provide the aud/dst that i=
t wants the token for.
    If that is not sent then the aud/dst are i=
mplicit in the scopes.

    The client gets back a AT w=
ith a list of scopes granted, aud/dst allowed and time to live for the toke=
n (one extra thing returned)

    This doesn=E2=80=99t =
require any discovery (yes there is a optional AS meta-data discovery but n=
ot required)

    I prefer to fix the RS man in the mid=
dle issue as part of the protocol and not part of discovery that should rem=
ain optional.

    I honestly don=E2=80=99t quite know =
how the client learns about this bad RS and starts talking to it, so this m=
ay be a solution to a problem that doesn=E2=80=99t yet exist. =C2=A0 The on=
e place this is posable is if the registration for the client is compromise=
d.=C2=A0 However we are discussing other mitigations for that that also exp=
licitly do not require discovery.

    John B.


    I am not stuck on webfinger or well-known. Because this i=
s config maybe it should be an oauth endpoint.=C2=A0

    Phil
    =

    On Mar 11, 2016, at 06:51, John Bradley <ve7jtb@ve7jtb.com> wrote:

    <=
blockquote type=3D"cite">
    I think Phil is proposing something different=
. =C2=A0 Should the client send a token from this AS to that RS. =C2=A0
    His goal is to prevent man in the middle attacks where a ba=
d RS gets a AT that is audianced to/accepted by another RS.

    <=
/div>
    That is separate from the question of if a RS accepts tokens from=
 a good AS. =C2=A0 A bad AS would always say yes.

    =
We need to be careful of what if anything the RS provides to the client as =
meta-data without validation.

    Currently the client=
 can provide a list of scopes required to get access. =C2=A0 I personally f=
eel it would be useful to also include in the unauthenticated error respons=
e an indication of what API the resource supports.=C2=A0 Say =E2=80=9Cscim2=
=E2=80=9D as an example. =C2=A0 I don=E2=80=99t think adding that is howeve=
r a high priority as most if all clients know what API they expect. =C2=A0 =
It might be useful if at some point in the future if a client were to be gi=
ven a RS URI it could check to see if it is a protocol that it supports bef=
ore bothering with OAuth. =C2=A0 =C2=A0I expect that a lot of people will w=
ant that left to the API definition. =C2=A0 I think we can talk about it bu=
t rate this low priority.

    I agree that the RS givi=
ng out a list of AS that it trusts is a generally bad idea.=C2=A0 I hope th=
at is not on the table.

    I don=E2=80=99t think that=
 preventing a client from sending a token to the wrong RS is part of a AS m=
eta-data discovery problem.

    I do however think tha=
t it is important.

    We have been discussing this as=
 a separate problem to AS meta-data discovery where the endpoints of the AS=
 and it=E2=80=99s configuration are discovery. =C2=A0 Sorry for perhaps sta=
ting the obvious, but the RS is explicitly not part of the AS in OAuth 2. =
=C2=A0 Starting in WAP that was a core principal.

    =
So we have a number of options to address the RS token leakage via MiTM att=
acks.

    1) PoP bound tokens.=C2=A0 If they are bound=
 to the TLS channel by mutual TLS or Token binding they cannot be replayed.=
=C2=A0 Signed messages where the signing covers the RS Host and path compon=
ents, =C2=A0also would work.

    2) Have the AS audien=
ce restrict the resources the AT is good at. (AT should be doing that now)=
=C2=A0
    In the token response include the list of audience/s the t=
oken is presentable at.=C2=A0 The client would throw an error if the RS it =
intends to send the token to is not on the list. =C2=A0 The RS the token is=
 good at might change based on scopes, client_id and resource owner. =C2=A0=
 This is the place where all of that comes together. =C2=A0 In some cases t=
he RS and AS might not have a pre-established relationship. =C2=A0 The clie=
nt should send the RS base URI to the AS as part of the request.=C2=A0 The =
AS can use that to audience restrict the AT and issue the AT or refuse to i=
ssue the AT based on policy.
    It can also use the audience in the =
request to down audience the AT if the default is to have multiple audience=
s. =C2=A0 =C2=A0We may want to use a term other than audience for this like=
 resource or destination.=C2=A0 It is a audience but that term might confus=
e people with AT.

    We did talk about breaking audie=
nce out of POP key distribution, and Brian Campbell did a draft=C2=A0https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt. =C2=A0=
=C2=A0

    To do this we could take dst4jwt and add an=
other spec that adds a new dst parameter to the token and authorization end=
points requests That would be a space separated list of dst values. =C2=A0a=
nd in the response from the token endpoint would be a JSON array of dst val=
ues.

    3) Have the AS always return all the list of =
all RS the token can be used at (basically Nat's link relationship prop=
osal).=C2=A0 It needs a way to handle=C2=A0
    down destinationing o=
f AT and to allow for un-configured RS that it might issue a token for.=C2=
=A0 So could be combined with dst from 2.=C2=A0 Basically returning the acc=
eptable destinations as link headers vs JS in the response is mostly a styl=
e issue that other people can bike shed.


    4) Trying to add all the RS to the AS discovery document.=C2=A0 This =
seems impractical as there would be multiple protocols and doesn=E2=80=99t =
address un-configured RS.

    5) Some new AS endpoint =
that the client could introspect the RS URI and get back metadata about if =
the client should send tokens there.
    =C2=A0 =C2=A0 A couple of pr=
oblems with this.=C2=A0 The first is that it would not support un-configure=
d RS unless you add dst to the token and authorization endpoints. =C2=A0 Th=
e other is that the introspection endpoint doesn=E2=80=99t have the context=
 of the RO and client_id unless you also pass the code/RT and client_id, an=
d probably client credentials. =C2=A0 =C2=A0Basically this is trying to int=
rospect the AT to determine the audiance/dst. =C2=A0 By the time you build =
a new introspection endpoint securely it is going to look like the token en=
dpoint with a bit more meta data about the token beyond expiry and scopes.<=
/div>


    I think we should go a head with th=
e renamed "OAuth 2.0 Authorization Server Discovery Metadata=E2=80=9D=
=C2=A0
    I am also fine with making the default document 'openi=
d-configuration=E2=80=99 =C2=A0as long as we allow for protocol specific va=
riation so that SCIM2 could define a file name. =C2=A0 =C2=A0If people want=
 we could do a API =C2=A0to file name registry so that protocol specific on=
es can be defined.

    We are all-ready working on opt=
ion 1 to secure AT, we need a spec like I propose in 2 for bearer tokens.=
=C2=A0 We can add one request parameter and a bit more token meta-data to t=
he token response and that takes care of the problem. =C2=A0 Honestly we pr=
obably should have separated scope and destination in the first place and r=
eturned both dst and scope in the response all along, so this is update tha=
t is consistent with the eisting architecture of OAuth 2.

    Lets keep the two issues separate.

    John B.=

    =C2=A0



    On Mar 11, 2016, at 12:07 AM, Anthony Nad=
alin <tonynad=
@microsoft.com> wrote:

    The relationship between=
 AS and RS need to be scoped to =E2=80=9Cdoes this RS accept tokens from th=
is AS=E2=80=9D as a list is too much information that could be used in the =
wrong way
    From:=C2=A0=
OAuth [m=
ailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=
=C2=A0Nat Sakimura
    Sent:=C2=A0Thursday, M=
arch 10, 2016 6:25 PM
    To:=C2=A0Phil Hunt (IDM) <<=
a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c=
om>
    Cc:=C2=A0oauth <oauth@ietf.org>
    Subject:=C2=A0    Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discover=
y
    =C2=A0
    Phil,=C2=A0
    =C2=A0
    R=
ight. So what my conditional approvals (11 conditions in total) said was to=
 drop the word "discovery" from everywhere. This is not a discove=
ry spec. This is a configuration lookup spec as you correctly points out. S=
o, I am with you here.=C2=A0
    =C2=A0
    Also, my=
 2nd conditiion is essentially saying to drop section 3.=C2=A0
    =C2=A0
    One thing that I overlooked and am with you is th=
at we need to be able to express the AS-RS relationships. I have been preac=
hing this in the other thread for so many times as you know so I thought I =
pointed it out, but missed apparently in my previous comment. So, I would a=
dd my 12th condition:=C2=A0
    =C2=A0
    12. A way=
 to express a list of valid RSs for this AS needs to be added to section 2.=
=C2=A0
    =C2=A0
    Best,=C2=A0
    =C2=A0
    Nat
    =C2=A0
    2016-03-11 2:=
09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@=
oracle.com>:
    I strongly oppose. 2 major issues.=C2=A0
    =C2=A0
    =

    This is not service discovery this is configuration =
lookup. The client must have already discovered the oauth issuer uri and th=
e resource uri.=C2=A0
    =
=C2=A0
    The objective w=
as to provide a method to ensure the client has a valid set of endpoints to=
 prevent mitm of endpoints like the token endpoint to the resource server.=
=C2=A0
    =C2=A0
    The draft does not address the=
 issue of a client being given a bad endpoint for an rs. What we end up wit=
h is a promiscuous authz service giving out tokens to an unwitting client.=
=C2=A0

    Phil

    On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
    =

    +1 to move forward with these
    On 10/03/16 17:35, Brian Campbell wrote:
    =

    +1
    =C2=A0
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie=
r New'">On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>wrote:
    =C2=A0
    <=
blockquote style=3D"margin-top:5pt;margin-bottom:5pt">
    I suppor=
t this document being moved forward with these two changes:
    =C2=A0
    - change name to =
=E2=80=9COAuth 2.0 Authorization Server Discovery Metadata=E2=80=9D as
    proposed by Brian and
    - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=
=99 instead of
    =E2=80=99openid-configuratio=
n=E2=80=99 as proposed by Justin.
    =
=C2=A0
    <=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie=
r New'">18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net
    :
    =C2=A0
    Hi all,
    =C2=A0
    =

    This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discov=
ery
    specification:
    https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
    =C2=A0
    Since=
 this document was only adopted recently we are running this last=

    call for **3 weeks**.
    =C2=A0
    Please have your comments in no l=
ater than March 10th.
    =C2=A0<=
/pre>
    Ciao
    Hannes & Derek
    =C2=A0
    _____=
__________________________________________
    =
OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/ma=
ilman/listinfo/oauth
    =E2=
=80=94 Roland
    =C2=A0
    =E2=80=9DEverybody should be quiet near a little stream and liste=
n."
    >From =E2=80=99Open House for B=
utterflies=E2=80=99 by Ruth Krauss
    =
=C2=A0
    =C2=A0
    ____=
___________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org=
/mailman/listinfo/oauth
    =C2=A0
    =C2=A0
    =C2=A0
    _____________=
__________________________________
    OAuth ma=
iling list
    OAuth@=
ietf.org
    https://www.ietf.org/mailman/li=
stinfo/oauth
    <=
/div>

    _______________________=
________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    =C2=A0
    =

    --=C2=A0
    =

    Nat Sakimura (=3Dnat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en<=
/div>
    ______________=
_________________________________
    OAuth mai=
ling list
    OAuth@ietf.org
    https:=
//www.ietf.org/mailman/listinfo/oauth
    <=
/div>
    _______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    


    

--089e013c71003ec3b2052dce0e57--


From nobody Fri Mar 11 15:24:52 2016
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 8D7A112DD18 for ; Fri, 11 Mar 2016 15:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.109
X-Spam-Level: *
X-Spam-Status: No, score=1.109 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 LmLuv1_Q2CEJ for ; Fri, 11 Mar 2016 15:24:46 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFFD12D95F for ; Fri, 11 Mar 2016 15:24:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+w+MQmcYMLz7D5zcaW+bobM62vBNHr3SyS5tudJkBxg=; b=Z7/Q+2yNlKIo/OPu4UjhawR8koGcHrpdR6jiwirf3CO3cPd6T8LPtmmpLFaZb3RfphMQxr2h/hZWkLxpc0/B4jKmeviFLIDZeN7Ts207NdR0S9aLXvEcBeyc74SC68EVAXT4ye8GmtwaoaOZHhLbwrtMoGIu8S4IOrFHcQKrw+s=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (10.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 11 Mar 2016 23:24:43 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0427.020; Fri, 11 Mar 2016 23:24:43 +0000
From: Anthony Nadalin 
To: Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH06DIAQfC9O0686lpsTuUfK59Sxh0AgAAqNQCAAAiJgIAAEaoAgACbQYCAAAsN0IAAxaEAgAAF5wCAAA9jAIAAdkGAgAACUgA=
Date: Fri, 11 Mar 2016 23:24:43 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:8::9b]
x-ms-office365-filtering-correlation-id: 6e2d65e1-bfdb-4f8c-9b0c-08d34a0453f0
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1235; 5:TbK+sA5dhnlaGM/+UYwkgzHpAiY0lHWLyDoHbtX+V3X+eEmNTJ3s2MkfC8NWIftMizzg8Oe5FloBS4UA/HWS2InMeBoU4GVFRf2ms3u5t7G8b2XCzy2xU5krRqXWEBT+wakLErj3pFQUj2vF0SM/NA==; 24:zgzSUNMp3k8BJIkCHpt+OgdqV9uWL48SJDLmk+ENYeXMIsCB4tAIxXmvu846MasYZ0BN7G9PR10irnFQvRZdP5xcA5uPGzObvaeEh3L81J0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235; 
x-forefront-prvs: 087894CD3C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(377424004)(53754006)(479174004)(77096005)(15975445007)(5001770100001)(74316001)(86362001)(790700001)(6116002)(5008740100001)(92566002)(586003)(102836003)(10090500001)(3280700002)(10290500002)(189998001)(3660700001)(4326007)(2906002)(5003600100002)(5005710100001)(5002640100001)(2900100001)(2950100001)(10400500002)(76576001)(122556002)(19609705001)(81166005)(93886004)(16236675004)(19300405004)(19617315012)(19625215002)(19580405001)(561944003)(87936001)(33656002)(1096002)(5004730100002)(50986999)(54356999)(76176999)(106116001)(99286002)(11100500001)(19580395003)(1220700001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234635AE77883D05EB4D82BA6B50BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 23:24:43.4536 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 23:24:50 -0000

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

RGlzYWdyZWUsIHdoYXQgcHVycG9zZSBpcyB0aGlzIGFjdGl2aXR5IHNvbHZpbmcgdGhlbiwgaXQg
d2FzIGJlaW5nIHB1c2hlZCBhcyB3aGF0IHdhcyBuZWVkIHRvIHNvbHZlIHRoZSBNaXgtdXAsIGJ1
dCB0aGF0IGlzIG5vdCB0cnVlLiBTbyBub3cgeW91IGFyZSBzdWdnZXN0aW5nIGEgY2hhbmdlIGlu
IHNjb3BlIGFuZCBub3QgZGVhbGluZyB3aXRoIGRpc2NvdmVyeS4NCg0KRnJvbTogT0F1dGggW21h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwN
ClNlbnQ6IEZyaWRheSwgTWFyY2ggMTEsIDIwMTYgMzoxMSBQTQ0KVG86IEpvaG4gQnJhZGxleSA8
dmU3anRiQHZlN2p0Yi5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog
UmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2Nv
dmVyeQ0KDQpJIHRlbmQgdG8gYWdyZWUgd2l0aCBKb2huIHRoYXQgYWRkcmVzc2luZyB0aGUgY29u
Y2VybnMgUGhpbCByYWlzZXMgc2hvdWxkIGJlIHBhcnQgb2YgKGV4dGVuc2lvbiB0bykgdGhlIGNv
cmUgcHJvdG9jb2wuICBBbmQgdGhhdCB0aG9zZSBraW5kcyBvZiBjb25jZXJucyBkb24ndCBtYW5p
ZmVzdCBpbiB0aGUgd2F5IE9BdXRoIGlzIHR5cGljYWxseSBkZXBsb3llZCBub3cuDQoNClRoZSBo
b3BlZnVsbHkgc29vbiB0byBiZSBuYW1lZCAiT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVy
IE1ldGFkYXRhIiBzaG91bGQga2VlcCBpdCdzIHNjb3BlIHRvIHRoZSBwdWJsaXNoaW5nIG9mIGF1
dGhvcml6YXRpb24gc2VydmVyIG1ldGFkYXRhLiBUaGUgYWN0IG9mIGRvaW5nIGRpc2NvdmVyeSBp
cyBiZXlvbmQgaXRzIHNjb3BlIGFuZCBzbyBpcyB0cnlpbmcgdG8gcHJldmVudCBhIGNsaWVudCBm
cm9tIHByZXNlbnRpbmcgYSB0b2tlbiB0byBzb21lcGxhY2UgaXQgc2hvdWxkbid0Lg0KDQoNCk9u
IEZyaSwgTWFyIDExLCAyMDE2IGF0IDk6MDggQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0
Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpJbmxpbmUNCk9uIE1hciAx
MSwgMjAxNiwgYXQgMTI6MTMgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5j
b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkpvaG4NCg0KSW4gbWFu
eSBjYXNlIGFsbCB0aGUgQVMgaGFzIHRvIGNoZWNrIGlzIHRoZSBkb21haW4gbmFtZSBjb21wb25l
bnQgdG8gY2hlY2sgZm9yIG1pdG0uDQoNClBPUCBhbmQgdGhlIG90aGVyIHNvbG5zIGFyZSBkcmFt
YXRpY2FsbHkgbW9yZSBjb21wbGV4IHRoYW4gYSBzaW1wbGUgY2hlY2suDQoNCkkgd2FzIHByb3Bv
c2luZyBkaW5nIHRoYXQgY2hlY2sgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb3IgdG9r
ZW4gZW5kcG9pbnQgYXMgcGFydCBvZiBBVCBpc3N1YW5jZS4NCg0KSXQgaXMgdXAgdG8gdGhlIEFT
IGhvdyBtdWNoIG9mIHRoZSBwYXRoIHRvIHZhbGlkYXRlIGFuZCBvciBwdXQgaW4gdGhlIGF1ZCBv
ciBkc3QuDQoNCg0KDQpJIHNlZSBpdCBhcyBwYXJ0IG9mIHRoZSBkaXNjb3ZlcnkoYmFkIG5hbWUg
YXNpZGUpIHByb2JsZW0gYmVjYXVzZSB3ZSBkaXNjdXNzZWQgdGhhdCBpZiBhIGNsaWVudCBmaW5k
cyBhcHAuZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv
b2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5leGFtcGxlLmNvbSUyZiZkYXRhPTAxJTdjMDEl
N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMx
ZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWZpUzhmNjB5
cGlYaHlNMHFWVGVxbCUyYiUyYk96SDJ3Ym1FQ1FFN0o1VHRHUFFNJTNkPiBob3cgZG8gd2UgZW5z
dXJlIGl0IGdldHMgYSBjb21wbGV0ZSBzZXQgb2Ygb2F1dGggZW5kcG9pbnRzIGFzIGEgdmFsaWQg
c2V0IG9mIGVuZHBvaW50cy0tdGhhdCBhIGhhY2tlciBoYXMgbm90IGluc2VydGVkIG9uZSBvZiB0
aGVpciBvd24gZW5kcG9pbnRzLiBUaGUgbW9zdCBpbXBvcnRhbnQgZW5kcG9pbnQgdG8gZ2V0IHJp
Z2h0IGlzIGVuc3VyaW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgKGFuZCBvcHRpb25hbGx5IHRoZSBw
YXRoKSBpcyB0aGUgY29ycmVjdCBvbmUuIFdlIGNhbid0IHJlYWxseSBkZWZpbmUgcmVzb3VyY2Ug
ZGlzY292ZXJ5IGJ1dCB3ZSBjYW4gdmFsaWRhdGUgaXQgdG8gc29tZSBkZWdyZWUuDQoNCkkgdGhp
bmsgaXQgaXMgcGFydCBvZiBjb3JlIHByb3RvY29sIHNlY3VyaXR5IGFuZCBzaG91bGQvbXVzdCBu
b3QgcmVxdWlyZSBkaXNjb3ZlcnkuDQoNCldoYXQgaXMgYXBwLmV4YW1wbGUuY29tPGh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZh
cHAuZXhhbXBsZS5jb20mZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0
YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdjMSZzZGF0YT1qQXNaUWVDaEolMmJSMWxieUJvVkt3aGVJWWkzUGlXTHJxJTJi
eERMYnFVNnJ4ayUzZD4gPw0KDQpJZiBpdCBpcyB0aGUgcmVzb3VyY2UgdGhlbiB0aGUgY2xpZW50
IHdvdWxkIGJlIHByZWNvbmZpZ3VyZWQgZm9yIGl04oCZcyBBUyBvdXQgb2YgYmFuZCBvciBvcHRp
b25hbGx5IHdvdWxkIGRvIGRpc2NvdmVyeSBvbiB0aGUgaXNzdWVyIHVyaSB0aGF0IHlvdSBhZG1p
dCBuZWVkcyB0byBiZSBjb25maWd1cmVkIG91dCBvZiBiYW5kIHNvbWUgd2F5IChub3RlIGRpc2Nv
dmVyeSBpcyBvcHRpb25hbCkNCg0KSW4gdGhlIEFTIG1ldGEtZGF0YSBkcmFmdCBpdCB3b3VsZCBk
byBhIGdldCBvbiBhIHdlbGwga25vd24gZmlsZSB0aGF0IHdvdWxkIGhhdmUgY29uZmlndXJhdGlv
biBmb3IgdGhlIEFTLCBidXQgbm90IHRoZSBSUywgdGhvdWdoIHNvbWUgQVBJIG1heSBvcHRpb25h
bGx5IGxpc3QgYSBBUEkgZW5kcG9pbnQgbGlrZSBjb25uZWN0IGhhcy4NCg0KVGhlIGNsaWVudCB0
aGVuIG1ha2VzIGEgYXV0aG9yaXphdGlvbiByZXF1ZXN0IChhZnRlciByZWdpc3RlcmluZyBvdXQg
b2YgYmFuZCBvciBkeW5hbWljYWxseSkuDQpBcyBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHJl
cXVlc3QgZm9yIGltcGxpY2l0IGl0IGNvdWxkIHByb3ZpZGUgdGhlIGF1ZC9kc3QgdGhhdCBpdCB3
YW50cyB0aGUgdG9rZW4gZm9yLg0KSWYgdGhhdCBpcyBub3Qgc2VudCB0aGVuIHRoZSBhdWQvZHN0
IGFyZSBpbXBsaWNpdCBpbiB0aGUgc2NvcGVzLg0KDQpUaGUgY2xpZW50IGdldHMgYmFjayBhIEFU
IHdpdGggYSBsaXN0IG9mIHNjb3BlcyBncmFudGVkLCBhdWQvZHN0IGFsbG93ZWQgYW5kIHRpbWUg
dG8gbGl2ZSBmb3IgdGhlIHRva2VuIChvbmUgZXh0cmEgdGhpbmcgcmV0dXJuZWQpDQoNClRoaXMg
ZG9lc27igJl0IHJlcXVpcmUgYW55IGRpc2NvdmVyeSAoeWVzIHRoZXJlIGlzIGEgb3B0aW9uYWwg
QVMgbWV0YS1kYXRhIGRpc2NvdmVyeSBidXQgbm90IHJlcXVpcmVkKQ0KDQpJIHByZWZlciB0byBm
aXggdGhlIFJTIG1hbiBpbiB0aGUgbWlkZGxlIGlzc3VlIGFzIHBhcnQgb2YgdGhlIHByb3RvY29s
IGFuZCBub3QgcGFydCBvZiBkaXNjb3ZlcnkgdGhhdCBzaG91bGQgcmVtYWluIG9wdGlvbmFsLg0K
DQpJIGhvbmVzdGx5IGRvbuKAmXQgcXVpdGUga25vdyBob3cgdGhlIGNsaWVudCBsZWFybnMgYWJv
dXQgdGhpcyBiYWQgUlMgYW5kIHN0YXJ0cyB0YWxraW5nIHRvIGl0LCBzbyB0aGlzIG1heSBiZSBh
IHNvbHV0aW9uIHRvIGEgcHJvYmxlbSB0aGF0IGRvZXNu4oCZdCB5ZXQgZXhpc3QuICAgVGhlIG9u
ZSBwbGFjZSB0aGlzIGlzIHBvc2FibGUgaXMgaWYgdGhlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIGNs
aWVudCBpcyBjb21wcm9taXNlZC4gIEhvd2V2ZXIgd2UgYXJlIGRpc2N1c3Npbmcgb3RoZXIgbWl0
aWdhdGlvbnMgZm9yIHRoYXQgdGhhdCBhbHNvIGV4cGxpY2l0bHkgZG8gbm90IHJlcXVpcmUgZGlz
Y292ZXJ5Lg0KDQpKb2huIEIuDQoNCg0KDQpJIGFtIG5vdCBzdHVjayBvbiB3ZWJmaW5nZXIgb3Ig
d2VsbC1rbm93bi4gQmVjYXVzZSB0aGlzIGlzIGNvbmZpZyBtYXliZSBpdCBzaG91bGQgYmUgYW4g
b2F1dGggZW5kcG9pbnQuDQoNClBoaWwNCg0KT24gTWFyIDExLCAyMDE2LCBhdCAwNjo1MSwgSm9o
biBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3
cm90ZToNCkkgdGhpbmsgUGhpbCBpcyBwcm9wb3Npbmcgc29tZXRoaW5nIGRpZmZlcmVudC4gICBT
aG91bGQgdGhlIGNsaWVudCBzZW5kIGEgdG9rZW4gZnJvbSB0aGlzIEFTIHRvIHRoYXQgUlMuDQoN
CkhpcyBnb2FsIGlzIHRvIHByZXZlbnQgbWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrcyB3aGVyZSBh
IGJhZCBSUyBnZXRzIGEgQVQgdGhhdCBpcyBhdWRpYW5jZWQgdG8vYWNjZXB0ZWQgYnkgYW5vdGhl
ciBSUy4NCg0KVGhhdCBpcyBzZXBhcmF0ZSBmcm9tIHRoZSBxdWVzdGlvbiBvZiBpZiBhIFJTIGFj
Y2VwdHMgdG9rZW5zIGZyb20gYSBnb29kIEFTLiAgIEEgYmFkIEFTIHdvdWxkIGFsd2F5cyBzYXkg
eWVzLg0KDQpXZSBuZWVkIHRvIGJlIGNhcmVmdWwgb2Ygd2hhdCBpZiBhbnl0aGluZyB0aGUgUlMg
cHJvdmlkZXMgdG8gdGhlIGNsaWVudCBhcyBtZXRhLWRhdGEgd2l0aG91dCB2YWxpZGF0aW9uLg0K
DQpDdXJyZW50bHkgdGhlIGNsaWVudCBjYW4gcHJvdmlkZSBhIGxpc3Qgb2Ygc2NvcGVzIHJlcXVp
cmVkIHRvIGdldCBhY2Nlc3MuICAgSSBwZXJzb25hbGx5IGZlZWwgaXQgd291bGQgYmUgdXNlZnVs
IHRvIGFsc28gaW5jbHVkZSBpbiB0aGUgdW5hdXRoZW50aWNhdGVkIGVycm9yIHJlc3BvbnNlIGFu
IGluZGljYXRpb24gb2Ygd2hhdCBBUEkgdGhlIHJlc291cmNlIHN1cHBvcnRzLiAgU2F5IOKAnHNj
aW0y4oCdIGFzIGFuIGV4YW1wbGUuICAgSSBkb27igJl0IHRoaW5rIGFkZGluZyB0aGF0IGlzIGhv
d2V2ZXIgYSBoaWdoIHByaW9yaXR5IGFzIG1vc3QgaWYgYWxsIGNsaWVudHMga25vdyB3aGF0IEFQ
SSB0aGV5IGV4cGVjdC4gICBJdCBtaWdodCBiZSB1c2VmdWwgaWYgYXQgc29tZSBwb2ludCBpbiB0
aGUgZnV0dXJlIGlmIGEgY2xpZW50IHdlcmUgdG8gYmUgZ2l2ZW4gYSBSUyBVUkkgaXQgY291bGQg
Y2hlY2sgdG8gc2VlIGlmIGl0IGlzIGEgcHJvdG9jb2wgdGhhdCBpdCBzdXBwb3J0cyBiZWZvcmUg
Ym90aGVyaW5nIHdpdGggT0F1dGguICAgIEkgZXhwZWN0IHRoYXQgYSBsb3Qgb2YgcGVvcGxlIHdp
bGwgd2FudCB0aGF0IGxlZnQgdG8gdGhlIEFQSSBkZWZpbml0aW9uLiAgIEkgdGhpbmsgd2UgY2Fu
IHRhbGsgYWJvdXQgaXQgYnV0IHJhdGUgdGhpcyBsb3cgcHJpb3JpdHkuDQoNCkkgYWdyZWUgdGhh
dCB0aGUgUlMgZ2l2aW5nIG91dCBhIGxpc3Qgb2YgQVMgdGhhdCBpdCB0cnVzdHMgaXMgYSBnZW5l
cmFsbHkgYmFkIGlkZWEuICBJIGhvcGUgdGhhdCBpcyBub3Qgb24gdGhlIHRhYmxlLg0KDQpJIGRv
buKAmXQgdGhpbmsgdGhhdCBwcmV2ZW50aW5nIGEgY2xpZW50IGZyb20gc2VuZGluZyBhIHRva2Vu
IHRvIHRoZSB3cm9uZyBSUyBpcyBwYXJ0IG9mIGEgQVMgbWV0YS1kYXRhIGRpc2NvdmVyeSBwcm9i
bGVtLg0KDQpJIGRvIGhvd2V2ZXIgdGhpbmsgdGhhdCBpdCBpcyBpbXBvcnRhbnQuDQoNCldlIGhh
dmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgYXMgYSBzZXBhcmF0ZSBwcm9ibGVtIHRvIEFTIG1ldGEt
ZGF0YSBkaXNjb3Zlcnkgd2hlcmUgdGhlIGVuZHBvaW50cyBvZiB0aGUgQVMgYW5kIGl04oCZcyBj
b25maWd1cmF0aW9uIGFyZSBkaXNjb3ZlcnkuICAgU29ycnkgZm9yIHBlcmhhcHMgc3RhdGluZyB0
aGUgb2J2aW91cywgYnV0IHRoZSBSUyBpcyBleHBsaWNpdGx5IG5vdCBwYXJ0IG9mIHRoZSBBUyBp
biBPQXV0aCAyLiAgIFN0YXJ0aW5nIGluIFdBUCB0aGF0IHdhcyBhIGNvcmUgcHJpbmNpcGFsLg0K
DQpTbyB3ZSBoYXZlIGEgbnVtYmVyIG9mIG9wdGlvbnMgdG8gYWRkcmVzcyB0aGUgUlMgdG9rZW4g
bGVha2FnZSB2aWEgTWlUTSBhdHRhY2tzLg0KDQoxKSBQb1AgYm91bmQgdG9rZW5zLiAgSWYgdGhl
eSBhcmUgYm91bmQgdG8gdGhlIFRMUyBjaGFubmVsIGJ5IG11dHVhbCBUTFMgb3IgVG9rZW4gYmlu
ZGluZyB0aGV5IGNhbm5vdCBiZSByZXBsYXllZC4gIFNpZ25lZCBtZXNzYWdlcyB3aGVyZSB0aGUg
c2lnbmluZyBjb3ZlcnMgdGhlIFJTIEhvc3QgYW5kIHBhdGggY29tcG9uZW50cywgIGFsc28gd291
bGQgd29yay4NCg0KMikgSGF2ZSB0aGUgQVMgYXVkaWVuY2UgcmVzdHJpY3QgdGhlIHJlc291cmNl
cyB0aGUgQVQgaXMgZ29vZCBhdC4gKEFUIHNob3VsZCBiZSBkb2luZyB0aGF0IG5vdykNCkluIHRo
ZSB0b2tlbiByZXNwb25zZSBpbmNsdWRlIHRoZSBsaXN0IG9mIGF1ZGllbmNlL3MgdGhlIHRva2Vu
IGlzIHByZXNlbnRhYmxlIGF0LiAgVGhlIGNsaWVudCB3b3VsZCB0aHJvdyBhbiBlcnJvciBpZiB0
aGUgUlMgaXQgaW50ZW5kcyB0byBzZW5kIHRoZSB0b2tlbiB0byBpcyBub3Qgb24gdGhlIGxpc3Qu
ICAgVGhlIFJTIHRoZSB0b2tlbiBpcyBnb29kIGF0IG1pZ2h0IGNoYW5nZSBiYXNlZCBvbiBzY29w
ZXMsIGNsaWVudF9pZCBhbmQgcmVzb3VyY2Ugb3duZXIuICAgVGhpcyBpcyB0aGUgcGxhY2Ugd2hl
cmUgYWxsIG9mIHRoYXQgY29tZXMgdG9nZXRoZXIuICAgSW4gc29tZSBjYXNlcyB0aGUgUlMgYW5k
IEFTIG1pZ2h0IG5vdCBoYXZlIGEgcHJlLWVzdGFibGlzaGVkIHJlbGF0aW9uc2hpcC4gICBUaGUg
Y2xpZW50IHNob3VsZCBzZW5kIHRoZSBSUyBiYXNlIFVSSSB0byB0aGUgQVMgYXMgcGFydCBvZiB0
aGUgcmVxdWVzdC4gIFRoZSBBUyBjYW4gdXNlIHRoYXQgdG8gYXVkaWVuY2UgcmVzdHJpY3QgdGhl
IEFUIGFuZCBpc3N1ZSB0aGUgQVQgb3IgcmVmdXNlIHRvIGlzc3VlIHRoZSBBVCBiYXNlZCBvbiBw
b2xpY3kuDQpJdCBjYW4gYWxzbyB1c2UgdGhlIGF1ZGllbmNlIGluIHRoZSByZXF1ZXN0IHRvIGRv
d24gYXVkaWVuY2UgdGhlIEFUIGlmIHRoZSBkZWZhdWx0IGlzIHRvIGhhdmUgbXVsdGlwbGUgYXVk
aWVuY2VzLiAgICBXZSBtYXkgd2FudCB0byB1c2UgYSB0ZXJtIG90aGVyIHRoYW4gYXVkaWVuY2Ug
Zm9yIHRoaXMgbGlrZSByZXNvdXJjZSBvciBkZXN0aW5hdGlvbi4gIEl0IGlzIGEgYXVkaWVuY2Ug
YnV0IHRoYXQgdGVybSBtaWdodCBjb25mdXNlIHBlb3BsZSB3aXRoIEFULg0KDQpXZSBkaWQgdGFs
ayBhYm91dCBicmVha2luZyBhdWRpZW5jZSBvdXQgb2YgUE9QIGtleSBkaXN0cmlidXRpb24sIGFu
ZCBCcmlhbiBDYW1wYmVsbCBkaWQgYSBkcmFmdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl
Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRt
bCUyZmRyYWZ0LWNhbXBiZWxsLW9hdXRoLWRzdDRqd3QmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1TVHIlMmI0a3JkMWh5OGg2ZUhP
Q0xoMVB6UWFLTVVoV2xLVjJpJTJmQ0wwSzFTUSUzZD4uDQoNClRvIGRvIHRoaXMgd2UgY291bGQg
dGFrZSBkc3Q0and0IGFuZCBhZGQgYW5vdGhlciBzcGVjIHRoYXQgYWRkcyBhIG5ldyBkc3QgcGFy
YW1ldGVyIHRvIHRoZSB0b2tlbiBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludHMgcmVxdWVzdHMg
VGhhdCB3b3VsZCBiZSBhIHNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIGRzdCB2YWx1ZXMuICBhbmQg
aW4gdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdvdWxkIGJlIGEgSlNPTiBh
cnJheSBvZiBkc3QgdmFsdWVzLg0KDQozKSBIYXZlIHRoZSBBUyBhbHdheXMgcmV0dXJuIGFsbCB0
aGUgbGlzdCBvZiBhbGwgUlMgdGhlIHRva2VuIGNhbiBiZSB1c2VkIGF0IChiYXNpY2FsbHkgTmF0
J3MgbGluayByZWxhdGlvbnNoaXAgcHJvcG9zYWwpLiAgSXQgbmVlZHMgYSB3YXkgdG8gaGFuZGxl
DQpkb3duIGRlc3RpbmF0aW9uaW5nIG9mIEFUIGFuZCB0byBhbGxvdyBmb3IgdW4tY29uZmlndXJl
ZCBSUyB0aGF0IGl0IG1pZ2h0IGlzc3VlIGEgdG9rZW4gZm9yLiAgU28gY291bGQgYmUgY29tYmlu
ZWQgd2l0aCBkc3QgZnJvbSAyLiAgQmFzaWNhbGx5IHJldHVybmluZyB0aGUgYWNjZXB0YWJsZSBk
ZXN0aW5hdGlvbnMgYXMgbGluayBoZWFkZXJzIHZzIEpTIGluIHRoZSByZXNwb25zZSBpcyBtb3N0
bHkgYSBzdHlsZSBpc3N1ZSB0aGF0IG90aGVyIHBlb3BsZSBjYW4gYmlrZSBzaGVkLg0KDQoNCjQp
IFRyeWluZyB0byBhZGQgYWxsIHRoZSBSUyB0byB0aGUgQVMgZGlzY292ZXJ5IGRvY3VtZW50LiAg
VGhpcyBzZWVtcyBpbXByYWN0aWNhbCBhcyB0aGVyZSB3b3VsZCBiZSBtdWx0aXBsZSBwcm90b2Nv
bHMgYW5kIGRvZXNu4oCZdCBhZGRyZXNzIHVuLWNvbmZpZ3VyZWQgUlMuDQoNCjUpIFNvbWUgbmV3
IEFTIGVuZHBvaW50IHRoYXQgdGhlIGNsaWVudCBjb3VsZCBpbnRyb3NwZWN0IHRoZSBSUyBVUkkg
YW5kIGdldCBiYWNrIG1ldGFkYXRhIGFib3V0IGlmIHRoZSBjbGllbnQgc2hvdWxkIHNlbmQgdG9r
ZW5zIHRoZXJlLg0KICAgIEEgY291cGxlIG9mIHByb2JsZW1zIHdpdGggdGhpcy4gIFRoZSBmaXJz
dCBpcyB0aGF0IGl0IHdvdWxkIG5vdCBzdXBwb3J0IHVuLWNvbmZpZ3VyZWQgUlMgdW5sZXNzIHlv
dSBhZGQgZHN0IHRvIHRoZSB0b2tlbiBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludHMuICAgVGhl
IG90aGVyIGlzIHRoYXQgdGhlIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgZG9lc27igJl0IGhhdmUg
dGhlIGNvbnRleHQgb2YgdGhlIFJPIGFuZCBjbGllbnRfaWQgdW5sZXNzIHlvdSBhbHNvIHBhc3Mg
dGhlIGNvZGUvUlQgYW5kIGNsaWVudF9pZCwgYW5kIHByb2JhYmx5IGNsaWVudCBjcmVkZW50aWFs
cy4gICAgQmFzaWNhbGx5IHRoaXMgaXMgdHJ5aW5nIHRvIGludHJvc3BlY3QgdGhlIEFUIHRvIGRl
dGVybWluZSB0aGUgYXVkaWFuY2UvZHN0LiAgIEJ5IHRoZSB0aW1lIHlvdSBidWlsZCBhIG5ldyBp
bnRyb3NwZWN0aW9uIGVuZHBvaW50IHNlY3VyZWx5IGl0IGlzIGdvaW5nIHRvIGxvb2sgbGlrZSB0
aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBhIGJpdCBtb3JlIG1ldGEgZGF0YSBhYm91dCB0aGUgdG9r
ZW4gYmV5b25kIGV4cGlyeSBhbmQgc2NvcGVzLg0KDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGdvIGEg
aGVhZCB3aXRoIHRoZSByZW5hbWVkICJPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlz
Y292ZXJ5IE1ldGFkYXRh4oCdDQpJIGFtIGFsc28gZmluZSB3aXRoIG1ha2luZyB0aGUgZGVmYXVs
dCBkb2N1bWVudCAnb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgIGFzIGxvbmcgYXMgd2UgYWxsb3cg
Zm9yIHByb3RvY29sIHNwZWNpZmljIHZhcmlhdGlvbiBzbyB0aGF0IFNDSU0yIGNvdWxkIGRlZmlu
ZSBhIGZpbGUgbmFtZS4gICAgSWYgcGVvcGxlIHdhbnQgd2UgY291bGQgZG8gYSBBUEkgIHRvIGZp
bGUgbmFtZSByZWdpc3RyeSBzbyB0aGF0IHByb3RvY29sIHNwZWNpZmljIG9uZXMgY2FuIGJlIGRl
ZmluZWQuDQoNCldlIGFyZSBhbGwtcmVhZHkgd29ya2luZyBvbiBvcHRpb24gMSB0byBzZWN1cmUg
QVQsIHdlIG5lZWQgYSBzcGVjIGxpa2UgSSBwcm9wb3NlIGluIDIgZm9yIGJlYXJlciB0b2tlbnMu
ICBXZSBjYW4gYWRkIG9uZSByZXF1ZXN0IHBhcmFtZXRlciBhbmQgYSBiaXQgbW9yZSB0b2tlbiBt
ZXRhLWRhdGEgdG8gdGhlIHRva2VuIHJlc3BvbnNlIGFuZCB0aGF0IHRha2VzIGNhcmUgb2YgdGhl
IHByb2JsZW0uICAgSG9uZXN0bHkgd2UgcHJvYmFibHkgc2hvdWxkIGhhdmUgc2VwYXJhdGVkIHNj
b3BlIGFuZCBkZXN0aW5hdGlvbiBpbiB0aGUgZmlyc3QgcGxhY2UgYW5kIHJldHVybmVkIGJvdGgg
ZHN0IGFuZCBzY29wZSBpbiB0aGUgcmVzcG9uc2UgYWxsIGFsb25nLCBzbyB0aGlzIGlzIHVwZGF0
ZSB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZWlzdGluZyBhcmNoaXRlY3R1cmUgb2YgT0F1
dGggMi4NCg0KTGV0cyBrZWVwIHRoZSB0d28gaXNzdWVzIHNlcGFyYXRlLg0KDQpKb2huIEIuDQoN
Cg0KDQoNCk9uIE1hciAxMSwgMjAxNiwgYXQgMTI6MDcgQU0sIEFudGhvbnkgTmFkYWxpbiA8dG9u
eW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToN
Cg0KVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEFTIGFuZCBSUyBuZWVkIHRvIGJlIHNjb3BlZCB0
byDigJxkb2VzIHRoaXMgUlMgYWNjZXB0IHRva2VucyBmcm9tIHRoaXMgQVPigJ0gYXMgYSBsaXN0
IGlzIHRvbyBtdWNoIGluZm9ybWF0aW9uIHRoYXQgY291bGQgYmUgdXNlZCBpbiB0aGUgd3Jvbmcg
d2F5DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIE5hdCBTYWtpbXVyYQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2IDY6MjUg
UE0NClRvOiBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGls
Lmh1bnRAb3JhY2xlLmNvbT4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0
aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3Qg
Q2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5DQoNClBoaWwsDQoNClJpZ2h0LiBTbyB3aGF0IG15
IGNvbmRpdGlvbmFsIGFwcHJvdmFscyAoMTEgY29uZGl0aW9ucyBpbiB0b3RhbCkgc2FpZCB3YXMg
dG8gZHJvcCB0aGUgd29yZCAiZGlzY292ZXJ5IiBmcm9tIGV2ZXJ5d2hlcmUuIFRoaXMgaXMgbm90
IGEgZGlzY292ZXJ5IHNwZWMuIFRoaXMgaXMgYSBjb25maWd1cmF0aW9uIGxvb2t1cCBzcGVjIGFz
IHlvdSBjb3JyZWN0bHkgcG9pbnRzIG91dC4gU28sIEkgYW0gd2l0aCB5b3UgaGVyZS4NCg0KQWxz
bywgbXkgMm5kIGNvbmRpdGlpb24gaXMgZXNzZW50aWFsbHkgc2F5aW5nIHRvIGRyb3Agc2VjdGlv
biAzLg0KDQpPbmUgdGhpbmcgdGhhdCBJIG92ZXJsb29rZWQgYW5kIGFtIHdpdGggeW91IGlzIHRo
YXQgd2UgbmVlZCB0byBiZSBhYmxlIHRvIGV4cHJlc3MgdGhlIEFTLVJTIHJlbGF0aW9uc2hpcHMu
IEkgaGF2ZSBiZWVuIHByZWFjaGluZyB0aGlzIGluIHRoZSBvdGhlciB0aHJlYWQgZm9yIHNvIG1h
bnkgdGltZXMgYXMgeW91IGtub3cgc28gSSB0aG91Z2h0IEkgcG9pbnRlZCBpdCBvdXQsIGJ1dCBt
aXNzZWQgYXBwYXJlbnRseSBpbiBteSBwcmV2aW91cyBjb21tZW50LiBTbywgSSB3b3VsZCBhZGQg
bXkgMTJ0aCBjb25kaXRpb246DQoNCjEyLiBBIHdheSB0byBleHByZXNzIGEgbGlzdCBvZiB2YWxp
ZCBSU3MgZm9yIHRoaXMgQVMgbmVlZHMgdG8gYmUgYWRkZWQgdG8gc2VjdGlvbiAyLg0KDQpCZXN0
LA0KDQpOYXQNCg0KMjAxNi0wMy0xMSAyOjA5IEdNVCswOTowMCBQaGlsIEh1bnQgKElETSkgPHBo
aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0KSSBzdHJv
bmdseSBvcHBvc2UuIDIgbWFqb3IgaXNzdWVzLg0KDQpUaGlzIGlzIG5vdCBzZXJ2aWNlIGRpc2Nv
dmVyeSB0aGlzIGlzIGNvbmZpZ3VyYXRpb24gbG9va3VwLiBUaGUgY2xpZW50IG11c3QgaGF2ZSBh
bHJlYWR5IGRpc2NvdmVyZWQgdGhlIG9hdXRoIGlzc3VlciB1cmkgYW5kIHRoZSByZXNvdXJjZSB1
cmkuDQoNClRoZSBvYmplY3RpdmUgd2FzIHRvIHByb3ZpZGUgYSBtZXRob2QgdG8gZW5zdXJlIHRo
ZSBjbGllbnQgaGFzIGEgdmFsaWQgc2V0IG9mIGVuZHBvaW50cyB0byBwcmV2ZW50IG1pdG0gb2Yg
ZW5kcG9pbnRzIGxpa2UgdGhlIHRva2VuIGVuZHBvaW50IHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIu
DQoNClRoZSBkcmFmdCBkb2VzIG5vdCBhZGRyZXNzIHRoZSBpc3N1ZSBvZiBhIGNsaWVudCBiZWlu
ZyBnaXZlbiBhIGJhZCBlbmRwb2ludCBmb3IgYW4gcnMuIFdoYXQgd2UgZW5kIHVwIHdpdGggaXMg
YSBwcm9taXNjdW91cyBhdXRoeiBzZXJ2aWNlIGdpdmluZyBvdXQgdG9rZW5zIHRvIGFuIHVud2l0
dGluZyBjbGllbnQuDQoNClBoaWwNCg0KT24gTWFyIDEwLCAyMDE2LCBhdCAwODowNiwgVmxhZGlt
aXIgRHpodXZpbm92IDx2bGFkaW1pckBjb25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29u
bmVjdDJpZC5jb20+PiB3cm90ZToNCisxIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZXNlDQpPbiAx
MC8wMy8xNiAxNzozNSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQoNCisxDQoNCg0KDQpPbiBUaHUs
IE1hciAxMCwgMjAxNiBhdCA2OjA0IEFNLCBSb2xhbmQgSGVkYmVyZyA8cm9sYW5kLmhlZGJlcmdA
dW11LnNlPjxtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlPg0KDQp3cm90ZToNCg0KDQoNCkkg
c3VwcG9ydCB0aGlzIGRvY3VtZW50IGJlaW5nIG1vdmVkIGZvcndhcmQgd2l0aCB0aGVzZSB0d28g
Y2hhbmdlczoNCg0KDQoNCi0gY2hhbmdlIG5hbWUgdG8g4oCcT0F1dGggMi4wIEF1dGhvcml6YXRp
b24gU2VydmVyIERpc2NvdmVyeSBNZXRhZGF0YeKAnSBhcw0KDQpwcm9wb3NlZCBieSBCcmlhbiBh
bmQNCg0KLSB1c2UgdGhlIFVSSSBwYXRoIHN1ZmZpeCDigJlvYXV0aC1hdXRob3JpemF0aW9uLXNl
cnZlcuKAmSBpbnN0ZWFkIG9mDQoNCuKAmW9wZW5pZC1jb25maWd1cmF0aW9u4oCZIGFzIHByb3Bv
c2VkIGJ5IEp1c3Rpbi4NCg0KDQoNCjE4IGZlYiAyMDE2IGtsLiAxNDo0MCBza3JldiBIYW5uZXMg
VHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hv
ZmVuaWdAZ214Lm5ldD4NCg0KOg0KDQoNCg0KSGkgYWxsLA0KDQoNCg0KVGhpcyBpcyBhIExhc3Qg
Q2FsbCBmb3IgY29tbWVudHMgb24gdGhlICBPQXV0aCAyLjAgRGlzY292ZXJ5DQoNCnNwZWNpZmlj
YXRpb246DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRp
c2NvdmVyeS0wMTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1
dGgtZGlzY292ZXJ5LTAxJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
MTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmc2RhdGE9dzMlMmJpaWFXb244MUxKQ1UlMmIybUNQUm1BJTJickVDQkhn
cXlScjBPZ3FpV1NIVSUzZD4NCg0KDQoNClNpbmNlIHRoaXMgZG9jdW1lbnQgd2FzIG9ubHkgYWRv
cHRlZCByZWNlbnRseSB3ZSBhcmUgcnVubmluZyB0aGlzIGxhc3QNCg0KY2FsbCBmb3IgKiozIHdl
ZWtzKiouDQoNCg0KDQpQbGVhc2UgaGF2ZSB5b3VyIGNvbW1lbnRzIGluIG5vIGxhdGVyIHRoYW4g
TWFyY2ggMTB0aC4NCg0KDQoNCkNpYW8NCg0KSGFubmVzICYgRGVyZWsNCg0KDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcg
bGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj
cm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4
NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekpp
WHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZD4NCg0K4oCUIFJvbGFuZA0KDQoNCg0K4oCd
RXZlcnlib2R5IHNob3VsZCBiZSBxdWlldCBuZWFyIGEgbGl0dGxlIHN0cmVhbSBhbmQgbGlzdGVu
LiINCg0KPkZyb20g4oCZT3BlbiBIb3VzZSBmb3IgQnV0dGVyZmxpZXPigJkgYnkgUnV0aCBLcmF1
c3MNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz
JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0w
MSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4
ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10
TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoN
Cg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll
dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0
dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh
JTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3
YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0
OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10TkNp
a21YREJGN3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls
aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj
cm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4
NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekpp
WHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZD4NCg0KDQoNCi0tDQpOYXQgU2FraW11cmEg
KD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEu
b3JnLzxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o
dHRwJTNhJTJmJTJmbmF0LnNha2ltdXJhLm9yZyUyZiZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTZGVm1kTjdhZDBZem9ZS1NORiUy
ZkRPJTJmZkcyRUYxaGFqNWFPSGlNaWQ2VU1JJTNkPg0KQF9uYXRfZW4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B
dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJm
bGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJnNkYXRhPWJLc0VWQlVYYzUyOHlhQU1MbXljWGNMMzMlMmJGSkNRcm5x
OWFzeFJvNUhlOCUzZD4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP
QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0
cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRh
PTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0
MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRh
PWJLc0VWQlVYYzUyOHlhQU1MbXljWGNMMzMlMmJGSkNRcm5xOWFzeFJvNUhlOCUzZD4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls
ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm
O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K
CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRpc2FncmVlLCB3aGF0IHB1cnBvc2UgaXMg
dGhpcyBhY3Rpdml0eSBzb2x2aW5nIHRoZW4sIGl0IHdhcyBiZWluZyBwdXNoZWQgYXMgd2hhdCB3
YXMgbmVlZCB0byBzb2x2ZSB0aGUgTWl4LXVwLCBidXQgdGhhdCBpcyBub3QgdHJ1ZS4gU28gbm93
IHlvdSBhcmUgc3VnZ2VzdGluZyBhIGNoYW5nZSBpbg0KIHNjb3BlIGFuZCBub3QgZGVhbGluZyB3
aXRoIGRpc2NvdmVyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8
YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAxMSwgMjAxNiAzOjExIFBNPGJyPg0KPGI+
VG86PC9iPiBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0Ozxicj4NCjxiPkNj
OjwvYj4gb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
ZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292
ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij5JIHRlbmQgdG8gYWdyZWUgd2l0aCBKb2huIHRoYXQgYWRkcmVzc2luZyB0
aGUgY29uY2VybnMgUGhpbCByYWlzZXMgc2hvdWxkIGJlIHBhcnQgb2YgKGV4dGVuc2lvbiB0bykg
dGhlIGNvcmUgcHJvdG9jb2wuJm5ic3A7IEFuZCB0aGF0IHRob3NlIGtpbmRzIG9mIGNvbmNlcm5z
IGRvbid0IG1hbmlmZXN0IGluIHRoZSB3YXkgT0F1dGggaXMgdHlwaWNhbGx5IGRlcGxveWVkDQog
bm93LiA8YnI+DQo8YnI+DQpUaGUgaG9wZWZ1bGx5IHNvb24gdG8gYmUgbmFtZWQgJnF1b3Q7T0F1
dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhJnF1b3Q7IHNob3VsZCBrZWVwIGl0
J3Mgc2NvcGUgdG8gdGhlIHB1Ymxpc2hpbmcgb2YgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWV0YWRh
dGEuIFRoZSBhY3Qgb2YgZG9pbmcgZGlzY292ZXJ5IGlzIGJleW9uZCBpdHMgc2NvcGUgYW5kIHNv
IGlzIHRyeWluZyB0byBwcmV2ZW50IGEgY2xpZW50IGZyb20gcHJlc2VudGluZyBhIHRva2VuIHRv
DQogc29tZXBsYWNlIGl0IHNob3VsZG4ndC4gPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1hciAxMSwgMjAxNiBhdCA5OjA4
IEFNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklubGluZTxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1h
ciAxMSwgMjAxNiwgYXQgMTI6MTMgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNs
ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5Kb2huPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkluIG1hbnkgY2FzZSBhbGwgdGhlIEFTIGhhcyB0byBjaGVjayBp
cyB0aGUgZG9tYWluIG5hbWUgY29tcG9uZW50IHRvIGNoZWNrIGZvciBtaXRtLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QT1AgYW5k
IHRoZSBvdGhlciBzb2xucyBhcmUgZHJhbWF0aWNhbGx5IG1vcmUgY29tcGxleCB0aGFuIGEgc2lt
cGxlIGNoZWNrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBwcm9wb3NpbmcgZGlu
ZyB0aGF0IGNoZWNrIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IG9yIHRva2VuIGVuZHBv
aW50IGFzIHBhcnQgb2YgQVQgaXNzdWFuY2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIHVwIHRvIHRoZSBBUyBob3cgbXVj
aCBvZiB0aGUgcGF0aCB0byB2YWxpZGF0ZSBhbmQgb3IgcHV0IGluIHRoZSBhdWQgb3IgZHN0LiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSBpdCBhcyBwYXJ0IG9mIHRoZSBkaXNj
b3ZlcnkoYmFkIG5hbWUgYXNpZGUpIHByb2JsZW0gYmVjYXVzZSB3ZSBkaXNjdXNzZWQgdGhhdCBp
ZiBhIGNsaWVudCBmaW5kcw0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0
aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5leGFtcGxlLmNvbSUyZiZhbXA7
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5
NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh
bXA7c2RhdGE9ZmlTOGY2MHlwaVhoeU0wcVZUZXFsJTJiJTJiT3pIMndibUVDUUU3SjVUdEdQUU0l
M2QiIHRhcmdldD0iX2JsYW5rIj4NCmFwcC5leGFtcGxlLmNvbTwvYT4gaG93IGRvIHdlIGVuc3Vy
ZSBpdCBnZXRzIGEgY29tcGxldGUgc2V0IG9mIG9hdXRoIGVuZHBvaW50cyBhcyBhIHZhbGlkIHNl
dCBvZiBlbmRwb2ludHMtLXRoYXQgYSBoYWNrZXIgaGFzIG5vdCBpbnNlcnRlZCBvbmUgb2YgdGhl
aXIgb3duIGVuZHBvaW50cy4gVGhlIG1vc3QgaW1wb3J0YW50IGVuZHBvaW50IHRvIGdldCByaWdo
dCBpcyBlbnN1cmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIChhbmQgb3B0aW9uYWxseSB0aGUNCiBw
YXRoKSBpcyB0aGUgY29ycmVjdCBvbmUuIFdlIGNhbid0IHJlYWxseSBkZWZpbmUgcmVzb3VyY2Ug
ZGlzY292ZXJ5IGJ1dCB3ZSBjYW4gdmFsaWRhdGUgaXQgdG8gc29tZSBkZWdyZWUuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IGlzIHBhcnQgb2YgY29yZSBwcm90
b2NvbCBzZWN1cml0eSBhbmQgc2hvdWxkL211c3Qgbm90IHJlcXVpcmUgZGlzY292ZXJ5LiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X
aGF0IGlzIDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r
LmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZhcHAuZXhhbXBsZS5jb20mYW1wO2RhdGE9MDElN2MwMSU3
Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFl
NTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWpBc1pR
ZUNoSiUyYlIxbGJ5Qm9WS3doZUlZaTNQaVdMcnElMmJ4RExicVU2cnhrJTNkIiB0YXJnZXQ9Il9i
bGFuayI+DQphcHAuZXhhbXBsZS5jb208L2E+ID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgaXQgaXMgdGhlIHJlc291cmNlIHRo
ZW4gdGhlIGNsaWVudCB3b3VsZCBiZSBwcmVjb25maWd1cmVkIGZvciBpdOKAmXMgQVMgb3V0IG9m
IGJhbmQgb3Igb3B0aW9uYWxseSB3b3VsZCBkbyBkaXNjb3Zlcnkgb24gdGhlIGlzc3VlciB1cmkg
dGhhdCB5b3UgYWRtaXQgbmVlZHMgdG8gYmUgY29uZmlndXJlZCBvdXQgb2YgYmFuZCBzb21lIHdh
eSAobm90ZSBkaXNjb3ZlcnkgaXMgb3B0aW9uYWwpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBBUyBtZXRhLWRhdGEgZHJhZnQgaXQg
d291bGQgZG8gYSBnZXQgb24gYSB3ZWxsIGtub3duIGZpbGUgdGhhdCB3b3VsZCBoYXZlIGNvbmZp
Z3VyYXRpb24gZm9yIHRoZSBBUywgYnV0IG5vdCB0aGUgUlMsIHRob3VnaCBzb21lIEFQSSBtYXkg
b3B0aW9uYWxseSBsaXN0IGEgQVBJIGVuZHBvaW50IGxpa2UgY29ubmVjdCBoYXMuICZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg
Y2xpZW50IHRoZW4gbWFrZXMgYSBhdXRob3JpemF0aW9uIHJlcXVlc3QgKGFmdGVyIHJlZ2lzdGVy
aW5nIG91dCBvZiBiYW5kIG9yIGR5bmFtaWNhbGx5KS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBwYXJ0IG9mIHRoZSBhdXRob3Jp
emF0aW9uIHJlcXVlc3QgZm9yIGltcGxpY2l0IGl0IGNvdWxkIHByb3ZpZGUgdGhlIGF1ZC9kc3Qg
dGhhdCBpdCB3YW50cyB0aGUgdG9rZW4gZm9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhhdCBpcyBub3Qgc2VudCB0aGVuIHRoZSBhdWQv
ZHN0IGFyZSBpbXBsaWNpdCBpbiB0aGUgc2NvcGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2xpZW50IGdldHMgYmFjayBhIEFUIHdp
dGggYSBsaXN0IG9mIHNjb3BlcyBncmFudGVkLCBhdWQvZHN0IGFsbG93ZWQgYW5kIHRpbWUgdG8g
bGl2ZSBmb3IgdGhlIHRva2VuIChvbmUgZXh0cmEgdGhpbmcgcmV0dXJuZWQpPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZG9lc27igJl0
IHJlcXVpcmUgYW55IGRpc2NvdmVyeSAoeWVzIHRoZXJlIGlzIGEgb3B0aW9uYWwgQVMgbWV0YS1k
YXRhIGRpc2NvdmVyeSBidXQgbm90IHJlcXVpcmVkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHByZWZlciB0byBmaXggdGhlIFJTIG1hbiBp
biB0aGUgbWlkZGxlIGlzc3VlIGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIGFuZCBub3QgcGFydCBv
ZiBkaXNjb3ZlcnkgdGhhdCBzaG91bGQgcmVtYWluIG9wdGlvbmFsLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhvbmVzdGx5IGRvbuKAmXQg
cXVpdGUga25vdyBob3cgdGhlIGNsaWVudCBsZWFybnMgYWJvdXQgdGhpcyBiYWQgUlMgYW5kIHN0
YXJ0cyB0YWxraW5nIHRvIGl0LCBzbyB0aGlzIG1heSBiZSBhIHNvbHV0aW9uIHRvIGEgcHJvYmxl
bSB0aGF0IGRvZXNu4oCZdCB5ZXQgZXhpc3QuICZuYnNwOyBUaGUgb25lIHBsYWNlIHRoaXMgaXMg
cG9zYWJsZSBpcyBpZiB0aGUgcmVnaXN0cmF0aW9uIGZvciB0aGUgY2xpZW50IGlzIGNvbXByb21p
c2VkLiZuYnNwOw0KIEhvd2V2ZXIgd2UgYXJlIGRpc2N1c3Npbmcgb3RoZXIgbWl0aWdhdGlvbnMg
Zm9yIHRoYXQgdGhhdCBhbHNvIGV4cGxpY2l0bHkgZG8gbm90IHJlcXVpcmUgZGlzY292ZXJ5Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2hu
IEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgc3R1Y2sgb24gd2ViZmluZ2VyIG9yIHdl
bGwta25vd24uIEJlY2F1c2UgdGhpcyBpcyBjb25maWcgbWF5YmUgaXQgc2hvdWxkIGJlIGFuIG9h
dXRoIGVuZHBvaW50LiZuYnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGJyPg0KT24gTWFyIDExLCAyMDE2LCBhdCAwNjo1MSwgSm9obiBCcmFkbGV5ICZsdDs8YSBo
cmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3
anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIFBoaWwgaXMgcHJvcG9zaW5nIHNvbWV0aGluZyBk
aWZmZXJlbnQuICZuYnNwOyBTaG91bGQgdGhlIGNsaWVudCBzZW5kIGEgdG9rZW4gZnJvbSB0aGlz
IEFTIHRvIHRoYXQgUlMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SGlzIGdvYWwgaXMgdG8gcHJldmVudCBtYW4gaW4gdGhlIG1pZGRsZSBhdHRh
Y2tzIHdoZXJlIGEgYmFkIFJTIGdldHMgYSBBVCB0aGF0IGlzIGF1ZGlhbmNlZCB0by9hY2NlcHRl
ZCBieSBhbm90aGVyIFJTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGF0IGlzIHNlcGFyYXRlIGZyb20gdGhlIHF1ZXN0aW9uIG9mIGlmIGEg
UlMgYWNjZXB0cyB0b2tlbnMgZnJvbSBhIGdvb2QgQVMuICZuYnNwOyBBIGJhZCBBUyB3b3VsZCBh
bHdheXMgc2F5IHllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+V2UgbmVlZCB0byBiZSBjYXJlZnVsIG9mIHdoYXQgaWYgYW55dGhpbmcgdGhl
IFJTIHByb3ZpZGVzIHRvIHRoZSBjbGllbnQgYXMgbWV0YS1kYXRhIHdpdGhvdXQgdmFsaWRhdGlv
bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Q3VycmVudGx5IHRoZSBjbGllbnQgY2FuIHByb3ZpZGUgYSBsaXN0IG9mIHNjb3BlcyByZXF1aXJl
ZCB0byBnZXQgYWNjZXNzLiAmbmJzcDsgSSBwZXJzb25hbGx5IGZlZWwgaXQgd291bGQgYmUgdXNl
ZnVsIHRvIGFsc28gaW5jbHVkZSBpbiB0aGUgdW5hdXRoZW50aWNhdGVkIGVycm9yIHJlc3BvbnNl
IGFuIGluZGljYXRpb24gb2Ygd2hhdCBBUEkgdGhlIHJlc291cmNlIHN1cHBvcnRzLiZuYnNwOyBT
YXkg4oCcc2NpbTLigJ0gYXMgYW4gZXhhbXBsZS4NCiAmbmJzcDsgSSBkb27igJl0IHRoaW5rIGFk
ZGluZyB0aGF0IGlzIGhvd2V2ZXIgYSBoaWdoIHByaW9yaXR5IGFzIG1vc3QgaWYgYWxsIGNsaWVu
dHMga25vdyB3aGF0IEFQSSB0aGV5IGV4cGVjdC4gJm5ic3A7IEl0IG1pZ2h0IGJlIHVzZWZ1bCBp
ZiBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUgaWYgYSBjbGllbnQgd2VyZSB0byBiZSBnaXZl
biBhIFJTIFVSSSBpdCBjb3VsZCBjaGVjayB0byBzZWUgaWYgaXQgaXMgYSBwcm90b2NvbCB0aGF0
IGl0IHN1cHBvcnRzIGJlZm9yZQ0KIGJvdGhlcmluZyB3aXRoIE9BdXRoLiAmbmJzcDsgJm5ic3A7
SSBleHBlY3QgdGhhdCBhIGxvdCBvZiBwZW9wbGUgd2lsbCB3YW50IHRoYXQgbGVmdCB0byB0aGUg
QVBJIGRlZmluaXRpb24uICZuYnNwOyBJIHRoaW5rIHdlIGNhbiB0YWxrIGFib3V0IGl0IGJ1dCBy
YXRlIHRoaXMgbG93IHByaW9yaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdGhlIFJTIGdpdmluZyBvdXQgYSBsaXN0
IG9mIEFTIHRoYXQgaXQgdHJ1c3RzIGlzIGEgZ2VuZXJhbGx5IGJhZCBpZGVhLiZuYnNwOyBJIGhv
cGUgdGhhdCBpcyBub3Qgb24gdGhlIHRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQgdGhpbmsgdGhhdCBwcmV2ZW50aW5n
IGEgY2xpZW50IGZyb20gc2VuZGluZyBhIHRva2VuIHRvIHRoZSB3cm9uZyBSUyBpcyBwYXJ0IG9m
IGEgQVMgbWV0YS1kYXRhIGRpc2NvdmVyeSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIGhvd2V2ZXIgdGhpbmsgdGhhdCBp
dCBpcyBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPldlIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgYXMgYSBzZXBhcmF0ZSBw
cm9ibGVtIHRvIEFTIG1ldGEtZGF0YSBkaXNjb3Zlcnkgd2hlcmUgdGhlIGVuZHBvaW50cyBvZiB0
aGUgQVMgYW5kIGl04oCZcyBjb25maWd1cmF0aW9uIGFyZSBkaXNjb3ZlcnkuICZuYnNwOyBTb3Jy
eSBmb3IgcGVyaGFwcyBzdGF0aW5nIHRoZSBvYnZpb3VzLCBidXQgdGhlIFJTIGlzIGV4cGxpY2l0
bHkgbm90IHBhcnQgb2YgdGhlIEFTIGluIE9BdXRoDQogMi4gJm5ic3A7IFN0YXJ0aW5nIGluIFdB
UCB0aGF0IHdhcyBhIGNvcmUgcHJpbmNpcGFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3ZSBoYXZlIGEgbnVtYmVyIG9mIG9wdGlvbnMg
dG8gYWRkcmVzcyB0aGUgUlMgdG9rZW4gbGVha2FnZSB2aWEgTWlUTSBhdHRhY2tzLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBQb1AgYm91
bmQgdG9rZW5zLiZuYnNwOyBJZiB0aGV5IGFyZSBib3VuZCB0byB0aGUgVExTIGNoYW5uZWwgYnkg
bXV0dWFsIFRMUyBvciBUb2tlbiBiaW5kaW5nIHRoZXkgY2Fubm90IGJlIHJlcGxheWVkLiZuYnNw
OyBTaWduZWQgbWVzc2FnZXMgd2hlcmUgdGhlIHNpZ25pbmcgY292ZXJzIHRoZSBSUyBIb3N0IGFu
ZCBwYXRoIGNvbXBvbmVudHMsICZuYnNwO2Fsc28gd291bGQgd29yay48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgSGF2ZSB0aGUgQVMgYXVk
aWVuY2UgcmVzdHJpY3QgdGhlIHJlc291cmNlcyB0aGUgQVQgaXMgZ29vZCBhdC4gKEFUIHNob3Vs
ZCBiZSBkb2luZyB0aGF0IG5vdykmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSB0b2tlbiByZXNwb25zZSBpbmNsdWRlIHRoZSBs
aXN0IG9mIGF1ZGllbmNlL3MgdGhlIHRva2VuIGlzIHByZXNlbnRhYmxlIGF0LiZuYnNwOyBUaGUg
Y2xpZW50IHdvdWxkIHRocm93IGFuIGVycm9yIGlmIHRoZSBSUyBpdCBpbnRlbmRzIHRvIHNlbmQg
dGhlIHRva2VuIHRvIGlzIG5vdCBvbiB0aGUgbGlzdC4gJm5ic3A7IFRoZSBSUyB0aGUgdG9rZW4g
aXMgZ29vZCBhdCBtaWdodCBjaGFuZ2UgYmFzZWQgb24gc2NvcGVzLA0KIGNsaWVudF9pZCBhbmQg
cmVzb3VyY2Ugb3duZXIuICZuYnNwOyBUaGlzIGlzIHRoZSBwbGFjZSB3aGVyZSBhbGwgb2YgdGhh
dCBjb21lcyB0b2dldGhlci4gJm5ic3A7IEluIHNvbWUgY2FzZXMgdGhlIFJTIGFuZCBBUyBtaWdo
dCBub3QgaGF2ZSBhIHByZS1lc3RhYmxpc2hlZCByZWxhdGlvbnNoaXAuICZuYnNwOyBUaGUgY2xp
ZW50IHNob3VsZCBzZW5kIHRoZSBSUyBiYXNlIFVSSSB0byB0aGUgQVMgYXMgcGFydCBvZiB0aGUg
cmVxdWVzdC4mbmJzcDsgVGhlIEFTIGNhbiB1c2UgdGhhdA0KIHRvIGF1ZGllbmNlIHJlc3RyaWN0
IHRoZSBBVCBhbmQgaXNzdWUgdGhlIEFUIG9yIHJlZnVzZSB0byBpc3N1ZSB0aGUgQVQgYmFzZWQg
b24gcG9saWN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SXQgY2FuIGFsc28gdXNlIHRoZSBhdWRpZW5jZSBpbiB0aGUgcmVxdWVzdCB0byBkb3du
IGF1ZGllbmNlIHRoZSBBVCBpZiB0aGUgZGVmYXVsdCBpcyB0byBoYXZlIG11bHRpcGxlIGF1ZGll
bmNlcy4gJm5ic3A7ICZuYnNwO1dlIG1heSB3YW50IHRvIHVzZSBhIHRlcm0gb3RoZXIgdGhhbiBh
dWRpZW5jZSBmb3IgdGhpcyBsaWtlIHJlc291cmNlIG9yIGRlc3RpbmF0aW9uLiZuYnNwOyBJdCBp
cyBhIGF1ZGllbmNlIGJ1dCB0aGF0IHRlcm0gbWlnaHQNCiBjb25mdXNlIHBlb3BsZSB3aXRoIEFU
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X
ZSBkaWQgdGFsayBhYm91dCBicmVha2luZyBhdWRpZW5jZSBvdXQgb2YgUE9QIGtleSBkaXN0cmli
dXRpb24sIGFuZCBCcmlhbiBDYW1wYmVsbCBkaWQgYSBkcmFmdCZuYnNwOzxhIGhyZWY9Imh0dHBz
Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm
JTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dCZh
bXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0
NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj
MSZhbXA7c2RhdGE9U1RyJTJiNGtyZDFoeThoNmVIT0NMaDFQelFhS01VaFdsS1YyaSUyZkNMMEsx
U1ElM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
Y2FtcGJlbGwtb2F1dGgtZHN0NGp3dDwvYT4uDQogJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGRvIHRoaXMgd2UgY291
bGQgdGFrZSBkc3Q0and0IGFuZCBhZGQgYW5vdGhlciBzcGVjIHRoYXQgYWRkcyBhIG5ldyBkc3Qg
cGFyYW1ldGVyIHRvIHRoZSB0b2tlbiBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludHMgcmVxdWVz
dHMgVGhhdCB3b3VsZCBiZSBhIHNwYWNlIHNlcGFyYXRlZCBsaXN0IG9mIGRzdCB2YWx1ZXMuICZu
YnNwO2FuZCBpbiB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgd291bGQNCiBi
ZSBhIEpTT04gYXJyYXkgb2YgZHN0IHZhbHVlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgSGF2ZSB0aGUgQVMgYWx3YXlzIHJldHVybiBh
bGwgdGhlIGxpc3Qgb2YgYWxsIFJTIHRoZSB0b2tlbiBjYW4gYmUgdXNlZCBhdCAoYmFzaWNhbGx5
IE5hdCdzIGxpbmsgcmVsYXRpb25zaGlwIHByb3Bvc2FsKS4mbmJzcDsgSXQgbmVlZHMgYSB3YXkg
dG8gaGFuZGxlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5kb3duIGRlc3RpbmF0aW9uaW5nIG9mIEFUIGFuZCB0byBhbGxvdyBmb3IgdW4t
Y29uZmlndXJlZCBSUyB0aGF0IGl0IG1pZ2h0IGlzc3VlIGEgdG9rZW4gZm9yLiZuYnNwOyBTbyBj
b3VsZCBiZSBjb21iaW5lZCB3aXRoIGRzdCBmcm9tIDIuJm5ic3A7IEJhc2ljYWxseSByZXR1cm5p
bmcgdGhlIGFjY2VwdGFibGUgZGVzdGluYXRpb25zIGFzIGxpbmsgaGVhZGVycyB2cyBKUyBpbiB0
aGUgcmVzcG9uc2UgaXMgbW9zdGx5IGEgc3R5bGUNCiBpc3N1ZSB0aGF0IG90aGVyIHBlb3BsZSBj
YW4gYmlrZSBzaGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjQpIFRyeWluZyB0byBhZGQgYWxsIHRoZSBSUyB0byB0aGUgQVMgZGlzY292
ZXJ5IGRvY3VtZW50LiZuYnNwOyBUaGlzIHNlZW1zIGltcHJhY3RpY2FsIGFzIHRoZXJlIHdvdWxk
IGJlIG11bHRpcGxlIHByb3RvY29scyBhbmQgZG9lc27igJl0IGFkZHJlc3MgdW4tY29uZmlndXJl
ZCBSUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+NSkgU29tZSBuZXcgQVMgZW5kcG9pbnQgdGhhdCB0aGUgY2xpZW50IGNvdWxkIGludHJvc3Bl
Y3QgdGhlIFJTIFVSSSBhbmQgZ2V0IGJhY2sgbWV0YWRhdGEgYWJvdXQgaWYgdGhlIGNsaWVudCBz
aG91bGQgc2VuZCB0b2tlbnMgdGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IEEgY291cGxlIG9mIHByb2JsZW1zIHdp
dGggdGhpcy4mbmJzcDsgVGhlIGZpcnN0IGlzIHRoYXQgaXQgd291bGQgbm90IHN1cHBvcnQgdW4t
Y29uZmlndXJlZCBSUyB1bmxlc3MgeW91IGFkZCBkc3QgdG8gdGhlIHRva2VuIGFuZCBhdXRob3Jp
emF0aW9uIGVuZHBvaW50cy4gJm5ic3A7IFRoZSBvdGhlciBpcyB0aGF0IHRoZSBpbnRyb3NwZWN0
aW9uIGVuZHBvaW50IGRvZXNu4oCZdCBoYXZlIHRoZSBjb250ZXh0IG9mIHRoZSBSTw0KIGFuZCBj
bGllbnRfaWQgdW5sZXNzIHlvdSBhbHNvIHBhc3MgdGhlIGNvZGUvUlQgYW5kIGNsaWVudF9pZCwg
YW5kIHByb2JhYmx5IGNsaWVudCBjcmVkZW50aWFscy4gJm5ic3A7ICZuYnNwO0Jhc2ljYWxseSB0
aGlzIGlzIHRyeWluZyB0byBpbnRyb3NwZWN0IHRoZSBBVCB0byBkZXRlcm1pbmUgdGhlIGF1ZGlh
bmNlL2RzdC4gJm5ic3A7IEJ5IHRoZSB0aW1lIHlvdSBidWlsZCBhIG5ldyBpbnRyb3NwZWN0aW9u
IGVuZHBvaW50IHNlY3VyZWx5IGl0IGlzIGdvaW5nIHRvIGxvb2sNCiBsaWtlIHRoZSB0b2tlbiBl
bmRwb2ludCB3aXRoIGEgYml0IG1vcmUgbWV0YSBkYXRhIGFib3V0IHRoZSB0b2tlbiBiZXlvbmQg
ZXhwaXJ5IGFuZCBzY29wZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB3ZSBzaG91bGQgZ28gYSBoZWFkIHdpdGggdGhlIHJl
bmFtZWQgJnF1b3Q7T0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeSBNZXRh
ZGF0YeKAnSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SSBhbSBhbHNvIGZpbmUgd2l0aCBtYWtpbmcgdGhlIGRlZmF1bHQgZG9jdW1lbnQg
J29wZW5pZC1jb25maWd1cmF0aW9u4oCZICZuYnNwO2FzIGxvbmcgYXMgd2UgYWxsb3cgZm9yIHBy
b3RvY29sIHNwZWNpZmljIHZhcmlhdGlvbiBzbyB0aGF0IFNDSU0yIGNvdWxkIGRlZmluZSBhIGZp
bGUgbmFtZS4gJm5ic3A7ICZuYnNwO0lmIHBlb3BsZSB3YW50IHdlIGNvdWxkIGRvIGEgQVBJICZu
YnNwO3RvIGZpbGUgbmFtZSByZWdpc3RyeSBzbyB0aGF0IHByb3RvY29sDQogc3BlY2lmaWMgb25l
cyBjYW4gYmUgZGVmaW5lZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+V2UgYXJlIGFsbC1yZWFkeSB3b3JraW5nIG9uIG9wdGlvbiAxIHRvIHNl
Y3VyZSBBVCwgd2UgbmVlZCBhIHNwZWMgbGlrZSBJIHByb3Bvc2UgaW4gMiBmb3IgYmVhcmVyIHRv
a2Vucy4mbmJzcDsgV2UgY2FuIGFkZCBvbmUgcmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGEgYml0IG1v
cmUgdG9rZW4gbWV0YS1kYXRhIHRvIHRoZSB0b2tlbiByZXNwb25zZSBhbmQgdGhhdCB0YWtlcyBj
YXJlIG9mIHRoZSBwcm9ibGVtLiAmbmJzcDsgSG9uZXN0bHkNCiB3ZSBwcm9iYWJseSBzaG91bGQg
aGF2ZSBzZXBhcmF0ZWQgc2NvcGUgYW5kIGRlc3RpbmF0aW9uIGluIHRoZSBmaXJzdCBwbGFjZSBh
bmQgcmV0dXJuZWQgYm90aCBkc3QgYW5kIHNjb3BlIGluIHRoZSByZXNwb25zZSBhbGwgYWxvbmcs
IHNvIHRoaXMgaXMgdXBkYXRlIHRoYXQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBlaXN0aW5nIGFy
Y2hpdGVjdHVyZSBvZiBPQXV0aCAyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXRzIGtlZXAgdGhlIHR3byBpc3N1ZXMgc2VwYXJhdGUuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4g
Qi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAxMSwgMjAxNiwgYXQgMTI6MDcgQU0sIEFudGhv
bnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+VGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEFTIGFuZCBSUyBuZWVkIHRvIGJlIHNjb3Bl
ZCB0byDigJxkb2VzIHRoaXMgUlMgYWNjZXB0IHRva2VucyBmcm9tIHRoaXMgQVPigJ0gYXMgYSBs
aXN0IGlzIHRvbyBtdWNoIGluZm9ybWF0aW9uIHRoYXQgY291bGQgYmUgdXNlZCBpbiB0aGUgd3Jv
bmcgd2F5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGEgbmFtZT0iMTI3Mjg5NjQyOV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7T0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XSZuYnNwOzxiPk9uDQogQmVoYWxmIE9mJm5ic3A7PC9iPk5hdCBTYWtpbXVyYTxicj4NCjxi
PlNlbnQ6PC9iPiZuYnNwO1RodXJzZGF5LCBNYXJjaCAxMCwgMjAxNiA2OjI1IFBNPGJyPg0KPGI+
VG86PC9iPiZuYnNwO1BoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu
dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0
Ozxicj4NCjxiPkNjOjwvYj4mbmJzcDtvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1
YmplY3Q6PC9iPiZuYnNwO1JlOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9u
IE9BdXRoIDIuMCBEaXNjb3Zlcnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsLCZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+UmlnaHQuIFNvIHdoYXQgbXkgY29uZGl0aW9uYWwgYXBwcm92YWxzICgxMSBjb25kaXRp
b25zIGluIHRvdGFsKSBzYWlkIHdhcyB0byBkcm9wIHRoZSB3b3JkICZxdW90O2Rpc2NvdmVyeSZx
dW90OyBmcm9tIGV2ZXJ5d2hlcmUuIFRoaXMgaXMgbm90IGEgZGlzY292ZXJ5IHNwZWMuIFRoaXMg
aXMgYSBjb25maWd1cmF0aW9uIGxvb2t1cCBzcGVjIGFzIHlvdSBjb3JyZWN0bHkgcG9pbnRzIG91
dC4gU28sIEkgYW0gd2l0aCB5b3UgaGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+QWxzbywgbXkgMm5kIGNvbmRpdGlpb24gaXMgZXNzZW50aWFsbHkgc2F5aW5nIHRvIGRyb3Ag
c2VjdGlvbiAzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgdGhpbmcgdGhh
dCBJIG92ZXJsb29rZWQgYW5kIGFtIHdpdGggeW91IGlzIHRoYXQgd2UgbmVlZCB0byBiZSBhYmxl
IHRvIGV4cHJlc3MgdGhlIEFTLVJTIHJlbGF0aW9uc2hpcHMuIEkgaGF2ZSBiZWVuIHByZWFjaGlu
ZyB0aGlzIGluIHRoZSBvdGhlciB0aHJlYWQgZm9yIHNvIG1hbnkgdGltZXMgYXMgeW91IGtub3cg
c28gSSB0aG91Z2h0IEkgcG9pbnRlZCBpdCBvdXQsIGJ1dCBtaXNzZWQgYXBwYXJlbnRseQ0KIGlu
IG15IHByZXZpb3VzIGNvbW1lbnQuIFNvLCBJIHdvdWxkIGFkZCBteSAxMnRoIGNvbmRpdGlvbjom
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTIuIEEgd2F5IHRvIGV4cHJlc3MgYSBs
aXN0IG9mIHZhbGlkIFJTcyBmb3IgdGhpcyBBUyBuZWVkcyB0byBiZSBhZGRlZCB0byBzZWN0aW9u
IDIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTAz
LTExIDI6MDkgR01UJiM0MzswOTowMCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0
bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7OjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3Ryb25n
bHkgb3Bwb3NlLiAyIG1ham9yIGlzc3Vlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGhpcyBpcyBub3Qgc2VydmljZSBkaXNjb3ZlcnkgdGhpcyBpcyBjb25maWd1cmF0aW9uIGxv
b2t1cC4gVGhlIGNsaWVudCBtdXN0IGhhdmUgYWxyZWFkeSBkaXNjb3ZlcmVkIHRoZSBvYXV0aCBp
c3N1ZXIgdXJpIGFuZCB0aGUgcmVzb3VyY2UgdXJpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGUgb2JqZWN0aXZlIHdhcyB0byBwcm92aWRlIGEgbWV0aG9kIHRvIGVuc3VyZSB0
aGUgY2xpZW50IGhhcyBhIHZhbGlkIHNldCBvZiBlbmRwb2ludHMgdG8gcHJldmVudCBtaXRtIG9m
IGVuZHBvaW50cyBsaWtlIHRoZSB0b2tlbiBlbmRwb2ludCB0byB0aGUgcmVzb3VyY2Ugc2VydmVy
LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgZG9lcyBub3QgYWRk
cmVzcyB0aGUgaXNzdWUgb2YgYSBjbGllbnQgYmVpbmcgZ2l2ZW4gYSBiYWQgZW5kcG9pbnQgZm9y
IGFuIHJzLiBXaGF0IHdlIGVuZCB1cCB3aXRoIGlzIGEgcHJvbWlzY3VvdXMgYXV0aHogc2Vydmlj
ZSBnaXZpbmcgb3V0IHRva2VucyB0byBhbiB1bndpdHRpbmcgY2xpZW50LiZuYnNwOzxzcGFuIHN0
eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWFyIDEwLCAyMDE2LCBh
dCAwODowNiwgVmxhZGltaXIgRHpodXZpbm92ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJA
Y29ubmVjdDJpZC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij4mIzQzOzEgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlc2U8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTAvMDMvMTYg
MTc6MzUsIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHByZT4mIzQzOzE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5PbiBUaHUsIE1hciAxMCwgMjAxNiBhdCA2OjA0IEFNLCBSb2xhbmQgSGVk
YmVyZyA8YSBocmVmPSJtYWlsdG86cm9sYW5kLmhlZGJlcmdAdW11LnNlIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Jmx0O3JvbGFuZC5oZWRiZXJnQHVtdS5zZSZn
dDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPndyb3RlOjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SSBzdXBwb3J0IHRoaXMg
ZG9jdW1lbnQgYmVpbmcgbW92ZWQgZm9yd2FyZCB3aXRoIHRoZXNlIHR3byBjaGFuZ2VzOjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gY2hhbmdl
IG5hbWUgdG8g4oCcT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeSBNZXRh
ZGF0YeKAnSBhczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb3Bvc2VkIGJ5IEJyaWFuIGFuZDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gdXNlIHRoZSBVUkkgcGF0aCBzdWZmaXgg4oCZb2F1dGgt
YXV0aG9yaXphdGlvbi1zZXJ2ZXLigJkgaW5zdGVhZCBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PuKAmW9wZW5pZC1jb25maWd1cmF0aW9u4oCZIGFzIHByb3Bvc2VkIGJ5IEp1c3Rpbi48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjE4IGZlYiAy
MDE2IGtsLiAxNDo0MCBza3JldiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRv
Omhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9zcGFuPjwvYT48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT46PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286
cD48L3ByZT4NCjxwcmU+SGkgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgaXMgYSBMYXN0IENhbGwgZm9yIGNvbW1lbnRzIG9uIHRo
ZSZuYnNwOyBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjxwcmU+c3BlY2lmaWNhdGlvbjo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxhIGhyZWY9
Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz
JTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zl
cnktMDEmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFl
NmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmYW1wO3NkYXRhPXczJTJiaWlhV29uODFMSkNVJTJiMm1DUFJtQSUyYnJFQ0JIZ3F5
UnIwT2dxaVdTSFUlM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zlcnkt
MDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlNpbmNlIHRoaXMgZG9jdW1lbnQgd2FzIG9ubHkgYWRvcHRlZCByZWNlbnRseSB3
ZSBhcmUgcnVubmluZyB0aGlzIGxhc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jYWxsIGZvciAq
KjMgd2Vla3MqKi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5QbGVhc2UgaGF2ZSB5b3VyIGNvbW1lbnRzIGluIG5vIGxhdGVyIHRoYW4gTWFyY2gg
MTB0aC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5DaWFvPG86cD48L286cD48L3ByZT4NCjxwcmU+SGFubmVzICZhbXA7IERlcmVrPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg
aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9
aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZh
bXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0
OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj
MSZhbXA7c2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjlt
NVdnQTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48
L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+4oCUIFJvbGFuZDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPuKAnUV2ZXJ5Ym9keSBzaG91
bGQgYmUgcXVpZXQgbmVhciBhIGxpdHRsZSBzdHJlYW0gYW5kIGxpc3Rlbi4mcXVvdDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mZ3Q7RnJvbSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KA
mSBieSBSdXRoIEtyYXVzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+
T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy
ZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1w
O2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDky
ZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm
YW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVX
Z0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9
Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9h
dXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZi
ZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi
NDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUy
YnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48
bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3Lmll
dGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3Rv
bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIl
N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXROQ2lrbVhE
QkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZCIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFy
PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNo
YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl
bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZuYXQuc2FraW11
cmEub3JnJTJmJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzEx
NmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJmFtcDtzZGF0YT02RlZtZE43YWQwWXpvWUtTTkYlMmZETyUyZmZHMkVGMWhh
ajVhT0hpTWlkNlVNSSUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvc3Bhbj48L2E+PGJyPg0KQF9uYXRfZW48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu
b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v
dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxp
c3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29t
JTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFh
YjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWJLc0VWQlVYYzUyOHlhQU1MbXljWGNMMzMlMmJG
SkNRcm5xOWFzeFJvNUhlOCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9
aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZh
bXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0
NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj
MSZhbXA7c2RhdGE9YktzRVZCVVhjNTI4eWFBTUxteWNYY0wzMyUyYkZKQ1FybnE5YXN4Um81SGU4
JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_BN3PR0301MB1234635AE77883D05EB4D82BA6B50BN3PR0301MB1234_--


From nobody Fri Mar 11 15:59:21 2016
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 CD7C812DDB7 for ; Fri, 11 Mar 2016 15:59:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.411
X-Spam-Level: 
X-Spam-Status: No, score=0.411 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no 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 IhV8uCkpE9s9 for ; Fri, 11 Mar 2016 15:59:17 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 8B55912DDB0 for ; Fri, 11 Mar 2016 15:59:17 -0800 (PST)
Received: by mail-ig0-x236.google.com with SMTP id av4so24419699igc.1 for ; Fri, 11 Mar 2016 15:59:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YkZ6m6EtHAJAyL4206eXcwGIqd6eOz7ncyd+W3quEhU=; b=RKHpwh27PYXBOPcf0N4h/6LKhESEcJaMWPkmH2JQ93Cjia9eAaLvoNSef71joEufzM LuVW/g7heR+8sXyWY4emDTvNEvA6Grgsr5eXfReZQ/hmnOyAhVbauncMXSN6Uke3WN7+ v79rL3NmpdrmsXuEzFg0q2KZ8b9cpm4kaFjss=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YkZ6m6EtHAJAyL4206eXcwGIqd6eOz7ncyd+W3quEhU=; b=catLYSuLwr0Zz+TuDSEM4qanMh6dy3qR16V2Pk8BvKYU7mFiu06u4njBk98Hl4JUVz W5/itnE6gyn9G1p89cKDSf+U8FxsrkGGJnChd5/+CNJoROZ8oDS+wo8YsB7MyTdZ3NV2 9ZqqAERNTqmgSI4npJpHjPRor/2UTll0RGASk6OmESohMWWQtk2Alfo0T1ImSsyEweIz OtSn9rPvv7uLtRNs7JN/aHuDBhopLP70IVV1IrGXc3S701YxIyH/LQRq8R4uHNRo/QI9 OZyf2jbrT7GjUCZKboMeCcWcvy6Ja76mMeTb+OWaB1EkdbkaGeqJ7JxYixK13Uo26IWG ENxA==
X-Gm-Message-State: AD7BkJIc70yEv8jXsrpIJC8xwdR2JwPWy0CZ2O1PVaSbfHls6DW6SSgX1u1NzQE5u3KXnOBxdF4kjueSgc9hFJ/X
X-Received: by 10.50.117.103 with SMTP id kd7mr6733351igb.57.1457740756775; Fri, 11 Mar 2016 15:59:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 11 Mar 2016 15:58:47 -0800 (PST)
In-Reply-To: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>  
From: Brian Campbell 
Date: Fri, 11 Mar 2016 16:58:47 -0700
Message-ID: 
To: Anthony Nadalin 
Content-Type: multipart/alternative; boundary=089e013a084cfb968f052dceb7eb
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 23:59:21 -0000

--089e013a084cfb968f052dceb7eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That *is* the scope of the current document, which a majority of folks have
agreed with. I was reiterating that the name of the document should reflect
its content, something else that has been widely agreed with.

On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin 
wrote:

> Disagree, what purpose is this activity solving then, it was being pushed
> as what was need to solve the Mix-up, but that is not true. So now you ar=
e
> suggesting a change in scope and not dealing with discovery.
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, March 11, 2016 3:11 PM
> *To:* John Bradley 
>
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> I tend to agree with John that addressing the concerns Phil raises should
> be part of (extension to) the core protocol.  And that those kinds of
> concerns don't manifest in the way OAuth is typically deployed now.
>
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata"
> should keep it's scope to the publishing of authorization server metadata=
.
> The act of doing discovery is beyond its scope and so is trying to preven=
t
> a client from presenting a token to someplace it shouldn't.
>
>
>
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley  wrote:
>
> Inline
>
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
> wrote:
>
>
>
> John
>
>
>
> In many case all the AS has to check is the domain name component to chec=
k
> for mitm.
>
>
>
> POP and the other solns are dramatically more complex than a simple check=
.
>
>
>
> I was proposing ding that check at the authorization endpoint or token
> endpoint as part of AT issuance.
>
>
>
> It is up to the AS how much of the path to validate and or put in the aud
> or dst.
>
>
>
>
>
>
>
> I see it as part of the discovery(bad name aside) problem because we
> discussed that if a client finds app.example.com
> 
> how do we ensure it gets a complete set of oauth endpoints as a valid set
> of endpoints--that a hacker has not inserted one of their own endpoints.
> The most important endpoint to get right is ensuring the resource server
> (and optionally the path) is the correct one. We can't really define
> resource discovery but we can validate it to some degree.
>
>
>
> I think it is part of core protocol security and should/must not require
> discovery.
>
>
>
> What is app.example.com
> 
> ?
>
>
>
> If it is the resource then the client would be preconfigured for it=E2=80=
=99s AS
> out of band or optionally would do discovery on the issuer uri that you
> admit needs to be configured out of band some way (note discovery is
> optional)
>
>
>
> In the AS meta-data draft it would do a get on a well known file that
> would have configuration for the AS, but not the RS, though some API may
> optionally list a API endpoint like connect has.
>
>
>
> The client then makes a authorization request (after registering out of
> band or dynamically).
>
> As part of the authorization request for implicit it could provide the
> aud/dst that it wants the token for.
>
> If that is not sent then the aud/dst are implicit in the scopes.
>
>
>
> The client gets back a AT with a list of scopes granted, aud/dst allowed
> and time to live for the token (one extra thing returned)
>
>
>
> This doesn=E2=80=99t require any discovery (yes there is a optional AS me=
ta-data
> discovery but not required)
>
>
>
> I prefer to fix the RS man in the middle issue as part of the protocol an=
d
> not part of discovery that should remain optional.
>
>
>
> I honestly don=E2=80=99t quite know how the client learns about this bad =
RS and
> starts talking to it, so this may be a solution to a problem that doesn=
=E2=80=99t
> yet exist.   The one place this is posable is if the registration for the
> client is compromised.  However we are discussing other mitigations for
> that that also explicitly do not require discovery.
>
>
>
> John B.
>
>
>
>
>
> I am not stuck on webfinger or well-known. Because this is config maybe i=
t
> should be an oauth endpoint.
>
> Phil
>
>
> On Mar 11, 2016, at 06:51, John Bradley  wrote:
>
> I think Phil is proposing something different.   Should the client send a
> token from this AS to that RS.
>
>
>
> His goal is to prevent man in the middle attacks where a bad RS gets a AT
> that is audianced to/accepted by another RS.
>
>
>
> That is separate from the question of if a RS accepts tokens from a good
> AS.   A bad AS would always say yes.
>
>
>
> We need to be careful of what if anything the RS provides to the client a=
s
> meta-data without validation.
>
>
>
> Currently the client can provide a list of scopes required to get access.
>   I personally feel it would be useful to also include in the
> unauthenticated error response an indication of what API the resource
> supports.  Say =E2=80=9Cscim2=E2=80=9D as an example.   I don=E2=80=99t t=
hink adding that is
> however a high priority as most if all clients know what API they expect.
> It might be useful if at some point in the future if a client were to be
> given a RS URI it could check to see if it is a protocol that it supports
> before bothering with OAuth.    I expect that a lot of people will want
> that left to the API definition.   I think we can talk about it but rate
> this low priority.
>
>
>
> I agree that the RS giving out a list of AS that it trusts is a generally
> bad idea.  I hope that is not on the table.
>
>
>
> I don=E2=80=99t think that preventing a client from sending a token to th=
e wrong
> RS is part of a AS meta-data discovery problem.
>
>
>
> I do however think that it is important.
>
>
>
> We have been discussing this as a separate problem to AS meta-data
> discovery where the endpoints of the AS and it=E2=80=99s configuration ar=
e
> discovery.   Sorry for perhaps stating the obvious, but the RS is
> explicitly not part of the AS in OAuth 2.   Starting in WAP that was a co=
re
> principal.
>
>
>
> So we have a number of options to address the RS token leakage via MiTM
> attacks.
>
>
>
> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS
> or Token binding they cannot be replayed.  Signed messages where the
> signing covers the RS Host and path components,  also would work.
>
>
>
> 2) Have the AS audience restrict the resources the AT is good at. (AT
> should be doing that now)
>
> In the token response include the list of audience/s the token is
> presentable at.  The client would throw an error if the RS it intends to
> send the token to is not on the list.   The RS the token is good at might
> change based on scopes, client_id and resource owner.   This is the place
> where all of that comes together.   In some cases the RS and AS might not
> have a pre-established relationship.   The client should send the RS base
> URI to the AS as part of the request.  The AS can use that to audience
> restrict the AT and issue the AT or refuse to issue the AT based on polic=
y.
>
> It can also use the audience in the request to down audience the AT if th=
e
> default is to have multiple audiences.    We may want to use a term other
> than audience for this like resource or destination.  It is a audience bu=
t
> that term might confuse people with AT.
>
>
>
> We did talk about breaking audience out of POP key distribution, and Bria=
n
> Campbell did a draft
> https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt
> .
>
>
>
>
> To do this we could take dst4jwt and add another spec that adds a new dst
> parameter to the token and authorization endpoints requests That would be=
 a
> space separated list of dst values.  and in the response from the token
> endpoint would be a JSON array of dst values.
>
>
>
> 3) Have the AS always return all the list of all RS the token can be used
> at (basically Nat's link relationship proposal).  It needs a way to handl=
e
>
> down destinationing of AT and to allow for un-configured RS that it might
> issue a token for.  So could be combined with dst from 2.  Basically
> returning the acceptable destinations as link headers vs JS in the respon=
se
> is mostly a style issue that other people can bike shed.
>
>
>
>
>
> 4) Trying to add all the RS to the AS discovery document.  This seems
> impractical as there would be multiple protocols and doesn=E2=80=99t addr=
ess
> un-configured RS.
>
>
>
> 5) Some new AS endpoint that the client could introspect the RS URI and
> get back metadata about if the client should send tokens there.
>
>     A couple of problems with this.  The first is that it would not
> support un-configured RS unless you add dst to the token and authorizatio=
n
> endpoints.   The other is that the introspection endpoint doesn=E2=80=99t=
 have the
> context of the RO and client_id unless you also pass the code/RT and
> client_id, and probably client credentials.    Basically this is trying t=
o
> introspect the AT to determine the audiance/dst.   By the time you build =
a
> new introspection endpoint securely it is going to look like the token
> endpoint with a bit more meta data about the token beyond expiry and scop=
es.
>
>
>
>
>
> I think we should go a head with the renamed "OAuth 2.0 Authorization
> Server Discovery Metadata=E2=80=9D
>
> I am also fine with making the default document 'openid-configuration=E2=
=80=99  as
> long as we allow for protocol specific variation so that SCIM2 could defi=
ne
> a file name.    If people want we could do a API  to file name registry s=
o
> that protocol specific ones can be defined.
>
>
>
> We are all-ready working on option 1 to secure AT, we need a spec like I
> propose in 2 for bearer tokens.  We can add one request parameter and a b=
it
> more token meta-data to the token response and that takes care of the
> problem.   Honestly we probably should have separated scope and destinati=
on
> in the first place and returned both dst and scope in the response all
> along, so this is update that is consistent with the eisting architecture
> of OAuth 2.
>
>
>
> Lets keep the two issues separate.
>
>
>
> John B.
>
>
>
>
>
>
>
>
>
> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin 
> wrote:
>
>
>
> The relationship between AS and RS need to be scoped to =E2=80=9Cdoes thi=
s RS
> accept tokens from this AS=E2=80=9D as a list is too much information tha=
t could be
> used in the wrong way
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O=
n
> Behalf Of *Nat Sakimura
> *Sent:* Thursday, March 10, 2016 6:25 PM
> *To:* Phil Hunt (IDM) 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> Phil,
>
>
>
> Right. So what my conditional approvals (11 conditions in total) said was
> to drop the word "discovery" from everywhere. This is not a discovery spe=
c.
> This is a configuration lookup spec as you correctly points out. So, I am
> with you here.
>
>
>
> Also, my 2nd conditiion is essentially saying to drop section 3.
>
>
>
> One thing that I overlooked and am with you is that we need to be able to
> express the AS-RS relationships. I have been preaching this in the other
> thread for so many times as you know so I thought I pointed it out, but
> missed apparently in my previous comment. So, I would add my 12th
> condition:
>
>
>
> 12. A way to express a list of valid RSs for this AS needs to be added to
> section 2.
>
>
>
> Best,
>
>
>
> Nat
>
>
>
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>
> I strongly oppose. 2 major issues.
>
>
>
> This is not service discovery this is configuration lookup. The client
> must have already discovered the oauth issuer uri and the resource uri.
>
>
>
> The objective was to provide a method to ensure the client has a valid se=
t
> of endpoints to prevent mitm of endpoints like the token endpoint to the
> resource server.
>
>
>
> The draft does not address the issue of a client being given a bad
> endpoint for an rs. What we end up with is a promiscuous authz service
> giving out tokens to an unwitting client.
>
> Phil
>
>
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
> wrote:
>
> +1 to move forward with these
>
> On 10/03/16 17:35, Brian Campbell wrote:
>
> +1
>
>
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg  <=
roland.hedberg@umu.se>
>
> wrote:
>
>
>
> I support this document being moved forward with these two changes:
>
>
>
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
>
> proposed by Brian and
>
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
>
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>
>
>
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
> :
>
>
>
> Hi all,
>
>
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery
>
> specification:
>
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 
>
>
>
> Since this document was only adopted recently we are running this last
>
> call for **3 weeks**.
>
>
>
> Please have your comments in no later than March 10th.
>
>
>
> Ciao
>
> Hannes & Derek
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
>
> =E2=80=94 Roland
>
>
>
> =E2=80=9DEverybody should be quiet near a little stream and listen."
>
> >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>
>
>
>
>
> _______________________________________________
>
> 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 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
>
>
>
> --
>
> Nat Sakimura (=3Dnat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> 
> @_nat_en
>
> _______________________________________________
> 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
> 
>
>
>

--089e013a084cfb968f052dceb7eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    That *is* the scope of the current document, which a major=
ity of folks have agreed with. I was reiterating that the name of the docum=
ent should reflect its content, something else that has been widely agreed =
with.=C2=A0 

    On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin <tonynad@microsoft.c=
om> wrote:
    






    

    

    Disagree, what purpose is this activity solving the=
n, it was being pushed as what was need to solve the Mix-up, but that is no=
t true. So now you are suggesting a change in
 scope and not dealing with discovery.
    

    =C2=
=A0
    

    From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell
    
Sent: Friday, March 11, 2016 3:11 PM
    
To: John Bradley <ve7jtb@ve7jtb.com>

    
Cc: oauth <oa=
uth@ietf.org>
    
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discove=
ry
    

    =C2=A0
    

    

    I tend to agree with =
John that addressing the concerns Phil raises should be part of (extension =
to) the core protocol.=C2=A0 And that those kinds of concerns don't man=
ifest in the way OAuth is typically deployed
 now. 
    

    
The hopefully soon to be named "OAuth 2.0 Authorization Server Metadat=
a" should keep it's scope to the publishing of authorization serve=
r metadata. The act of doing discovery is beyond its scope and so is trying=
 to prevent a client from presenting a token to
 someplace it shouldn't. 
    

    

    

    

    

    =C2=A0
    

    

    On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7jtb@ve7jtb.com&=
gt; wrote:
    

    

    

    Inline
    

    

    

    

    On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) <phil.hunt@oracle.co=
m> wrote:
    

    

    =C2=A0
    

    

    

    

    John
    

    

    

    =C2=A0
    

    

    

    In many case all the AS has to check is the domain n=
ame component to check for mitm.=C2=A0
    

    

    

    =C2=A0
    

    

    

    POP and the other solns are dramatically more comple=
x than a simple check.=C2=A0
    

    

    

    

    

    

    =C2=A0
    

    

    I was proposing ding that check at the authorization=
 endpoint or token endpoint as part of AT issuance.=C2=A0
    

    

    

    =C2=A0
    

    

    

    It is up to the AS how much of the path to validate =
and or put in the aud or dst.=C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

    

    

    

    =C2=A0
    

    

    

    I see it as part of the discovery(bad name aside) pr=
oblem because we discussed that if a client finds

app.example.com how do we ensure it gets a complete set of oauth endpoi=
nts as a valid set of endpoints--that a hacker has not inserted one of thei=
r own endpoints. The most important endpoint to get right is ensuring the r=
esource server (and optionally the
 path) is the correct one. We can't really define resource discovery bu=
t we can validate it to some degree.=C2=A0
    

    

    

    =C2=A0
    

    

    

    

    

    

    I think it is part of core protocol security and sho=
uld/must not require discovery.=C2=A0
    

    

    

    =C2=A0
    

    

    

    What is 
app.example.com ?=C2=A0
    

    

    

    =C2=A0
    

    

    

    If it is the resource then the client would be preco=
nfigured for it=E2=80=99s AS out of band or optionally would do discovery o=
n the issuer uri that you admit needs to be configured out of band some way=
 (note discovery is optional)
    

    

    

    =C2=A0
    

    

    

    In the AS meta-data draft it would do a get on a wel=
l known file that would have configuration for the AS, but not the RS, thou=
gh some API may optionally list a API endpoint like connect has. =C2=A0<=
/u>
    

    

    

    =C2=A0
    

    

    

    The client then makes a authorization request (after=
 registering out of band or dynamically). =C2=A0
    

    

    

    As part of the authorization request for implicit it=
 could provide the aud/dst that it wants the token for.
    

    

    

    If that is not sent then the aud/dst are implicit in=
 the scopes.
    

    

    

    =C2=A0
    

    

    

    The client gets back a AT with a list of scopes gran=
ted, aud/dst allowed and time to live for the token (one extra thing return=
ed)
    

    

    

    =C2=A0
    

    

    

    This doesn=E2=80=99t require any discovery (yes ther=
e is a optional AS meta-data discovery but not required)
    

    

    

    =C2=A0
    

    

    

    I prefer to fix the RS man in the middle issue as pa=
rt of the protocol and not part of discovery that should remain optional.
    

    

    

    =C2=A0
    

    

    

    I honestly don=E2=80=99t quite know how the client l=
earns about this bad RS and starts talking to it, so this may be a solution=
 to a problem that doesn=E2=80=99t yet exist. =C2=A0 The one place this is =
posable is if the registration for the client is compromised.=C2=A0
 However we are discussing other mitigations for that that also explicitly =
do not require discovery.
    

    

    

    =C2=A0
    

    

    

    John B.
    

    

    

    

    

    =C2=A0
    

    


    

    

    

    

    

    

    

    I am not stuck on webfinger or well-known. Because t=
his is config maybe it should be an oauth endpoint.=C2=A0
    

    
Phil
    

    

    


    
On Mar 11, 2016, at 06:51, John Bradley <ve7jtb@ve7jtb.com> wrote:
    

    

    

    

    I think Phil is proposing something different. =C2=
=A0 Should the client send a token from this AS to that RS. =C2=A0
    

    

    =C2=A0
    

    

    

    His goal is to prevent man in the middle attacks whe=
re a bad RS gets a AT that is audianced to/accepted by another RS.
    

    

    

    =C2=A0
    

    

    

    That is separate from the question of if a RS accept=
s tokens from a good AS. =C2=A0 A bad AS would always say yes.
    

    

    

    =C2=A0
    

    

    

    We need to be careful of what if anything the RS pro=
vides to the client as meta-data without validation.
    

    

    

    =C2=A0
    

    

    

    Currently the client can provide a list of scopes re=
quired to get access. =C2=A0 I personally feel it would be useful to also i=
nclude in the unauthenticated error response an indication of what API the =
resource supports.=C2=A0 Say =E2=80=9Cscim2=E2=80=9D as an example.
 =C2=A0 I don=E2=80=99t think adding that is however a high priority as mos=
t if all clients know what API they expect. =C2=A0 It might be useful if at=
 some point in the future if a client were to be given a RS URI it could ch=
eck to see if it is a protocol that it supports before
 bothering with OAuth. =C2=A0 =C2=A0I expect that a lot of people will want=
 that left to the API definition. =C2=A0 I think we can talk about it but r=
ate this low priority.
    

    

    

    =C2=A0
    

    

    

    I agree that the RS giving out a list of AS that it =
trusts is a generally bad idea.=C2=A0 I hope that is not on the table.
    

    

    

    =C2=A0
    

    

    

    I don=E2=80=99t think that preventing a client from =
sending a token to the wrong RS is part of a AS meta-data discovery problem=
.
    

    

    

    =C2=A0
    

    

    

    I do however think that it is important.
    

    

    

    =C2=A0
    

    

    

    We have been discussing this as a separate problem t=
o AS meta-data discovery where the endpoints of the AS and it=E2=80=99s con=
figuration are discovery. =C2=A0 Sorry for perhaps stating the obvious, but=
 the RS is explicitly not part of the AS in OAuth
 2. =C2=A0 Starting in WAP that was a core principal.
    

    

    

    =C2=A0
    

    

    

    So we have a number of options to address the RS tok=
en leakage via MiTM attacks.
    

    

    

    =C2=A0
    

    

    

    1) PoP bound tokens.=C2=A0 If they are bound to the =
TLS channel by mutual TLS or Token binding they cannot be replayed.=C2=A0 S=
igned messages where the signing covers the RS Host and path components, =
=C2=A0also would work.
    

    

    

    =C2=A0
    

    

    

    2) Have the AS audience restrict the resources the A=
T is good at. (AT should be doing that now)=C2=A0
    

    

    

    In the token response include the list of audience/s=
 the token is presentable at.=C2=A0 The client would throw an error if the =
RS it intends to send the token to is not on the list. =C2=A0 The RS the to=
ken is good at might change based on scopes,
 client_id and resource owner. =C2=A0 This is the place where all of that c=
omes together. =C2=A0 In some cases the RS and AS might not have a pre-esta=
blished relationship. =C2=A0 The client should send the RS base URI to the =
AS as part of the request.=C2=A0 The AS can use that
 to audience restrict the AT and issue the AT or refuse to issue the AT bas=
ed on policy.
    

    

    

    It can also use the audience in the request to down =
audience the AT if the default is to have multiple audiences. =C2=A0 =C2=A0=
We may want to use a term other than audience for this like resource or des=
tination.=C2=A0 It is a audience but that term might
 confuse people with AT.
    

    

    

    =C2=A0
    

    

    

    We did talk about breaking audience out of POP key d=
istribution, and Brian Campbell did a draft=C2=A0https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt.
 =C2=A0=C2=A0
    

    

    

    =C2=A0
    

    

    

    To do this we could take dst4jwt and add another spe=
c that adds a new dst parameter to the token and authorization endpoints re=
quests That would be a space separated list of dst values. =C2=A0and in the=
 response from the token endpoint would
 be a JSON array of dst values.
    

    

    

    =C2=A0
    

    

    

    3) Have the AS always return all the list of all RS =
the token can be used at (basically Nat's link relationship proposal).=
=C2=A0 It needs a way to handle=C2=A0
    

    

    

    down destinationing of AT and to allow for un-config=
ured RS that it might issue a token for.=C2=A0 So could be combined with ds=
t from 2.=C2=A0 Basically returning the acceptable destinations as link hea=
ders vs JS in the response is mostly a style
 issue that other people can bike shed.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    4) Trying to add all the RS to the AS discovery docu=
ment.=C2=A0 This seems impractical as there would be multiple protocols and=
 doesn=E2=80=99t address un-configured RS.
    

    

    

    =C2=A0
    

    

    

    5) Some new AS endpoint that the client could intros=
pect the RS URI and get back metadata about if the client should send token=
s there.
    

    

    

    =C2=A0 =C2=A0 A couple of problems with this.=C2=A0 =
The first is that it would not support un-configured RS unless you add dst =
to the token and authorization endpoints. =C2=A0 The other is that the intr=
ospection endpoint doesn=E2=80=99t have the context of the RO
 and client_id unless you also pass the code/RT and client_id, and probably=
 client credentials. =C2=A0 =C2=A0Basically this is trying to introspect th=
e AT to determine the audiance/dst. =C2=A0 By the time you build a new intr=
ospection endpoint securely it is going to look
 like the token endpoint with a bit more meta data about the token beyond e=
xpiry and scopes.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    I think we should go a head with the renamed "O=
Auth 2.0 Authorization Server Discovery Metadata=E2=80=9D=C2=A0
    

    

    

    I am also fine with making the default document '=
;openid-configuration=E2=80=99 =C2=A0as long as we allow for protocol speci=
fic variation so that SCIM2 could define a file name. =C2=A0 =C2=A0If peopl=
e want we could do a API =C2=A0to file name registry so that protocol
 specific ones can be defined.
    

    

    

    =C2=A0
    

    

    

    We are all-ready working on option 1 to secure AT, w=
e need a spec like I propose in 2 for bearer tokens.=C2=A0 We can add one r=
equest parameter and a bit more token meta-data to the token response and t=
hat takes care of the problem. =C2=A0 Honestly
 we probably should have separated scope and destination in the first place=
 and returned both dst and scope in the response all along, so this is upda=
te that is consistent with the eisting architecture of OAuth 2.
    

    

    

    =C2=A0
    

    

    

    Lets keep the two issues separate.
    

    

    

    =C2=A0
    

    

    

    John B.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

    

    

    On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tonynad@microsoft.=
com> wrote:
    

    

    =C2=A0
    

    

    

    

    The relationship between AS and RS need to be scope=
d to =E2=80=9Cdoes this RS accept tokens from this AS=E2=80=9D as a list is=
 too much information that could be used in the wrong way<=
/u>
    

    


    

    From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org=
]=C2=A0On
 Behalf Of=C2=A0Nat Sakimura
    
Sent:=C2=A0Thursday, March 10, 2016 6:25 PM
    
To:=C2=A0Phil Hunt (IDM) <phil.hunt@oracle.com>
    
Cc:=C2=A0oauth <oauth@ietf.org>
    
Subject:=C2=A0Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Di=
scovery
    

    

    

    =C2=A0
    

    

    

    

    Phil,=C2=A0
    

    

    

    

    =C2=A0
    

    

    

    

    

    Right. So what my conditional approvals (11 conditio=
ns in total) said was to drop the word "discovery" from everywher=
e. This is not a discovery spec. This is a configuration lookup spec as you=
 correctly points out. So, I am with you here.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    Also, my 2nd conditiion is essentially saying to dro=
p section 3.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    One thing that I overlooked and am with you is that =
we need to be able to express the AS-RS relationships. I have been preachin=
g this in the other thread for so many times as you know so I thought I poi=
nted it out, but missed apparently
 in my previous comment. So, I would add my 12th condition:=C2=A0=

    

    

    

    

    

    =C2=A0
    

    

    

    

    

    12. A way to express a list of valid RSs for this AS=
 needs to be added to section 2.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    Best,=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    Nat
    

    

    

    

    

    

    =C2=A0
    

    

    

    

    2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
    

    

    

    

    

    

    I strongly oppose. 2 major issues.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    This is not service discovery this is configuration =
lookup. The client must have already discovered the oauth issuer uri and th=
e resource uri.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    The objective was to provide a method to ensure the =
client has a valid set of endpoints to prevent mitm of endpoints like the t=
oken endpoint to the resource server.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    The draft does not address the issue of a client bei=
ng given a bad endpoint for an rs. What we end up with is a promiscuous aut=
hz service giving out tokens to an unwitting client.=C2=A0
    

    
Phil
    

    

    

    

    

    


    
On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@c=
onnect2id.com> wrote:
    

    

    

    

    +1 to move forward wi=
th these
    

    

    

    On 10/03/16 17:35, Brian Campbell wrote:
    

    

    

    

    +1
    

    =C2=A0
    

    On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <rolan=
d.hedberg@umu.se>
    

    wrote:
    

    =C2=A0
    

    

    I support this document being moved forward with these two changes:=

    

    =C2=A0
    

    - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Met=
adata=E2=80=9D as
    

    proposed by Brian and
    

    - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99=
 instead of
    

    =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
    

    =C2=A0
    

    

    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <han=
nes.tschofenig@gmx.net
    

    :
    

    =C2=A0
    

    Hi all,
    

    =C2=A0
    

    This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery
    

    

    specification:
    

    

    https:=
//tools.ietf.org/html/draft-ietf-oauth-discovery-01
    

    =C2=A0
    

    Since this document was only adopted recently we are running this last=

    

    call for **3 weeks**.
    

    =C2=A0
    

    Please have your comments in no later than March 10th.

    =C2=A0
    

    Ciao
    

    Hannes & Derek
    

    =C2=A0
    

    _______________________________________________
    

    OAuth mailing list
    

    OAuth@ietf.org
    

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

    

    =E2=80=94 Roland
    

    =C2=A0
    

    =E2=80=9DEverybody should be quiet near a little stream and listen.&qu=
ot;
    

    >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
    

    =C2=A0
    

    =C2=A0
    

    _______________________________________________
    

    OAuth mailing list
    

    OAuth@ietf.org
    

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

    =C2=A0
    

    =C2=A0
    

    

    =C2=A0<=
/p>

    _______________________________________________
    

    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
    

    

    

    


    

    

    

    

    

    

    =C2=A0
    

    

    

    

    --=C2=A0
    

    

    

    

    Nat Sakimura (=3Dnat)
    

    

    

    

    Chairman, OpenID Foundation
    
http://nat.sakimura.org/
    
@_nat_en
    

    

    

    

    

    

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

    

    

    

    =C2=A0
    

    

    

    

    

    

    

    

    

    

    =C2=A0
    

    


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

    

    

    =C2=A0
    

    

    

    



    

--089e013a084cfb968f052dceb7eb--


From nobody Fri Mar 11 16:01:06 2016
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 EB5C112DD9B for ; Fri, 11 Mar 2016 16:01:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.11
X-Spam-Level: *
X-Spam-Status: No, score=1.11 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 3vP2Dhiqa9i0 for ; Fri, 11 Mar 2016 16:00:59 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A994D12DDB7 for ; Fri, 11 Mar 2016 16:00:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GVtrAXv6ZBf7EDqyDfN1OKW6RClg/PjSOVN2F2NE5LE=; b=bZLFgF3CROlvqd/hMBA0N1vi8jmt9wJuCZMYFWYKf25Q2/lPTDQ4+zlaOUkfiGJw7JjVN/LdW1eLaBdbSERzLI8YcKaRr0r5x46Ppnn78Z//yxk8mS0XbLO46T+Lz0+q6SCoVhIoA3Y9yoGTIDOIjyTPAW2QNWS72NBm2oXXMqA=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.427.16; Sat, 12 Mar 2016 00:00:32 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0427.020; Sat, 12 Mar 2016 00:00:32 +0000
From: Anthony Nadalin 
To: Brian Campbell 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH06DIAQfC9O0686lpsTuUfK59Sxh0AgAAqNQCAAAiJgIAAEaoAgACbQYCAAAsN0IAAxaEAgAAF5wCAAA9jAIAAdkGAgAACUgCAAArxgIAAAF7A
Date: Sat, 12 Mar 2016 00:00:32 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:8::9b]
x-ms-office365-filtering-correlation-id: 277831a4-d493-4a5f-7d35-08d34a09548a
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:U2xyoQadv66i0HzD37U8cRIaE4MFBTbd9qM3P/yGpSOtsIvmpK05DseOwlBaa8Ev95K3xIGzx7o5nKZ3+RArEhtcA2A6nK5vifP30QfrOB7Gk/DJqzA/pTCDM/ivGGp05caLEEoOwB3Z9qDFtXutLA==; 24:tx3hqkQksdvOhlPkr+Bo7ZUvXzDoNnnaSlsFcNvUuGG2ZXHHGu5s1Fe6ooOTqSMwkrEsBid17hYZGqRg/12XnqPXXDslzG/Nwv8Pic8SpnU=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 0879599414
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(53754006)(24454002)(377454003)(377424004)(10400500002)(15975445007)(93886004)(92566002)(3660700001)(5005710100001)(3280700002)(1096002)(2950100001)(6116002)(2900100001)(586003)(790700001)(5003600100002)(11100500001)(102836003)(10290500002)(1220700001)(77096005)(19300405004)(4326007)(81166005)(50986999)(5002640100001)(110136002)(2906002)(189998001)(76176999)(19580395003)(5008740100001)(86362001)(19609705001)(19580405001)(19617315012)(8990500004)(5004730100002)(16236675004)(106116001)(99286002)(76576001)(19625215002)(122556002)(54356999)(33656002)(561944003)(74316001)(87936001)(3826002)(42262002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123426487F3BB78AE49346C2A6B60BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2016 00:00:32.0395 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 00:01:04 -0000

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

U29ycnkgYnV0IG5vdCB0cnVlLCB0aGlzIHN0YXJ0ZWQgb3V0IGFzIOKAnGRpc2NvdmVyeeKAnSBh
bmQgbm93IGl04oCZcyBub3QNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJl
bGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTEsIDIwMTYgMzo1OSBQ
TQ0KVG86IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0KQ2M6IEpvaG4g
QnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+OyBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAg
RGlzY292ZXJ5DQoNClRoYXQgKmlzKiB0aGUgc2NvcGUgb2YgdGhlIGN1cnJlbnQgZG9jdW1lbnQs
IHdoaWNoIGEgbWFqb3JpdHkgb2YgZm9sa3MgaGF2ZSBhZ3JlZWQgd2l0aC4gSSB3YXMgcmVpdGVy
YXRpbmcgdGhhdCB0aGUgbmFtZSBvZiB0aGUgZG9jdW1lbnQgc2hvdWxkIHJlZmxlY3QgaXRzIGNv
bnRlbnQsIHNvbWV0aGluZyBlbHNlIHRoYXQgaGFzIGJlZW4gd2lkZWx5IGFncmVlZCB3aXRoLg0K
DQpPbiBGcmksIE1hciAxMSwgMjAxNiBhdCA0OjI0IFBNLCBBbnRob255IE5hZGFsaW4gPHRvbnlu
YWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpE
aXNhZ3JlZSwgd2hhdCBwdXJwb3NlIGlzIHRoaXMgYWN0aXZpdHkgc29sdmluZyB0aGVuLCBpdCB3
YXMgYmVpbmcgcHVzaGVkIGFzIHdoYXQgd2FzIG5lZWQgdG8gc29sdmUgdGhlIE1peC11cCwgYnV0
IHRoYXQgaXMgbm90IHRydWUuIFNvIG5vdyB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBjaGFuZ2UgaW4g
c2NvcGUgYW5kIG5vdCBkZWFsaW5nIHdpdGggZGlzY292ZXJ5Lg0KDQpGcm9tOiBPQXV0aCBbbWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+
XSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IEZyaWRheSwgTWFyY2ggMTEsIDIw
MTYgMzoxMSBQTQ0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZl
N2p0YkB2ZTdqdGIuY29tPj4NCg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1
dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0
IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeQ0KDQpJIHRlbmQgdG8gYWdyZWUgd2l0aCBKb2hu
IHRoYXQgYWRkcmVzc2luZyB0aGUgY29uY2VybnMgUGhpbCByYWlzZXMgc2hvdWxkIGJlIHBhcnQg
b2YgKGV4dGVuc2lvbiB0bykgdGhlIGNvcmUgcHJvdG9jb2wuICBBbmQgdGhhdCB0aG9zZSBraW5k
cyBvZiBjb25jZXJucyBkb24ndCBtYW5pZmVzdCBpbiB0aGUgd2F5IE9BdXRoIGlzIHR5cGljYWxs
eSBkZXBsb3llZCBub3cuDQoNClRoZSBob3BlZnVsbHkgc29vbiB0byBiZSBuYW1lZCAiT0F1dGgg
Mi4wIEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIiBzaG91bGQga2VlcCBpdCdzIHNjb3Bl
IHRvIHRoZSBwdWJsaXNoaW5nIG9mIGF1dGhvcml6YXRpb24gc2VydmVyIG1ldGFkYXRhLiBUaGUg
YWN0IG9mIGRvaW5nIGRpc2NvdmVyeSBpcyBiZXlvbmQgaXRzIHNjb3BlIGFuZCBzbyBpcyB0cnlp
bmcgdG8gcHJldmVudCBhIGNsaWVudCBmcm9tIHByZXNlbnRpbmcgYSB0b2tlbiB0byBzb21lcGxh
Y2UgaXQgc2hvdWxkbid0Lg0KDQpPbiBGcmksIE1hciAxMSwgMjAxNiBhdCA5OjA4IEFNLCBKb2hu
IEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdy
b3RlOg0KSW5saW5lDQpPbiBNYXIgMTEsIDIwMTYsIGF0IDEyOjEzIFBNLCBQaGlsIEh1bnQgKElE
TSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdy
b3RlOg0KDQpKb2huDQoNCkluIG1hbnkgY2FzZSBhbGwgdGhlIEFTIGhhcyB0byBjaGVjayBpcyB0
aGUgZG9tYWluIG5hbWUgY29tcG9uZW50IHRvIGNoZWNrIGZvciBtaXRtLg0KDQpQT1AgYW5kIHRo
ZSBvdGhlciBzb2xucyBhcmUgZHJhbWF0aWNhbGx5IG1vcmUgY29tcGxleCB0aGFuIGEgc2ltcGxl
IGNoZWNrLg0KDQpJIHdhcyBwcm9wb3NpbmcgZGluZyB0aGF0IGNoZWNrIGF0IHRoZSBhdXRob3Jp
emF0aW9uIGVuZHBvaW50IG9yIHRva2VuIGVuZHBvaW50IGFzIHBhcnQgb2YgQVQgaXNzdWFuY2Uu
DQoNCkl0IGlzIHVwIHRvIHRoZSBBUyBob3cgbXVjaCBvZiB0aGUgcGF0aCB0byB2YWxpZGF0ZSBh
bmQgb3IgcHV0IGluIHRoZSBhdWQgb3IgZHN0Lg0KDQoNCg0KSSBzZWUgaXQgYXMgcGFydCBvZiB0
aGUgZGlzY292ZXJ5KGJhZCBuYW1lIGFzaWRlKSBwcm9ibGVtIGJlY2F1c2Ugd2UgZGlzY3Vzc2Vk
IHRoYXQgaWYgYSBjbGllbnQgZmluZHMgYXBwLmV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZl
bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZhcHAuZXhhbXBs
ZS5jb20lMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1
ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk
YjQ3JTdjMSZzZGF0YT1maVM4ZjYweXBpWGh5TTBxVlRlcWwlMmIlMmJPekgyd2JtRUNRRTdKNVR0
R1BRTSUzZD4gaG93IGRvIHdlIGVuc3VyZSBpdCBnZXRzIGEgY29tcGxldGUgc2V0IG9mIG9hdXRo
IGVuZHBvaW50cyBhcyBhIHZhbGlkIHNldCBvZiBlbmRwb2ludHMtLXRoYXQgYSBoYWNrZXIgaGFz
IG5vdCBpbnNlcnRlZCBvbmUgb2YgdGhlaXIgb3duIGVuZHBvaW50cy4gVGhlIG1vc3QgaW1wb3J0
YW50IGVuZHBvaW50IHRvIGdldCByaWdodCBpcyBlbnN1cmluZyB0aGUgcmVzb3VyY2Ugc2VydmVy
IChhbmQgb3B0aW9uYWxseSB0aGUgcGF0aCkgaXMgdGhlIGNvcnJlY3Qgb25lLiBXZSBjYW4ndCBy
ZWFsbHkgZGVmaW5lIHJlc291cmNlIGRpc2NvdmVyeSBidXQgd2UgY2FuIHZhbGlkYXRlIGl0IHRv
IHNvbWUgZGVncmVlLg0KDQpJIHRoaW5rIGl0IGlzIHBhcnQgb2YgY29yZSBwcm90b2NvbCBzZWN1
cml0eSBhbmQgc2hvdWxkL211c3Qgbm90IHJlcXVpcmUgZGlzY292ZXJ5Lg0KDQpXaGF0IGlzIGFw
cC5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwJTNhJTJmJTJmYXBwLmV4YW1wbGUuY29tJmRhdGE9MDElN2MwMSU3Y3Rvbnlu
YWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3
MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9akFzWlFlQ2hKJTJiUjFs
YnlCb1ZLd2hlSVlpM1BpV0xycSUyYnhETGJxVTZyeGslM2Q+ID8NCg0KSWYgaXQgaXMgdGhlIHJl
c291cmNlIHRoZW4gdGhlIGNsaWVudCB3b3VsZCBiZSBwcmVjb25maWd1cmVkIGZvciBpdOKAmXMg
QVMgb3V0IG9mIGJhbmQgb3Igb3B0aW9uYWxseSB3b3VsZCBkbyBkaXNjb3Zlcnkgb24gdGhlIGlz
c3VlciB1cmkgdGhhdCB5b3UgYWRtaXQgbmVlZHMgdG8gYmUgY29uZmlndXJlZCBvdXQgb2YgYmFu
ZCBzb21lIHdheSAobm90ZSBkaXNjb3ZlcnkgaXMgb3B0aW9uYWwpDQoNCkluIHRoZSBBUyBtZXRh
LWRhdGEgZHJhZnQgaXQgd291bGQgZG8gYSBnZXQgb24gYSB3ZWxsIGtub3duIGZpbGUgdGhhdCB3
b3VsZCBoYXZlIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBBUywgYnV0IG5vdCB0aGUgUlMsIHRob3Vn
aCBzb21lIEFQSSBtYXkgb3B0aW9uYWxseSBsaXN0IGEgQVBJIGVuZHBvaW50IGxpa2UgY29ubmVj
dCBoYXMuDQoNClRoZSBjbGllbnQgdGhlbiBtYWtlcyBhIGF1dGhvcml6YXRpb24gcmVxdWVzdCAo
YWZ0ZXIgcmVnaXN0ZXJpbmcgb3V0IG9mIGJhbmQgb3IgZHluYW1pY2FsbHkpLg0KQXMgcGFydCBv
ZiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZvciBpbXBsaWNpdCBpdCBjb3VsZCBwcm92aWRl
IHRoZSBhdWQvZHN0IHRoYXQgaXQgd2FudHMgdGhlIHRva2VuIGZvci4NCklmIHRoYXQgaXMgbm90
IHNlbnQgdGhlbiB0aGUgYXVkL2RzdCBhcmUgaW1wbGljaXQgaW4gdGhlIHNjb3Blcy4NCg0KVGhl
IGNsaWVudCBnZXRzIGJhY2sgYSBBVCB3aXRoIGEgbGlzdCBvZiBzY29wZXMgZ3JhbnRlZCwgYXVk
L2RzdCBhbGxvd2VkIGFuZCB0aW1lIHRvIGxpdmUgZm9yIHRoZSB0b2tlbiAob25lIGV4dHJhIHRo
aW5nIHJldHVybmVkKQ0KDQpUaGlzIGRvZXNu4oCZdCByZXF1aXJlIGFueSBkaXNjb3ZlcnkgKHll
cyB0aGVyZSBpcyBhIG9wdGlvbmFsIEFTIG1ldGEtZGF0YSBkaXNjb3ZlcnkgYnV0IG5vdCByZXF1
aXJlZCkNCg0KSSBwcmVmZXIgdG8gZml4IHRoZSBSUyBtYW4gaW4gdGhlIG1pZGRsZSBpc3N1ZSBh
cyBwYXJ0IG9mIHRoZSBwcm90b2NvbCBhbmQgbm90IHBhcnQgb2YgZGlzY292ZXJ5IHRoYXQgc2hv
dWxkIHJlbWFpbiBvcHRpb25hbC4NCg0KSSBob25lc3RseSBkb27igJl0IHF1aXRlIGtub3cgaG93
IHRoZSBjbGllbnQgbGVhcm5zIGFib3V0IHRoaXMgYmFkIFJTIGFuZCBzdGFydHMgdGFsa2luZyB0
byBpdCwgc28gdGhpcyBtYXkgYmUgYSBzb2x1dGlvbiB0byBhIHByb2JsZW0gdGhhdCBkb2VzbuKA
mXQgeWV0IGV4aXN0LiAgIFRoZSBvbmUgcGxhY2UgdGhpcyBpcyBwb3NhYmxlIGlzIGlmIHRoZSBy
ZWdpc3RyYXRpb24gZm9yIHRoZSBjbGllbnQgaXMgY29tcHJvbWlzZWQuICBIb3dldmVyIHdlIGFy
ZSBkaXNjdXNzaW5nIG90aGVyIG1pdGlnYXRpb25zIGZvciB0aGF0IHRoYXQgYWxzbyBleHBsaWNp
dGx5IGRvIG5vdCByZXF1aXJlIGRpc2NvdmVyeS4NCg0KSm9obiBCLg0KDQoNCkkgYW0gbm90IHN0
dWNrIG9uIHdlYmZpbmdlciBvciB3ZWxsLWtub3duLiBCZWNhdXNlIHRoaXMgaXMgY29uZmlnIG1h
eWJlIGl0IHNob3VsZCBiZSBhbiBvYXV0aCBlbmRwb2ludC4NCg0KUGhpbA0KDQpPbiBNYXIgMTEs
IDIwMTYsIGF0IDA2OjUxLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2
ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KSSB0aGluayBQaGlsIGlzIHByb3Bvc2luZyBzb21l
dGhpbmcgZGlmZmVyZW50LiAgIFNob3VsZCB0aGUgY2xpZW50IHNlbmQgYSB0b2tlbiBmcm9tIHRo
aXMgQVMgdG8gdGhhdCBSUy4NCg0KSGlzIGdvYWwgaXMgdG8gcHJldmVudCBtYW4gaW4gdGhlIG1p
ZGRsZSBhdHRhY2tzIHdoZXJlIGEgYmFkIFJTIGdldHMgYSBBVCB0aGF0IGlzIGF1ZGlhbmNlZCB0
by9hY2NlcHRlZCBieSBhbm90aGVyIFJTLg0KDQpUaGF0IGlzIHNlcGFyYXRlIGZyb20gdGhlIHF1
ZXN0aW9uIG9mIGlmIGEgUlMgYWNjZXB0cyB0b2tlbnMgZnJvbSBhIGdvb2QgQVMuICAgQSBiYWQg
QVMgd291bGQgYWx3YXlzIHNheSB5ZXMuDQoNCldlIG5lZWQgdG8gYmUgY2FyZWZ1bCBvZiB3aGF0
IGlmIGFueXRoaW5nIHRoZSBSUyBwcm92aWRlcyB0byB0aGUgY2xpZW50IGFzIG1ldGEtZGF0YSB3
aXRob3V0IHZhbGlkYXRpb24uDQoNCkN1cnJlbnRseSB0aGUgY2xpZW50IGNhbiBwcm92aWRlIGEg
bGlzdCBvZiBzY29wZXMgcmVxdWlyZWQgdG8gZ2V0IGFjY2Vzcy4gICBJIHBlcnNvbmFsbHkgZmVl
bCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gYWxzbyBpbmNsdWRlIGluIHRoZSB1bmF1dGhlbnRpY2F0
ZWQgZXJyb3IgcmVzcG9uc2UgYW4gaW5kaWNhdGlvbiBvZiB3aGF0IEFQSSB0aGUgcmVzb3VyY2Ug
c3VwcG9ydHMuICBTYXkg4oCcc2NpbTLigJ0gYXMgYW4gZXhhbXBsZS4gICBJIGRvbuKAmXQgdGhp
bmsgYWRkaW5nIHRoYXQgaXMgaG93ZXZlciBhIGhpZ2ggcHJpb3JpdHkgYXMgbW9zdCBpZiBhbGwg
Y2xpZW50cyBrbm93IHdoYXQgQVBJIHRoZXkgZXhwZWN0LiAgIEl0IG1pZ2h0IGJlIHVzZWZ1bCBp
ZiBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUgaWYgYSBjbGllbnQgd2VyZSB0byBiZSBnaXZl
biBhIFJTIFVSSSBpdCBjb3VsZCBjaGVjayB0byBzZWUgaWYgaXQgaXMgYSBwcm90b2NvbCB0aGF0
IGl0IHN1cHBvcnRzIGJlZm9yZSBib3RoZXJpbmcgd2l0aCBPQXV0aC4gICAgSSBleHBlY3QgdGhh
dCBhIGxvdCBvZiBwZW9wbGUgd2lsbCB3YW50IHRoYXQgbGVmdCB0byB0aGUgQVBJIGRlZmluaXRp
b24uICAgSSB0aGluayB3ZSBjYW4gdGFsayBhYm91dCBpdCBidXQgcmF0ZSB0aGlzIGxvdyBwcmlv
cml0eS4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBSUyBnaXZpbmcgb3V0IGEgbGlzdCBvZiBBUyB0aGF0
IGl0IHRydXN0cyBpcyBhIGdlbmVyYWxseSBiYWQgaWRlYS4gIEkgaG9wZSB0aGF0IGlzIG5vdCBv
biB0aGUgdGFibGUuDQoNCkkgZG9u4oCZdCB0aGluayB0aGF0IHByZXZlbnRpbmcgYSBjbGllbnQg
ZnJvbSBzZW5kaW5nIGEgdG9rZW4gdG8gdGhlIHdyb25nIFJTIGlzIHBhcnQgb2YgYSBBUyBtZXRh
LWRhdGEgZGlzY292ZXJ5IHByb2JsZW0uDQoNCkkgZG8gaG93ZXZlciB0aGluayB0aGF0IGl0IGlz
IGltcG9ydGFudC4NCg0KV2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhpcyBhcyBhIHNlcGFyYXRl
IHByb2JsZW0gdG8gQVMgbWV0YS1kYXRhIGRpc2NvdmVyeSB3aGVyZSB0aGUgZW5kcG9pbnRzIG9m
IHRoZSBBUyBhbmQgaXTigJlzIGNvbmZpZ3VyYXRpb24gYXJlIGRpc2NvdmVyeS4gICBTb3JyeSBm
b3IgcGVyaGFwcyBzdGF0aW5nIHRoZSBvYnZpb3VzLCBidXQgdGhlIFJTIGlzIGV4cGxpY2l0bHkg
bm90IHBhcnQgb2YgdGhlIEFTIGluIE9BdXRoIDIuICAgU3RhcnRpbmcgaW4gV0FQIHRoYXQgd2Fz
IGEgY29yZSBwcmluY2lwYWwuDQoNClNvIHdlIGhhdmUgYSBudW1iZXIgb2Ygb3B0aW9ucyB0byBh
ZGRyZXNzIHRoZSBSUyB0b2tlbiBsZWFrYWdlIHZpYSBNaVRNIGF0dGFja3MuDQoNCjEpIFBvUCBi
b3VuZCB0b2tlbnMuICBJZiB0aGV5IGFyZSBib3VuZCB0byB0aGUgVExTIGNoYW5uZWwgYnkgbXV0
dWFsIFRMUyBvciBUb2tlbiBiaW5kaW5nIHRoZXkgY2Fubm90IGJlIHJlcGxheWVkLiAgU2lnbmVk
IG1lc3NhZ2VzIHdoZXJlIHRoZSBzaWduaW5nIGNvdmVycyB0aGUgUlMgSG9zdCBhbmQgcGF0aCBj
b21wb25lbnRzLCAgYWxzbyB3b3VsZCB3b3JrLg0KDQoyKSBIYXZlIHRoZSBBUyBhdWRpZW5jZSBy
ZXN0cmljdCB0aGUgcmVzb3VyY2VzIHRoZSBBVCBpcyBnb29kIGF0LiAoQVQgc2hvdWxkIGJlIGRv
aW5nIHRoYXQgbm93KQ0KSW4gdGhlIHRva2VuIHJlc3BvbnNlIGluY2x1ZGUgdGhlIGxpc3Qgb2Yg
YXVkaWVuY2UvcyB0aGUgdG9rZW4gaXMgcHJlc2VudGFibGUgYXQuICBUaGUgY2xpZW50IHdvdWxk
IHRocm93IGFuIGVycm9yIGlmIHRoZSBSUyBpdCBpbnRlbmRzIHRvIHNlbmQgdGhlIHRva2VuIHRv
IGlzIG5vdCBvbiB0aGUgbGlzdC4gICBUaGUgUlMgdGhlIHRva2VuIGlzIGdvb2QgYXQgbWlnaHQg
Y2hhbmdlIGJhc2VkIG9uIHNjb3BlcywgY2xpZW50X2lkIGFuZCByZXNvdXJjZSBvd25lci4gICBU
aGlzIGlzIHRoZSBwbGFjZSB3aGVyZSBhbGwgb2YgdGhhdCBjb21lcyB0b2dldGhlci4gICBJbiBz
b21lIGNhc2VzIHRoZSBSUyBhbmQgQVMgbWlnaHQgbm90IGhhdmUgYSBwcmUtZXN0YWJsaXNoZWQg
cmVsYXRpb25zaGlwLiAgIFRoZSBjbGllbnQgc2hvdWxkIHNlbmQgdGhlIFJTIGJhc2UgVVJJIHRv
IHRoZSBBUyBhcyBwYXJ0IG9mIHRoZSByZXF1ZXN0LiAgVGhlIEFTIGNhbiB1c2UgdGhhdCB0byBh
dWRpZW5jZSByZXN0cmljdCB0aGUgQVQgYW5kIGlzc3VlIHRoZSBBVCBvciByZWZ1c2UgdG8gaXNz
dWUgdGhlIEFUIGJhc2VkIG9uIHBvbGljeS4NCkl0IGNhbiBhbHNvIHVzZSB0aGUgYXVkaWVuY2Ug
aW4gdGhlIHJlcXVlc3QgdG8gZG93biBhdWRpZW5jZSB0aGUgQVQgaWYgdGhlIGRlZmF1bHQgaXMg
dG8gaGF2ZSBtdWx0aXBsZSBhdWRpZW5jZXMuICAgIFdlIG1heSB3YW50IHRvIHVzZSBhIHRlcm0g
b3RoZXIgdGhhbiBhdWRpZW5jZSBmb3IgdGhpcyBsaWtlIHJlc291cmNlIG9yIGRlc3RpbmF0aW9u
LiAgSXQgaXMgYSBhdWRpZW5jZSBidXQgdGhhdCB0ZXJtIG1pZ2h0IGNvbmZ1c2UgcGVvcGxlIHdp
dGggQVQuDQoNCldlIGRpZCB0YWxrIGFib3V0IGJyZWFraW5nIGF1ZGllbmNlIG91dCBvZiBQT1Ag
a2V5IGRpc3RyaWJ1dGlvbiwgYW5kIEJyaWFuIENhbXBiZWxsIGRpZCBhIGRyYWZ0IGh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1kc3Q0and0PGh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm
dG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dCZkYXRh
PTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0
MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRh
PVNUciUyYjRrcmQxaHk4aDZlSE9DTGgxUHpRYUtNVWhXbEtWMmklMmZDTDBLMVNRJTNkPi4NCg0K
VG8gZG8gdGhpcyB3ZSBjb3VsZCB0YWtlIGRzdDRqd3QgYW5kIGFkZCBhbm90aGVyIHNwZWMgdGhh
dCBhZGRzIGEgbmV3IGRzdCBwYXJhbWV0ZXIgdG8gdGhlIHRva2VuIGFuZCBhdXRob3JpemF0aW9u
IGVuZHBvaW50cyByZXF1ZXN0cyBUaGF0IHdvdWxkIGJlIGEgc3BhY2Ugc2VwYXJhdGVkIGxpc3Qg
b2YgZHN0IHZhbHVlcy4gIGFuZCBpbiB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgdG9rZW4gZW5kcG9p
bnQgd291bGQgYmUgYSBKU09OIGFycmF5IG9mIGRzdCB2YWx1ZXMuDQoNCjMpIEhhdmUgdGhlIEFT
IGFsd2F5cyByZXR1cm4gYWxsIHRoZSBsaXN0IG9mIGFsbCBSUyB0aGUgdG9rZW4gY2FuIGJlIHVz
ZWQgYXQgKGJhc2ljYWxseSBOYXQncyBsaW5rIHJlbGF0aW9uc2hpcCBwcm9wb3NhbCkuICBJdCBu
ZWVkcyBhIHdheSB0byBoYW5kbGUNCmRvd24gZGVzdGluYXRpb25pbmcgb2YgQVQgYW5kIHRvIGFs
bG93IGZvciB1bi1jb25maWd1cmVkIFJTIHRoYXQgaXQgbWlnaHQgaXNzdWUgYSB0b2tlbiBmb3Iu
ICBTbyBjb3VsZCBiZSBjb21iaW5lZCB3aXRoIGRzdCBmcm9tIDIuICBCYXNpY2FsbHkgcmV0dXJu
aW5nIHRoZSBhY2NlcHRhYmxlIGRlc3RpbmF0aW9ucyBhcyBsaW5rIGhlYWRlcnMgdnMgSlMgaW4g
dGhlIHJlc3BvbnNlIGlzIG1vc3RseSBhIHN0eWxlIGlzc3VlIHRoYXQgb3RoZXIgcGVvcGxlIGNh
biBiaWtlIHNoZWQuDQoNCg0KNCkgVHJ5aW5nIHRvIGFkZCBhbGwgdGhlIFJTIHRvIHRoZSBBUyBk
aXNjb3ZlcnkgZG9jdW1lbnQuICBUaGlzIHNlZW1zIGltcHJhY3RpY2FsIGFzIHRoZXJlIHdvdWxk
IGJlIG11bHRpcGxlIHByb3RvY29scyBhbmQgZG9lc27igJl0IGFkZHJlc3MgdW4tY29uZmlndXJl
ZCBSUy4NCg0KNSkgU29tZSBuZXcgQVMgZW5kcG9pbnQgdGhhdCB0aGUgY2xpZW50IGNvdWxkIGlu
dHJvc3BlY3QgdGhlIFJTIFVSSSBhbmQgZ2V0IGJhY2sgbWV0YWRhdGEgYWJvdXQgaWYgdGhlIGNs
aWVudCBzaG91bGQgc2VuZCB0b2tlbnMgdGhlcmUuDQogICAgQSBjb3VwbGUgb2YgcHJvYmxlbXMg
d2l0aCB0aGlzLiAgVGhlIGZpcnN0IGlzIHRoYXQgaXQgd291bGQgbm90IHN1cHBvcnQgdW4tY29u
ZmlndXJlZCBSUyB1bmxlc3MgeW91IGFkZCBkc3QgdG8gdGhlIHRva2VuIGFuZCBhdXRob3JpemF0
aW9uIGVuZHBvaW50cy4gICBUaGUgb3RoZXIgaXMgdGhhdCB0aGUgaW50cm9zcGVjdGlvbiBlbmRw
b2ludCBkb2VzbuKAmXQgaGF2ZSB0aGUgY29udGV4dCBvZiB0aGUgUk8gYW5kIGNsaWVudF9pZCB1
bmxlc3MgeW91IGFsc28gcGFzcyB0aGUgY29kZS9SVCBhbmQgY2xpZW50X2lkLCBhbmQgcHJvYmFi
bHkgY2xpZW50IGNyZWRlbnRpYWxzLiAgICBCYXNpY2FsbHkgdGhpcyBpcyB0cnlpbmcgdG8gaW50
cm9zcGVjdCB0aGUgQVQgdG8gZGV0ZXJtaW5lIHRoZSBhdWRpYW5jZS9kc3QuICAgQnkgdGhlIHRp
bWUgeW91IGJ1aWxkIGEgbmV3IGludHJvc3BlY3Rpb24gZW5kcG9pbnQgc2VjdXJlbHkgaXQgaXMg
Z29pbmcgdG8gbG9vayBsaWtlIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIGEgYml0IG1vcmUgbWV0
YSBkYXRhIGFib3V0IHRoZSB0b2tlbiBiZXlvbmQgZXhwaXJ5IGFuZCBzY29wZXMuDQoNCg0KSSB0
aGluayB3ZSBzaG91bGQgZ28gYSBoZWFkIHdpdGggdGhlIHJlbmFtZWQgIk9BdXRoIDIuMCBBdXRo
b3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRhdGHigJ0NCkkgYW0gYWxzbyBmaW5lIHdp
dGggbWFraW5nIHRoZSBkZWZhdWx0IGRvY3VtZW50ICdvcGVuaWQtY29uZmlndXJhdGlvbuKAmSAg
YXMgbG9uZyBhcyB3ZSBhbGxvdyBmb3IgcHJvdG9jb2wgc3BlY2lmaWMgdmFyaWF0aW9uIHNvIHRo
YXQgU0NJTTIgY291bGQgZGVmaW5lIGEgZmlsZSBuYW1lLiAgICBJZiBwZW9wbGUgd2FudCB3ZSBj
b3VsZCBkbyBhIEFQSSAgdG8gZmlsZSBuYW1lIHJlZ2lzdHJ5IHNvIHRoYXQgcHJvdG9jb2wgc3Bl
Y2lmaWMgb25lcyBjYW4gYmUgZGVmaW5lZC4NCg0KV2UgYXJlIGFsbC1yZWFkeSB3b3JraW5nIG9u
IG9wdGlvbiAxIHRvIHNlY3VyZSBBVCwgd2UgbmVlZCBhIHNwZWMgbGlrZSBJIHByb3Bvc2UgaW4g
MiBmb3IgYmVhcmVyIHRva2Vucy4gIFdlIGNhbiBhZGQgb25lIHJlcXVlc3QgcGFyYW1ldGVyIGFu
ZCBhIGJpdCBtb3JlIHRva2VuIG1ldGEtZGF0YSB0byB0aGUgdG9rZW4gcmVzcG9uc2UgYW5kIHRo
YXQgdGFrZXMgY2FyZSBvZiB0aGUgcHJvYmxlbS4gICBIb25lc3RseSB3ZSBwcm9iYWJseSBzaG91
bGQgaGF2ZSBzZXBhcmF0ZWQgc2NvcGUgYW5kIGRlc3RpbmF0aW9uIGluIHRoZSBmaXJzdCBwbGFj
ZSBhbmQgcmV0dXJuZWQgYm90aCBkc3QgYW5kIHNjb3BlIGluIHRoZSByZXNwb25zZSBhbGwgYWxv
bmcsIHNvIHRoaXMgaXMgdXBkYXRlIHRoYXQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBlaXN0aW5n
IGFyY2hpdGVjdHVyZSBvZiBPQXV0aCAyLg0KDQpMZXRzIGtlZXAgdGhlIHR3byBpc3N1ZXMgc2Vw
YXJhdGUuDQoNCkpvaG4gQi4NCg0KDQoNCg0KT24gTWFyIDExLCAyMDE2LCBhdCAxMjowNyBBTSwg
QW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWlj
cm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gQVMgYW5kIFJT
IG5lZWQgdG8gYmUgc2NvcGVkIHRvIOKAnGRvZXMgdGhpcyBSUyBhY2NlcHQgdG9rZW5zIGZyb20g
dGhpcyBBU+KAnSBhcyBhIGxpc3QgaXMgdG9vIG11Y2ggaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBi
ZSB1c2VkIGluIHRoZSB3cm9uZyB3YXkNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmF0IFNha2ltdXJhDQpTZW50OiBUaHVyc2RheSwg
TWFyY2ggMTAsIDIwMTYgNjoyNSBQTQ0KVG86IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9y
YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhA
aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd
IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIE9BdXRoIDIuMCBEaXNjb3ZlcnkNCg0KUGhpbCwN
Cg0KUmlnaHQuIFNvIHdoYXQgbXkgY29uZGl0aW9uYWwgYXBwcm92YWxzICgxMSBjb25kaXRpb25z
IGluIHRvdGFsKSBzYWlkIHdhcyB0byBkcm9wIHRoZSB3b3JkICJkaXNjb3ZlcnkiIGZyb20gZXZl
cnl3aGVyZS4gVGhpcyBpcyBub3QgYSBkaXNjb3Zlcnkgc3BlYy4gVGhpcyBpcyBhIGNvbmZpZ3Vy
YXRpb24gbG9va3VwIHNwZWMgYXMgeW91IGNvcnJlY3RseSBwb2ludHMgb3V0LiBTbywgSSBhbSB3
aXRoIHlvdSBoZXJlLg0KDQpBbHNvLCBteSAybmQgY29uZGl0aWlvbiBpcyBlc3NlbnRpYWxseSBz
YXlpbmcgdG8gZHJvcCBzZWN0aW9uIDMuDQoNCk9uZSB0aGluZyB0aGF0IEkgb3Zlcmxvb2tlZCBh
bmQgYW0gd2l0aCB5b3UgaXMgdGhhdCB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gZXhwcmVzcyB0aGUg
QVMtUlMgcmVsYXRpb25zaGlwcy4gSSBoYXZlIGJlZW4gcHJlYWNoaW5nIHRoaXMgaW4gdGhlIG90
aGVyIHRocmVhZCBmb3Igc28gbWFueSB0aW1lcyBhcyB5b3Uga25vdyBzbyBJIHRob3VnaHQgSSBw
b2ludGVkIGl0IG91dCwgYnV0IG1pc3NlZCBhcHBhcmVudGx5IGluIG15IHByZXZpb3VzIGNvbW1l
bnQuIFNvLCBJIHdvdWxkIGFkZCBteSAxMnRoIGNvbmRpdGlvbjoNCg0KMTIuIEEgd2F5IHRvIGV4
cHJlc3MgYSBsaXN0IG9mIHZhbGlkIFJTcyBmb3IgdGhpcyBBUyBuZWVkcyB0byBiZSBhZGRlZCB0
byBzZWN0aW9uIDIuDQoNCkJlc3QsDQoNCk5hdA0KDQoyMDE2LTAzLTExIDI6MDkgR01UKzA5OjAw
IFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv
cmFjbGUuY29tPj46DQpJIHN0cm9uZ2x5IG9wcG9zZS4gMiBtYWpvciBpc3N1ZXMuDQoNClRoaXMg
aXMgbm90IHNlcnZpY2UgZGlzY292ZXJ5IHRoaXMgaXMgY29uZmlndXJhdGlvbiBsb29rdXAuIFRo
ZSBjbGllbnQgbXVzdCBoYXZlIGFscmVhZHkgZGlzY292ZXJlZCB0aGUgb2F1dGggaXNzdWVyIHVy
aSBhbmQgdGhlIHJlc291cmNlIHVyaS4NCg0KVGhlIG9iamVjdGl2ZSB3YXMgdG8gcHJvdmlkZSBh
IG1ldGhvZCB0byBlbnN1cmUgdGhlIGNsaWVudCBoYXMgYSB2YWxpZCBzZXQgb2YgZW5kcG9pbnRz
IHRvIHByZXZlbnQgbWl0bSBvZiBlbmRwb2ludHMgbGlrZSB0aGUgdG9rZW4gZW5kcG9pbnQgdG8g
dGhlIHJlc291cmNlIHNlcnZlci4NCg0KVGhlIGRyYWZ0IGRvZXMgbm90IGFkZHJlc3MgdGhlIGlz
c3VlIG9mIGEgY2xpZW50IGJlaW5nIGdpdmVuIGEgYmFkIGVuZHBvaW50IGZvciBhbiBycy4gV2hh
dCB3ZSBlbmQgdXAgd2l0aCBpcyBhIHByb21pc2N1b3VzIGF1dGh6IHNlcnZpY2UgZ2l2aW5nIG91
dCB0b2tlbnMgdG8gYW4gdW53aXR0aW5nIGNsaWVudC4NCg0KUGhpbA0KDQpPbiBNYXIgMTAsIDIw
MTYsIGF0IDA4OjA2LCBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29t
PG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3RlOg0KKzEgdG8gbW92ZSBmb3J3
YXJkIHdpdGggdGhlc2UNCk9uIDEwLzAzLzE2IDE3OjM1LCBCcmlhbiBDYW1wYmVsbCB3cm90ZToN
Cg0KKzENCg0KDQoNCk9uIFRodSwgTWFyIDEwLCAyMDE2IGF0IDY6MDQgQU0sIFJvbGFuZCBIZWRi
ZXJnIDxyb2xhbmQuaGVkYmVyZ0B1bXUuc2U+PG1haWx0bzpyb2xhbmQuaGVkYmVyZ0B1bXUuc2U+
DQoNCndyb3RlOg0KDQoNCg0KSSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgYmVpbmcgbW92ZWQgZm9y
d2FyZCB3aXRoIHRoZXNlIHR3byBjaGFuZ2VzOg0KDQoNCg0KLSBjaGFuZ2UgbmFtZSB0byDigJxP
QXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCdIGFzDQoN
CnByb3Bvc2VkIGJ5IEJyaWFuIGFuZA0KDQotIHVzZSB0aGUgVVJJIHBhdGggc3VmZml4IOKAmW9h
dXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCZIGluc3RlYWQgb2YNCg0K4oCZb3BlbmlkLWNvbmZp
Z3VyYXRpb27igJkgYXMgcHJvcG9zZWQgYnkgSnVzdGluLg0KDQoNCg0KMTggZmViIDIwMTYga2wu
IDE0OjQwIHNrcmV2IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0
PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pg0KDQo6DQoNCg0KDQpIaSBhbGwsDQoN
Cg0KDQpUaGlzIGlzIGEgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiB0aGUgIE9BdXRoIDIuMCBE
aXNjb3ZlcnkNCg0Kc3BlY2lmaWNhdGlvbjoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZo
dG1sJTJmZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEmZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT13MyUyYmlpYVdvbjgxTEpD
VSUyYjJtQ1BSbUElMmJyRUNCSGdxeVJyME9ncWlXU0hVJTNkPg0KDQoNCg0KU2luY2UgdGhpcyBk
b2N1bWVudCB3YXMgb25seSBhZG9wdGVkIHJlY2VudGx5IHdlIGFyZSBydW5uaW5nIHRoaXMgbGFz
dA0KDQpjYWxsIGZvciAqKjMgd2Vla3MqKi4NCg0KDQoNClBsZWFzZSBoYXZlIHlvdXIgY29tbWVu
dHMgaW4gbm8gbGF0ZXIgdGhhbiBNYXJjaCAxMHRoLg0KDQoNCg0KQ2lhbw0KDQpIYW5uZXMgJiBE
ZXJlaw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDEl
N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQz
NDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5D
aWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQri
gJQgUm9sYW5kDQoNCg0KDQrigJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0
bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIg0KDQo+RnJvbSDigJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJm
bGllc+KAmSBieSBSdXRoIEtyYXVzcw0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBp
ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlz
dGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzEx
NmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZr
JTJicVI5bTVXZ0EyayUzZD4NCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRm
Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv
b2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGlu
Zm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVh
ZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx
MWRiNDclN2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJi
cVI5bTVXZ0EyayUzZD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDEl
N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQz
NDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5D
aWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQoN
Cg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0K
aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZuYXQuc2FraW11cmEub3JnJTJmJmRhdGE9
MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUw
OGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9
NkZWbWRON2FkMFl6b1lLU05GJTJmRE8lMmZmRzJFRjFoYWo1YU9IaU1pZDZVTUklM2Q+DQpAX25h
dF9lbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B
dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEu
c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5p
ZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3Rvbnlu
YWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3
MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9YktzRVZCVVhjNTI4eWFB
TUxteWNYY0wzMyUyYkZKQ1FybnE5YXN4Um81SGU4JTNkPg0KDQoNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1
dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u
b3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZs
aXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
NGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmc2RhdGE9YktzRVZCVVhjNTI4eWFBTUxteWNYY0wzMyUyYkZKQ1FybnE5
YXN4Um81SGU4JTNkPg0KDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h
bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv
Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy
Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt
bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s
YXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U29ycnkgYnV0IG5v
dCB0cnVlLCB0aGlzIHN0YXJ0ZWQgb3V0IGFzIOKAnGRpc2NvdmVyeeKAnSBhbmQgbm93IGl04oCZ
cyBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l
PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNh
bXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJj
aCAxMSwgMjAxNiAzOjU5IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW4gJmx0O3Rv
bnluYWRAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gQnJhZGxleSAmbHQ7
dmU3anRiQHZlN2p0Yi5jb20mZ3Q7OyBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9u
IE9BdXRoIDIuMCBEaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGF0ICppcyogdGhlIHNjb3BlIG9mIHRoZSBjdXJyZW50IGRvY3VtZW50LCB3aGljaCBhIG1h
am9yaXR5IG9mIGZvbGtzIGhhdmUgYWdyZWVkIHdpdGguIEkgd2FzIHJlaXRlcmF0aW5nIHRoYXQg
dGhlIG5hbWUgb2YgdGhlIGRvY3VtZW50IHNob3VsZCByZWZsZWN0IGl0cyBjb250ZW50LCBzb21l
dGhpbmcgZWxzZSB0aGF0IGhhcyBiZWVuIHdpZGVseSBhZ3JlZWQgd2l0aC4mbmJzcDsNCjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXIgMTEs
IDIwMTYgYXQgNDoyNCBQTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9u
eW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ueW5hZEBtaWNyb3NvZnQuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGlzYWdyZWUsIHdoYXQg
cHVycG9zZSBpcyB0aGlzIGFjdGl2aXR5IHNvbHZpbmcgdGhlbiwgaXQgd2FzIGJlaW5nIHB1c2hl
ZCBhcyB3aGF0IHdhcyBuZWVkIHRvIHNvbHZlIHRoZSBNaXgtdXAsIGJ1dA0KIHRoYXQgaXMgbm90
IHRydWUuIFNvIG5vdyB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBjaGFuZ2UgaW4gc2NvcGUgYW5kIG5v
dCBkZWFsaW5nIHdpdGggZGlzY292ZXJ5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0iMTgzNzUyNzg2NF9fTWFpbEVuZENvbXBvc2UiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4gT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g
QmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1h
cmNoIDExLCAyMDE2IDM6MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQnJhZGxleSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZl
N2p0Yi5jb208L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0
Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3Qg
Q2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB0ZW5kIHRvIGFncmVlIHdpdGggSm9obiB0
aGF0IGFkZHJlc3NpbmcgdGhlIGNvbmNlcm5zIFBoaWwgcmFpc2VzIHNob3VsZCBiZSBwYXJ0IG9m
IChleHRlbnNpb24gdG8pIHRoZSBjb3JlIHByb3RvY29sLiZuYnNwOyBBbmQgdGhhdCB0aG9zZSBr
aW5kcyBvZiBjb25jZXJucyBkb24ndCBtYW5pZmVzdCBpbiB0aGUgd2F5IE9BdXRoDQogaXMgdHlw
aWNhbGx5IGRlcGxveWVkIG5vdy4gPGJyPg0KPGJyPg0KVGhlIGhvcGVmdWxseSBzb29uIHRvIGJl
IG5hbWVkICZxdW90O09BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSZxdW90
OyBzaG91bGQga2VlcCBpdCdzIHNjb3BlIHRvIHRoZSBwdWJsaXNoaW5nIG9mIGF1dGhvcml6YXRp
b24gc2VydmVyIG1ldGFkYXRhLiBUaGUgYWN0IG9mIGRvaW5nIGRpc2NvdmVyeSBpcyBiZXlvbmQg
aXRzIHNjb3BlIGFuZCBzbyBpcyB0cnlpbmcgdG8gcHJldmVudCBhIGNsaWVudCBmcm9tIHByZXNl
bnRpbmcgYSB0b2tlbiB0bw0KIHNvbWVwbGFjZSBpdCBzaG91bGRuJ3QuIDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgTWFyIDExLCAyMDE2
IGF0IDk6MDggQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdq
dGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW5saW5lPG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNYXIgMTEsIDIw
MTYsIGF0IDEyOjEzIFBNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGls
Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkluIG1hbnkgY2FzZSBhbGwgdGhlIEFTIGhhcyB0byBjaGVjayBp
cyB0aGUgZG9tYWluIG5hbWUgY29tcG9uZW50IHRvIGNoZWNrIGZvciBtaXRtLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UE9Q
IGFuZCB0aGUgb3RoZXIgc29sbnMgYXJlIGRyYW1hdGljYWxseSBtb3JlIGNvbXBsZXggdGhhbiBh
IHNpbXBsZSBjaGVjay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd2FzIHByb3Bv
c2luZyBkaW5nIHRoYXQgY2hlY2sgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb3IgdG9r
ZW4gZW5kcG9pbnQgYXMgcGFydCBvZiBBVCBpc3N1YW5jZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGlzIHVwIHRvIHRo
ZSBBUyBob3cgbXVjaCBvZiB0aGUgcGF0aCB0byB2YWxpZGF0ZSBhbmQgb3IgcHV0IGluIHRoZSBh
dWQgb3IgZHN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgc2VlIGl0
IGFzIHBhcnQgb2YgdGhlIGRpc2NvdmVyeShiYWQgbmFtZSBhc2lkZSkgcHJvYmxlbSBiZWNhdXNl
IHdlIGRpc2N1c3NlZCB0aGF0IGlmIGEgY2xpZW50IGZpbmRzDQo8YSBocmVmPSJodHRwczovL25h
MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYXBw
LmV4YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv
bSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkx
YWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1maVM4ZjYweXBpWGh5TTBxVlRlcWwlMmIlMmJP
ekgyd2JtRUNRRTdKNVR0R1BRTSUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KYXBwLmV4YW1wbGUuY29t
PC9hPiBob3cgZG8gd2UgZW5zdXJlIGl0IGdldHMgYSBjb21wbGV0ZSBzZXQgb2Ygb2F1dGggZW5k
cG9pbnRzIGFzIGEgdmFsaWQgc2V0IG9mIGVuZHBvaW50cy0tdGhhdCBhIGhhY2tlciBoYXMgbm90
IGluc2VydGVkIG9uZSBvZiB0aGVpciBvd24gZW5kcG9pbnRzLiBUaGUgbW9zdCBpbXBvcnRhbnQg
ZW5kcG9pbnQgdG8gZ2V0IHJpZ2h0IGlzIGVuc3VyaW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgKGFu
ZCBvcHRpb25hbGx5IHRoZQ0KIHBhdGgpIGlzIHRoZSBjb3JyZWN0IG9uZS4gV2UgY2FuJ3QgcmVh
bGx5IGRlZmluZSByZXNvdXJjZSBkaXNjb3ZlcnkgYnV0IHdlIGNhbiB2YWxpZGF0ZSBpdCB0byBz
b21lIGRlZ3JlZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5r
IGl0IGlzIHBhcnQgb2YgY29yZSBwcm90b2NvbCBzZWN1cml0eSBhbmQgc2hvdWxkL211c3Qgbm90
IHJlcXVpcmUgZGlzY292ZXJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCBpcw0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAx
LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5l
eGFtcGxlLmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0
YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9akFzWlFlQ2hKJTJiUjFsYnlCb1ZLd2hlSVlpM1BpV0xy
cSUyYnhETGJxVTZyeGslM2QiIHRhcmdldD0iX2JsYW5rIj4NCmFwcC5leGFtcGxlLmNvbTwvYT4g
PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+SWYgaXQgaXMgdGhlIHJlc291cmNlIHRoZW4gdGhlIGNsaWVudCB3b3VsZCBiZSBw
cmVjb25maWd1cmVkIGZvciBpdOKAmXMgQVMgb3V0IG9mIGJhbmQgb3Igb3B0aW9uYWxseSB3b3Vs
ZCBkbyBkaXNjb3Zlcnkgb24gdGhlIGlzc3VlciB1cmkgdGhhdCB5b3UgYWRtaXQgbmVlZHMgdG8g
YmUgY29uZmlndXJlZCBvdXQNCiBvZiBiYW5kIHNvbWUgd2F5IChub3RlIGRpc2NvdmVyeSBpcyBv
cHRpb25hbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkluIHRoZSBBUyBtZXRhLWRhdGEgZHJhZnQgaXQgd291bGQgZG8gYSBnZXQgb24g
YSB3ZWxsIGtub3duIGZpbGUgdGhhdCB3b3VsZCBoYXZlIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBB
UywgYnV0IG5vdCB0aGUgUlMsIHRob3VnaCBzb21lIEFQSSBtYXkgb3B0aW9uYWxseSBsaXN0IGEg
QVBJIGVuZHBvaW50IGxpa2UNCiBjb25uZWN0IGhhcy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgY2xpZW50IHRoZW4g
bWFrZXMgYSBhdXRob3JpemF0aW9uIHJlcXVlc3QgKGFmdGVyIHJlZ2lzdGVyaW5nIG91dCBvZiBi
YW5kIG9yIGR5bmFtaWNhbGx5KS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIHBhcnQgb2YgdGhlIGF1dGhvcml6YXRpb24gcmVx
dWVzdCBmb3IgaW1wbGljaXQgaXQgY291bGQgcHJvdmlkZSB0aGUgYXVkL2RzdCB0aGF0IGl0IHdh
bnRzIHRoZSB0b2tlbiBmb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPklmIHRoYXQgaXMgbm90IHNlbnQgdGhlbiB0aGUgYXVkL2RzdCBhcmUg
aW1wbGljaXQgaW4gdGhlIHNjb3Blcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjbGllbnQgZ2V0cyBiYWNrIGEgQVQgd2l0aCBh
IGxpc3Qgb2Ygc2NvcGVzIGdyYW50ZWQsIGF1ZC9kc3QgYWxsb3dlZCBhbmQgdGltZSB0byBsaXZl
IGZvciB0aGUgdG9rZW4gKG9uZSBleHRyYSB0aGluZyByZXR1cm5lZCk8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgZG9lc27igJl0
IHJlcXVpcmUgYW55IGRpc2NvdmVyeSAoeWVzIHRoZXJlIGlzIGEgb3B0aW9uYWwgQVMgbWV0YS1k
YXRhIGRpc2NvdmVyeSBidXQgbm90IHJlcXVpcmVkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBwcmVmZXIgdG8gZml4IHRoZSBSUyBt
YW4gaW4gdGhlIG1pZGRsZSBpc3N1ZSBhcyBwYXJ0IG9mIHRoZSBwcm90b2NvbCBhbmQgbm90IHBh
cnQgb2YgZGlzY292ZXJ5IHRoYXQgc2hvdWxkIHJlbWFpbiBvcHRpb25hbC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaG9uZXN0bHkg
ZG9u4oCZdCBxdWl0ZSBrbm93IGhvdyB0aGUgY2xpZW50IGxlYXJucyBhYm91dCB0aGlzIGJhZCBS
UyBhbmQgc3RhcnRzIHRhbGtpbmcgdG8gaXQsIHNvIHRoaXMgbWF5IGJlIGEgc29sdXRpb24gdG8g
YSBwcm9ibGVtIHRoYXQgZG9lc27igJl0IHlldCBleGlzdC4gJm5ic3A7IFRoZSBvbmUgcGxhY2Ug
dGhpcw0KIGlzIHBvc2FibGUgaXMgaWYgdGhlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIGNsaWVudCBp
cyBjb21wcm9taXNlZC4mbmJzcDsgSG93ZXZlciB3ZSBhcmUgZGlzY3Vzc2luZyBvdGhlciBtaXRp
Z2F0aW9ucyBmb3IgdGhhdCB0aGF0IGFsc28gZXhwbGljaXRseSBkbyBub3QgcmVxdWlyZSBkaXNj
b3ZlcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn
aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbSBub3Qgc3R1Y2sgb24gd2ViZmluZ2Vy
IG9yIHdlbGwta25vd24uIEJlY2F1c2UgdGhpcyBpcyBjb25maWcgbWF5YmUgaXQgc2hvdWxkIGJl
IGFuIG9hdXRoIGVuZHBvaW50LiZuYnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWFyIDExLCAyMDE2LCBh
dCAwNjo1MSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5j
b20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhp
bmsgUGhpbCBpcyBwcm9wb3Npbmcgc29tZXRoaW5nIGRpZmZlcmVudC4gJm5ic3A7IFNob3VsZCB0
aGUgY2xpZW50IHNlbmQgYSB0b2tlbiBmcm9tIHRoaXMgQVMgdG8gdGhhdCBSUy4gJm5ic3A7PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGlzIGdvYWwg
aXMgdG8gcHJldmVudCBtYW4gaW4gdGhlIG1pZGRsZSBhdHRhY2tzIHdoZXJlIGEgYmFkIFJTIGdl
dHMgYSBBVCB0aGF0IGlzIGF1ZGlhbmNlZCB0by9hY2NlcHRlZCBieSBhbm90aGVyIFJTLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhh
dCBpcyBzZXBhcmF0ZSBmcm9tIHRoZSBxdWVzdGlvbiBvZiBpZiBhIFJTIGFjY2VwdHMgdG9rZW5z
IGZyb20gYSBnb29kIEFTLiAmbmJzcDsgQSBiYWQgQVMgd291bGQgYWx3YXlzIHNheSB5ZXMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5X
ZSBuZWVkIHRvIGJlIGNhcmVmdWwgb2Ygd2hhdCBpZiBhbnl0aGluZyB0aGUgUlMgcHJvdmlkZXMg
dG8gdGhlIGNsaWVudCBhcyBtZXRhLWRhdGEgd2l0aG91dCB2YWxpZGF0aW9uLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q3VycmVudGx5
IHRoZSBjbGllbnQgY2FuIHByb3ZpZGUgYSBsaXN0IG9mIHNjb3BlcyByZXF1aXJlZCB0byBnZXQg
YWNjZXNzLiAmbmJzcDsgSSBwZXJzb25hbGx5IGZlZWwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGFs
c28gaW5jbHVkZSBpbiB0aGUgdW5hdXRoZW50aWNhdGVkIGVycm9yIHJlc3BvbnNlIGFuIGluZGlj
YXRpb24NCiBvZiB3aGF0IEFQSSB0aGUgcmVzb3VyY2Ugc3VwcG9ydHMuJm5ic3A7IFNheSDigJxz
Y2ltMuKAnSBhcyBhbiBleGFtcGxlLiAmbmJzcDsgSSBkb27igJl0IHRoaW5rIGFkZGluZyB0aGF0
IGlzIGhvd2V2ZXIgYSBoaWdoIHByaW9yaXR5IGFzIG1vc3QgaWYgYWxsIGNsaWVudHMga25vdyB3
aGF0IEFQSSB0aGV5IGV4cGVjdC4gJm5ic3A7IEl0IG1pZ2h0IGJlIHVzZWZ1bCBpZiBhdCBzb21l
IHBvaW50IGluIHRoZSBmdXR1cmUgaWYgYSBjbGllbnQgd2VyZSB0byBiZSBnaXZlbiBhIFJTIFVS
SQ0KIGl0IGNvdWxkIGNoZWNrIHRvIHNlZSBpZiBpdCBpcyBhIHByb3RvY29sIHRoYXQgaXQgc3Vw
cG9ydHMgYmVmb3JlIGJvdGhlcmluZyB3aXRoIE9BdXRoLiAmbmJzcDsgJm5ic3A7SSBleHBlY3Qg
dGhhdCBhIGxvdCBvZiBwZW9wbGUgd2lsbCB3YW50IHRoYXQgbGVmdCB0byB0aGUgQVBJIGRlZmlu
aXRpb24uICZuYnNwOyBJIHRoaW5rIHdlIGNhbiB0YWxrIGFib3V0IGl0IGJ1dCByYXRlIHRoaXMg
bG93IHByaW9yaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+SSBhZ3JlZSB0aGF0IHRoZSBSUyBnaXZpbmcgb3V0IGEgbGlzdCBvZiBB
UyB0aGF0IGl0IHRydXN0cyBpcyBhIGdlbmVyYWxseSBiYWQgaWRlYS4mbmJzcDsgSSBob3BlIHRo
YXQgaXMgbm90IG9uIHRoZSB0YWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9u4oCZdCB0aGluayB0aGF0IHByZXZlbnRpbmcg
YSBjbGllbnQgZnJvbSBzZW5kaW5nIGEgdG9rZW4gdG8gdGhlIHdyb25nIFJTIGlzIHBhcnQgb2Yg
YSBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5IHByb2JsZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvIGhvd2V2ZXIgdGhpbmsgdGhh
dCBpdCBpcyBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5XZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlzIGFzIGEgc2Vw
YXJhdGUgcHJvYmxlbSB0byBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5IHdoZXJlIHRoZSBlbmRwb2lu
dHMgb2YgdGhlIEFTIGFuZCBpdOKAmXMgY29uZmlndXJhdGlvbiBhcmUgZGlzY292ZXJ5LiAmbmJz
cDsgU29ycnkgZm9yIHBlcmhhcHMgc3RhdGluZyB0aGUNCiBvYnZpb3VzLCBidXQgdGhlIFJTIGlz
IGV4cGxpY2l0bHkgbm90IHBhcnQgb2YgdGhlIEFTIGluIE9BdXRoIDIuICZuYnNwOyBTdGFydGlu
ZyBpbiBXQVAgdGhhdCB3YXMgYSBjb3JlIHByaW5jaXBhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIHdlIGhhdmUgYSBudW1iZXIg
b2Ygb3B0aW9ucyB0byBhZGRyZXNzIHRoZSBSUyB0b2tlbiBsZWFrYWdlIHZpYSBNaVRNIGF0dGFj
a3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4xKSBQb1AgYm91bmQgdG9rZW5zLiZuYnNwOyBJZiB0aGV5IGFyZSBib3VuZCB0byB0aGUg
VExTIGNoYW5uZWwgYnkgbXV0dWFsIFRMUyBvciBUb2tlbiBiaW5kaW5nIHRoZXkgY2Fubm90IGJl
IHJlcGxheWVkLiZuYnNwOyBTaWduZWQgbWVzc2FnZXMgd2hlcmUgdGhlIHNpZ25pbmcgY292ZXJz
IHRoZSBSUyBIb3N0IGFuZCBwYXRoDQogY29tcG9uZW50cywgJm5ic3A7YWxzbyB3b3VsZCB3b3Jr
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+MikgSGF2ZSB0aGUgQVMgYXVkaWVuY2UgcmVzdHJpY3QgdGhlIHJlc291cmNlcyB0aGUgQVQg
aXMgZ29vZCBhdC4gKEFUIHNob3VsZCBiZSBkb2luZyB0aGF0IG5vdykmbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhlIHRva2Vu
IHJlc3BvbnNlIGluY2x1ZGUgdGhlIGxpc3Qgb2YgYXVkaWVuY2UvcyB0aGUgdG9rZW4gaXMgcHJl
c2VudGFibGUgYXQuJm5ic3A7IFRoZSBjbGllbnQgd291bGQgdGhyb3cgYW4gZXJyb3IgaWYgdGhl
IFJTIGl0IGludGVuZHMgdG8gc2VuZCB0aGUgdG9rZW4gdG8gaXMgbm90IG9uIHRoZSBsaXN0Lg0K
ICZuYnNwOyBUaGUgUlMgdGhlIHRva2VuIGlzIGdvb2QgYXQgbWlnaHQgY2hhbmdlIGJhc2VkIG9u
IHNjb3BlcywgY2xpZW50X2lkIGFuZCByZXNvdXJjZSBvd25lci4gJm5ic3A7IFRoaXMgaXMgdGhl
IHBsYWNlIHdoZXJlIGFsbCBvZiB0aGF0IGNvbWVzIHRvZ2V0aGVyLiAmbmJzcDsgSW4gc29tZSBj
YXNlcyB0aGUgUlMgYW5kIEFTIG1pZ2h0IG5vdCBoYXZlIGEgcHJlLWVzdGFibGlzaGVkIHJlbGF0
aW9uc2hpcC4gJm5ic3A7IFRoZSBjbGllbnQgc2hvdWxkIHNlbmQgdGhlIFJTIGJhc2UNCiBVUkkg
dG8gdGhlIEFTIGFzIHBhcnQgb2YgdGhlIHJlcXVlc3QuJm5ic3A7IFRoZSBBUyBjYW4gdXNlIHRo
YXQgdG8gYXVkaWVuY2UgcmVzdHJpY3QgdGhlIEFUIGFuZCBpc3N1ZSB0aGUgQVQgb3IgcmVmdXNl
IHRvIGlzc3VlIHRoZSBBVCBiYXNlZCBvbiBwb2xpY3kuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGNhbiBhbHNvIHVzZSB0aGUgYXVkaWVu
Y2UgaW4gdGhlIHJlcXVlc3QgdG8gZG93biBhdWRpZW5jZSB0aGUgQVQgaWYgdGhlIGRlZmF1bHQg
aXMgdG8gaGF2ZSBtdWx0aXBsZSBhdWRpZW5jZXMuICZuYnNwOyAmbmJzcDtXZSBtYXkgd2FudCB0
byB1c2UgYSB0ZXJtIG90aGVyIHRoYW4gYXVkaWVuY2UgZm9yIHRoaXMgbGlrZQ0KIHJlc291cmNl
IG9yIGRlc3RpbmF0aW9uLiZuYnNwOyBJdCBpcyBhIGF1ZGllbmNlIGJ1dCB0aGF0IHRlcm0gbWln
aHQgY29uZnVzZSBwZW9wbGUgd2l0aCBBVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGRpZCB0YWxrIGFib3V0IGJyZWFraW5nIGF1
ZGllbmNlIG91dCBvZiBQT1Aga2V5IGRpc3RyaWJ1dGlvbiwgYW5kIEJyaWFuIENhbXBiZWxsIGRp
ZCBhIGRyYWZ0Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZk
cmFmdC1jYW1wYmVsbC1vYXV0aC1kc3Q0and0JmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1TVHIlMmI0a3JkMWh5OGg2
ZUhPQ0xoMVB6UWFLTVVoV2xLVjJpJTJmQ0wwSzFTUSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1kc3Q0and0PC9hPi4N
CiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlRvIGRvIHRoaXMgd2UgY291bGQgdGFrZSBkc3Q0and0IGFuZCBhZGQg
YW5vdGhlciBzcGVjIHRoYXQgYWRkcyBhIG5ldyBkc3QgcGFyYW1ldGVyIHRvIHRoZSB0b2tlbiBh
bmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludHMgcmVxdWVzdHMgVGhhdCB3b3VsZCBiZSBhIHNwYWNl
IHNlcGFyYXRlZCBsaXN0IG9mIGRzdA0KIHZhbHVlcy4gJm5ic3A7YW5kIGluIHRoZSByZXNwb25z
ZSBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB3b3VsZCBiZSBhIEpTT04gYXJyYXkgb2YgZHN0IHZh
bHVlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjMpIEhhdmUgdGhlIEFTIGFsd2F5cyByZXR1cm4gYWxsIHRoZSBsaXN0IG9mIGFsbCBS
UyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQgYXQgKGJhc2ljYWxseSBOYXQncyBsaW5rIHJlbGF0aW9u
c2hpcCBwcm9wb3NhbCkuJm5ic3A7IEl0IG5lZWRzIGEgd2F5IHRvIGhhbmRsZSZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5kb3duIGRl
c3RpbmF0aW9uaW5nIG9mIEFUIGFuZCB0byBhbGxvdyBmb3IgdW4tY29uZmlndXJlZCBSUyB0aGF0
IGl0IG1pZ2h0IGlzc3VlIGEgdG9rZW4gZm9yLiZuYnNwOyBTbyBjb3VsZCBiZSBjb21iaW5lZCB3
aXRoIGRzdCBmcm9tIDIuJm5ic3A7IEJhc2ljYWxseSByZXR1cm5pbmcgdGhlIGFjY2VwdGFibGUg
ZGVzdGluYXRpb25zDQogYXMgbGluayBoZWFkZXJzIHZzIEpTIGluIHRoZSByZXNwb25zZSBpcyBt
b3N0bHkgYSBzdHlsZSBpc3N1ZSB0aGF0IG90aGVyIHBlb3BsZSBjYW4gYmlrZSBzaGVkLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjQpIFRyeWluZyB0byBhZGQgYWxsIHRoZSBSUyB0byB0aGUgQVMgZGlzY292ZXJ5IGRvY3VtZW50
LiZuYnNwOyBUaGlzIHNlZW1zIGltcHJhY3RpY2FsIGFzIHRoZXJlIHdvdWxkIGJlIG11bHRpcGxl
IHByb3RvY29scyBhbmQgZG9lc27igJl0IGFkZHJlc3MgdW4tY29uZmlndXJlZCBSUy48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjUpIFNv
bWUgbmV3IEFTIGVuZHBvaW50IHRoYXQgdGhlIGNsaWVudCBjb3VsZCBpbnRyb3NwZWN0IHRoZSBS
UyBVUkkgYW5kIGdldCBiYWNrIG1ldGFkYXRhIGFib3V0IGlmIHRoZSBjbGllbnQgc2hvdWxkIHNl
bmQgdG9rZW5zIHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IEEgY291cGxlIG9mIHByb2JsZW1zIHdpdGggdGhp
cy4mbmJzcDsgVGhlIGZpcnN0IGlzIHRoYXQgaXQgd291bGQgbm90IHN1cHBvcnQgdW4tY29uZmln
dXJlZCBSUyB1bmxlc3MgeW91IGFkZCBkc3QgdG8gdGhlIHRva2VuIGFuZCBhdXRob3JpemF0aW9u
IGVuZHBvaW50cy4gJm5ic3A7IFRoZSBvdGhlciBpcyB0aGF0IHRoZQ0KIGludHJvc3BlY3Rpb24g
ZW5kcG9pbnQgZG9lc27igJl0IGhhdmUgdGhlIGNvbnRleHQgb2YgdGhlIFJPIGFuZCBjbGllbnRf
aWQgdW5sZXNzIHlvdSBhbHNvIHBhc3MgdGhlIGNvZGUvUlQgYW5kIGNsaWVudF9pZCwgYW5kIHBy
b2JhYmx5IGNsaWVudCBjcmVkZW50aWFscy4gJm5ic3A7ICZuYnNwO0Jhc2ljYWxseSB0aGlzIGlz
IHRyeWluZyB0byBpbnRyb3NwZWN0IHRoZSBBVCB0byBkZXRlcm1pbmUgdGhlIGF1ZGlhbmNlL2Rz
dC4gJm5ic3A7IEJ5IHRoZSB0aW1lIHlvdSBidWlsZA0KIGEgbmV3IGludHJvc3BlY3Rpb24gZW5k
cG9pbnQgc2VjdXJlbHkgaXQgaXMgZ29pbmcgdG8gbG9vayBsaWtlIHRoZSB0b2tlbiBlbmRwb2lu
dCB3aXRoIGEgYml0IG1vcmUgbWV0YSBkYXRhIGFib3V0IHRoZSB0b2tlbiBiZXlvbmQgZXhwaXJ5
IGFuZCBzY29wZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB3ZSBzaG91bGQgZ28gYSBoZWFkIHdpdGggdGhlIHJl
bmFtZWQgJnF1b3Q7T0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeSBNZXRh
ZGF0YeKAnSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5JIGFtIGFsc28gZmluZSB3aXRoIG1ha2luZyB0aGUgZGVmYXVsdCBkb2N1bWVu
dCAnb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgJm5ic3A7YXMgbG9uZyBhcyB3ZSBhbGxvdyBmb3Ig
cHJvdG9jb2wgc3BlY2lmaWMgdmFyaWF0aW9uIHNvIHRoYXQgU0NJTTIgY291bGQgZGVmaW5lIGEg
ZmlsZSBuYW1lLiAmbmJzcDsgJm5ic3A7SWYgcGVvcGxlDQogd2FudCB3ZSBjb3VsZCBkbyBhIEFQ
SSAmbmJzcDt0byBmaWxlIG5hbWUgcmVnaXN0cnkgc28gdGhhdCBwcm90b2NvbCBzcGVjaWZpYyBv
bmVzIGNhbiBiZSBkZWZpbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgYXJlIGFsbC1yZWFkeSB3b3JraW5nIG9uIG9wdGlvbiAx
IHRvIHNlY3VyZSBBVCwgd2UgbmVlZCBhIHNwZWMgbGlrZSBJIHByb3Bvc2UgaW4gMiBmb3IgYmVh
cmVyIHRva2Vucy4mbmJzcDsgV2UgY2FuIGFkZCBvbmUgcmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGEg
Yml0IG1vcmUgdG9rZW4gbWV0YS1kYXRhIHRvIHRoZQ0KIHRva2VuIHJlc3BvbnNlIGFuZCB0aGF0
IHRha2VzIGNhcmUgb2YgdGhlIHByb2JsZW0uICZuYnNwOyBIb25lc3RseSB3ZSBwcm9iYWJseSBz
aG91bGQgaGF2ZSBzZXBhcmF0ZWQgc2NvcGUgYW5kIGRlc3RpbmF0aW9uIGluIHRoZSBmaXJzdCBw
bGFjZSBhbmQgcmV0dXJuZWQgYm90aCBkc3QgYW5kIHNjb3BlIGluIHRoZSByZXNwb25zZSBhbGwg
YWxvbmcsIHNvIHRoaXMgaXMgdXBkYXRlIHRoYXQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBlaXN0
aW5nIGFyY2hpdGVjdHVyZQ0KIG9mIE9BdXRoIDIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5MZXRzIGtlZXAgdGhlIHR3byBpc3N1ZXMg
c2VwYXJhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTWFyIDEx
LCAyMDE2LCBhdCAxMjowNyBBTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86
dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ueW5hZEBtaWNyb3NvZnQu
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHJlbGF0aW9uc2hpcCBiZXR3
ZWVuIEFTIGFuZCBSUyBuZWVkIHRvIGJlIHNjb3BlZCB0byDigJxkb2VzIHRoaXMgUlMgYWNjZXB0
IHRva2VucyBmcm9tIHRoaXMgQVPigJ0gYXMgYSBsaXN0IGlzIHRvbw0KIG11Y2ggaW5mb3JtYXRp
b24gdGhhdCBjb3VsZCBiZSB1c2VkIGluIHRoZSB3cm9uZyB3YXk8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9IjE4Mzc1
Mjc4NjRfMTI3Mjg5NjQyOV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4mbmJzcDtPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dJm5ic3A7
PGI+T24NCiBCZWhhbGYgT2YmbmJzcDs8L2I+TmF0IFNha2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+
Jm5ic3A7VGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2IDY6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+Jm5i
c3A7UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j
b20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+
Q2M6PC9iPiZuYnNwO29hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+
Jm5ic3A7UmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4w
IERpc2NvdmVyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QaGlsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPlJpZ2h0LiBTbyB3aGF0IG15IGNvbmRpdGlvbmFsIGFwcHJvdmFscyAoMTEgY29uZGl0aW9u
cyBpbiB0b3RhbCkgc2FpZCB3YXMgdG8gZHJvcCB0aGUgd29yZCAmcXVvdDtkaXNjb3ZlcnkmcXVv
dDsgZnJvbSBldmVyeXdoZXJlLiBUaGlzIGlzIG5vdCBhIGRpc2NvdmVyeSBzcGVjLiBUaGlzIGlz
IGEgY29uZmlndXJhdGlvbiBsb29rdXANCiBzcGVjIGFzIHlvdSBjb3JyZWN0bHkgcG9pbnRzIG91
dC4gU28sIEkgYW0gd2l0aCB5b3UgaGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkFsc28sIG15IDJuZCBjb25kaXRpaW9uIGlzIGVzc2VudGlhbGx5IHNheWluZyB0byBk
cm9wIHNlY3Rpb24gMy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uZSB0
aGluZyB0aGF0IEkgb3Zlcmxvb2tlZCBhbmQgYW0gd2l0aCB5b3UgaXMgdGhhdCB3ZSBuZWVkIHRv
IGJlIGFibGUgdG8gZXhwcmVzcyB0aGUgQVMtUlMgcmVsYXRpb25zaGlwcy4gSSBoYXZlIGJlZW4g
cHJlYWNoaW5nIHRoaXMgaW4gdGhlIG90aGVyIHRocmVhZCBmb3Igc28gbWFueSB0aW1lcyBhcyB5
b3UNCiBrbm93IHNvIEkgdGhvdWdodCBJIHBvaW50ZWQgaXQgb3V0LCBidXQgbWlzc2VkIGFwcGFy
ZW50bHkgaW4gbXkgcHJldmlvdXMgY29tbWVudC4gU28sIEkgd291bGQgYWRkIG15IDEydGggY29u
ZGl0aW9uOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTIuIEEgd2F5IHRv
IGV4cHJlc3MgYSBsaXN0IG9mIHZhbGlkIFJTcyBmb3IgdGhpcyBBUyBuZWVkcyB0byBiZSBhZGRl
ZCB0byBzZWN0aW9uIDIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0
LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4yMDE2LTAzLTExIDI6MDkgR01UJiM0MzswOTowMCBQaGlsIEh1bnQg
KElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9z
cGFuPjwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp
Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+SSBzdHJvbmdseSBvcHBvc2UuIDIgbWFqb3IgaXNzdWVzLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBpcyBub3Qgc2VydmljZSBkaXNj
b3ZlcnkgdGhpcyBpcyBjb25maWd1cmF0aW9uIGxvb2t1cC4gVGhlIGNsaWVudCBtdXN0IGhhdmUg
YWxyZWFkeSBkaXNjb3ZlcmVkIHRoZSBvYXV0aCBpc3N1ZXIgdXJpIGFuZCB0aGUgcmVzb3VyY2Ug
dXJpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG9iamVjdGl2ZSB3
YXMgdG8gcHJvdmlkZSBhIG1ldGhvZCB0byBlbnN1cmUgdGhlIGNsaWVudCBoYXMgYSB2YWxpZCBz
ZXQgb2YgZW5kcG9pbnRzIHRvIHByZXZlbnQgbWl0bSBvZiBlbmRwb2ludHMgbGlrZSB0aGUgdG9r
ZW4gZW5kcG9pbnQgdG8gdGhlIHJlc291cmNlIHNlcnZlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlRoZSBkcmFmdCBkb2VzIG5vdCBhZGRyZXNzIHRoZSBpc3N1ZSBvZiBh
IGNsaWVudCBiZWluZyBnaXZlbiBhIGJhZCBlbmRwb2ludCBmb3IgYW4gcnMuIFdoYXQgd2UgZW5k
IHVwIHdpdGggaXMgYSBwcm9taXNjdW91cyBhdXRoeiBzZXJ2aWNlIGdpdmluZyBvdXQgdG9rZW5z
IHRvIGFuIHVud2l0dGluZyBjbGllbnQuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi
Pjxicj4NCjxicj4NClBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBNYXIgMTAsIDIw
MTYsIGF0IDA4OjA2LCBWbGFkaW1pciBEemh1dmlub3YgJmx0OzxhIGhyZWY9Im1haWx0bzp2bGFk
aW1pckBjb25uZWN0MmlkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiYjNDM7MSB0byBt
b3ZlIGZvcndhcmQgd2l0aCB0aGVzZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPk9uIDEwLzAzLzE2IDE3OjM1LCBCcmlhbiBDYW1wYmVsbCB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+JiM0MzsxPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+T24gVGh1LCBNYXIg
MTAsIDIwMTYgYXQgNjowNCBBTSwgUm9sYW5kIEhlZGJlcmcgPGEgaHJlZj0ibWFpbHRvOnJvbGFu
ZC5oZWRiZXJnQHVtdS5zZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPiZsdDtyb2xhbmQuaGVkYmVyZ0B1bXUuc2UmZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT53cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cHJlPkkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IGJlaW5nIG1vdmVkIGZvcndh
cmQgd2l0aCB0aGVzZSB0d28gY2hhbmdlczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIGNoYW5nZSBuYW1lIHRvIOKAnE9BdXRoIDIuMCBBdXRo
b3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRhdGHigJ0gYXM8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5wcm9wb3NlZCBieSBCcmlhbiBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIHVz
ZSB0aGUgVVJJIHBhdGggc3VmZml4IOKAmW9hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCZIGlu
c3RlYWQgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7igJlvcGVuaWQtY29uZmlndXJhdGlvbuKA
mSBhcyBwcm9wb3NlZCBieSBKdXN0aW4uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86
cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHByZT4xOCBmZWIgMjAxNiBrbC4gMTQ6NDAgc2tyZXYgSGFubmVz
IFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0
IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGFubmVzLnRzY2hv
ZmVuaWdAZ214Lm5ldDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+OjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhpIGFsbCw8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGlz
IGEgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiB0aGUmbmJzcDsgT0F1dGggMi4wIERpc2NvdmVy
eTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPnNwZWNpZmljYXRpb246PG86
cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy
b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJm
aHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxJmFtcDtkYXRhPTAxJTdjMDElN2N0
b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1Yzcy
JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT13MyUyYmlp
YVdvbjgxTEpDVSUyYjJtQ1BSbUElMmJyRUNCSGdxeVJyME9ncWlXU0hVJTNkIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TaW5jZSB0aGlzIGRvY3Vt
ZW50IHdhcyBvbmx5IGFkb3B0ZWQgcmVjZW50bHkgd2UgYXJlIHJ1bm5pbmcgdGhpcyBsYXN0PG86
cD48L286cD48L3ByZT4NCjxwcmU+Y2FsbCBmb3IgKiozIHdlZWtzKiouPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIGhhdmUgeW91ciBj
b21tZW50cyBpbiBubyBsYXRlciB0aGFuIE1hcmNoIDEwdGguPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2lhbzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPkhhbm5lcyAmYW1wOyBEZXJlazxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48
L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu
a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3Jn
JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQl
NDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJr
JTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPuKAlCBSb2xhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT7igJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUg
c3RyZWFtIGFuZCBsaXN0ZW4uJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0O0Zyb20g
4oCZT3BlbiBIb3VzZSBmb3IgQnV0dGVyZmxpZXPigJkgYnkgUnV0aCBLcmF1c3M8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz
LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUy
Zm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUy
YiUyYnpKaVh3UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h
cmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+
PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91
cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0
aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQx
YjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3
JTdjMSZhbXA7c2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJx
UjltNVdnQTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86
cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlz
dDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8
YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRo
JmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFi
MjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl
N2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUyYnFS
OW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLSZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u
PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su
Y29tLz91cmw9aHR0cCUzYSUyZiUyZm5hdC5zYWtpbXVyYS5vcmclMmYmYW1wO2RhdGE9MDElN2Mw
MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1
NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTZG
Vm1kTjdhZDBZem9ZS1NORiUyZkRPJTJmZkcyRUYxaGFqNWFPSGlNaWQ2VU1JJTNkIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL25hdC5zYWtpbXVyYS5v
cmcvPC9zcGFuPjwvYT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0
Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRh
PTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0
MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtz
ZGF0YT1iS3NFVkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJiRkpDUXJucTlhc3hSbzVIZTglM2QiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJy
Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhA
aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0
aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFu
JTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29m
dC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQx
YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9YktzRVZCVVhjNTI4eWFBTUxteWNYY0wz
MyUyYkZKQ1FybnE5YXN4Um81SGU4JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BN3PR0301MB123426487F3BB78AE49346C2A6B60BN3PR0301MB1234_--


From nobody Fri Mar 11 16:02:25 2016
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 785D312DDCC for ; Fri, 11 Mar 2016 16:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.411
X-Spam-Level: 
X-Spam-Status: No, score=0.411 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no 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 Cz8V29gVAHoX for ; Fri, 11 Mar 2016 16:02:20 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 2DF4012DDC2 for ; Fri, 11 Mar 2016 16:02:13 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id g203so164725348iof.2 for ; Fri, 11 Mar 2016 16:02:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wtU85/29HhmqYIxp/D0+A36WOSp3/0mtJetjX/M5+8U=; b=pDk9IE9VFUbqu5nmnR0tSWA6r3cJYXJYat4fsHEIkmosjQBmIl+2jlHZNVCRwOQyZL 9RRM4n0h6v1ww1aScl92hW/04i8FD9ygbqFa8r9c2EX1n6nYJksVVYJu5zBVVhauPK8I 6K44zg1JtReFf0OD8p6YTyaig6/fAwjt7ncho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wtU85/29HhmqYIxp/D0+A36WOSp3/0mtJetjX/M5+8U=; b=AdFNwfMRD0b1GEz+75T1ZSNEh4bsWsQgQl2buL+/2PpsN8WhFhOuS8aWOWX9s8jjkx aM7L098DVz6VAaXYlOfUBZV30h3YR0VMqfb0LamcIzHzMMUwwDI7cFWKJT4F2OohSJA5 xnyD40gsZUMWgcM4hCzDpKFz6jX7ta3NTpj9vy8n/9pCrVD8XMItjg8fLe28rs1559CE JUeOeSCSPwMpqqlIwHle+lwbS5lTlq8VkTBt1u0C8P0PUMdp/IOs54vd4W878gh8iSeM Kvq6MDjxgQ7fyjTkwapAyCYbPi9YE6NdgOFfx70Y8DiAxtCSxvjF/wI70NYr19znhwJo BBLw==
X-Gm-Message-State: AD7BkJLG4rIbtj5llaD+iOouvLis6xFNwPcGfkYV6Sad/a1vaqMo1y8g7yeI9pr4x4OPAvqwZ88M0yTBqQs+Lw4a
X-Received: by 10.107.5.149 with SMTP id 143mr15909057iof.129.1457740932414; Fri, 11 Mar 2016 16:02:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 11 Mar 2016 16:01:42 -0800 (PST)
In-Reply-To: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>    
From: Brian Campbell 
Date: Fri, 11 Mar 2016 17:01:42 -0700
Message-ID: 
To: Anthony Nadalin 
Content-Type: multipart/alternative; boundary=001a113eecee73a075052dcec28c
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 00:02:23 -0000

--001a113eecee73a075052dcec28c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good to see you are following along with what's happened.

On Fri, Mar 11, 2016 at 5:00 PM, Anthony Nadalin 
wrote:

> Sorry but not true, this started out as =E2=80=9Cdiscovery=E2=80=9D and n=
ow it=E2=80=99s not
>
>
>
> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com]
> *Sent:* Friday, March 11, 2016 3:59 PM
> *To:* Anthony Nadalin 
> *Cc:* John Bradley ; oauth 
>
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> That *is* the scope of the current document, which a majority of folks
> have agreed with. I was reiterating that the name of the document should
> reflect its content, something else that has been widely agreed with.
>
>
>
> On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin 
> wrote:
>
> Disagree, what purpose is this activity solving then, it was being pushed
> as what was need to solve the Mix-up, but that is not true. So now you ar=
e
> suggesting a change in scope and not dealing with discovery.
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, March 11, 2016 3:11 PM
> *To:* John Bradley 
>
>
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> I tend to agree with John that addressing the concerns Phil raises should
> be part of (extension to) the core protocol.  And that those kinds of
> concerns don't manifest in the way OAuth is typically deployed now.
>
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata"
> should keep it's scope to the publishing of authorization server metadata=
.
> The act of doing discovery is beyond its scope and so is trying to preven=
t
> a client from presenting a token to someplace it shouldn't.
>
>
>
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley  wrote:
>
> Inline
>
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
> wrote:
>
>
>
> John
>
>
>
> In many case all the AS has to check is the domain name component to chec=
k
> for mitm.
>
>
>
> POP and the other solns are dramatically more complex than a simple check=
.
>
>
>
> I was proposing ding that check at the authorization endpoint or token
> endpoint as part of AT issuance.
>
>
>
> It is up to the AS how much of the path to validate and or put in the aud
> or dst.
>
>
>
>
>
>
>
> I see it as part of the discovery(bad name aside) problem because we
> discussed that if a client finds app.example.com
> 
> how do we ensure it gets a complete set of oauth endpoints as a valid set
> of endpoints--that a hacker has not inserted one of their own endpoints.
> The most important endpoint to get right is ensuring the resource server
> (and optionally the path) is the correct one. We can't really define
> resource discovery but we can validate it to some degree.
>
>
>
> I think it is part of core protocol security and should/must not require
> discovery.
>
>
>
> What is app.example.com
> 
> ?
>
>
>
> If it is the resource then the client would be preconfigured for it=E2=80=
=99s AS
> out of band or optionally would do discovery on the issuer uri that you
> admit needs to be configured out of band some way (note discovery is
> optional)
>
>
>
> In the AS meta-data draft it would do a get on a well known file that
> would have configuration for the AS, but not the RS, though some API may
> optionally list a API endpoint like connect has.
>
>
>
> The client then makes a authorization request (after registering out of
> band or dynamically).
>
> As part of the authorization request for implicit it could provide the
> aud/dst that it wants the token for.
>
> If that is not sent then the aud/dst are implicit in the scopes.
>
>
>
> The client gets back a AT with a list of scopes granted, aud/dst allowed
> and time to live for the token (one extra thing returned)
>
>
>
> This doesn=E2=80=99t require any discovery (yes there is a optional AS me=
ta-data
> discovery but not required)
>
>
>
> I prefer to fix the RS man in the middle issue as part of the protocol an=
d
> not part of discovery that should remain optional.
>
>
>
> I honestly don=E2=80=99t quite know how the client learns about this bad =
RS and
> starts talking to it, so this may be a solution to a problem that doesn=
=E2=80=99t
> yet exist.   The one place this is posable is if the registration for the
> client is compromised.  However we are discussing other mitigations for
> that that also explicitly do not require discovery.
>
>
>
> John B.
>
>
>
>
>
> I am not stuck on webfinger or well-known. Because this is config maybe i=
t
> should be an oauth endpoint.
>
> Phil
>
>
> On Mar 11, 2016, at 06:51, John Bradley  wrote:
>
> I think Phil is proposing something different.   Should the client send a
> token from this AS to that RS.
>
>
>
> His goal is to prevent man in the middle attacks where a bad RS gets a AT
> that is audianced to/accepted by another RS.
>
>
>
> That is separate from the question of if a RS accepts tokens from a good
> AS.   A bad AS would always say yes.
>
>
>
> We need to be careful of what if anything the RS provides to the client a=
s
> meta-data without validation.
>
>
>
> Currently the client can provide a list of scopes required to get access.
>   I personally feel it would be useful to also include in the
> unauthenticated error response an indication of what API the resource
> supports.  Say =E2=80=9Cscim2=E2=80=9D as an example.   I don=E2=80=99t t=
hink adding that is
> however a high priority as most if all clients know what API they expect.
> It might be useful if at some point in the future if a client were to be
> given a RS URI it could check to see if it is a protocol that it supports
> before bothering with OAuth.    I expect that a lot of people will want
> that left to the API definition.   I think we can talk about it but rate
> this low priority.
>
>
>
> I agree that the RS giving out a list of AS that it trusts is a generally
> bad idea.  I hope that is not on the table.
>
>
>
> I don=E2=80=99t think that preventing a client from sending a token to th=
e wrong
> RS is part of a AS meta-data discovery problem.
>
>
>
> I do however think that it is important.
>
>
>
> We have been discussing this as a separate problem to AS meta-data
> discovery where the endpoints of the AS and it=E2=80=99s configuration ar=
e
> discovery.   Sorry for perhaps stating the obvious, but the RS is
> explicitly not part of the AS in OAuth 2.   Starting in WAP that was a co=
re
> principal.
>
>
>
> So we have a number of options to address the RS token leakage via MiTM
> attacks.
>
>
>
> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS
> or Token binding they cannot be replayed.  Signed messages where the
> signing covers the RS Host and path components,  also would work.
>
>
>
> 2) Have the AS audience restrict the resources the AT is good at. (AT
> should be doing that now)
>
> In the token response include the list of audience/s the token is
> presentable at.  The client would throw an error if the RS it intends to
> send the token to is not on the list.   The RS the token is good at might
> change based on scopes, client_id and resource owner.   This is the place
> where all of that comes together.   In some cases the RS and AS might not
> have a pre-established relationship.   The client should send the RS base
> URI to the AS as part of the request.  The AS can use that to audience
> restrict the AT and issue the AT or refuse to issue the AT based on polic=
y.
>
> It can also use the audience in the request to down audience the AT if th=
e
> default is to have multiple audiences.    We may want to use a term other
> than audience for this like resource or destination.  It is a audience bu=
t
> that term might confuse people with AT.
>
>
>
> We did talk about breaking audience out of POP key distribution, and Bria=
n
> Campbell did a draft
> https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt
> .
>
>
>
>
> To do this we could take dst4jwt and add another spec that adds a new dst
> parameter to the token and authorization endpoints requests That would be=
 a
> space separated list of dst values.  and in the response from the token
> endpoint would be a JSON array of dst values.
>
>
>
> 3) Have the AS always return all the list of all RS the token can be used
> at (basically Nat's link relationship proposal).  It needs a way to handl=
e
>
> down destinationing of AT and to allow for un-configured RS that it might
> issue a token for.  So could be combined with dst from 2.  Basically
> returning the acceptable destinations as link headers vs JS in the respon=
se
> is mostly a style issue that other people can bike shed.
>
>
>
>
>
> 4) Trying to add all the RS to the AS discovery document.  This seems
> impractical as there would be multiple protocols and doesn=E2=80=99t addr=
ess
> un-configured RS.
>
>
>
> 5) Some new AS endpoint that the client could introspect the RS URI and
> get back metadata about if the client should send tokens there.
>
>     A couple of problems with this.  The first is that it would not
> support un-configured RS unless you add dst to the token and authorizatio=
n
> endpoints.   The other is that the introspection endpoint doesn=E2=80=99t=
 have the
> context of the RO and client_id unless you also pass the code/RT and
> client_id, and probably client credentials.    Basically this is trying t=
o
> introspect the AT to determine the audiance/dst.   By the time you build =
a
> new introspection endpoint securely it is going to look like the token
> endpoint with a bit more meta data about the token beyond expiry and scop=
es.
>
>
>
>
>
> I think we should go a head with the renamed "OAuth 2.0 Authorization
> Server Discovery Metadata=E2=80=9D
>
> I am also fine with making the default document 'openid-configuration=E2=
=80=99  as
> long as we allow for protocol specific variation so that SCIM2 could defi=
ne
> a file name.    If people want we could do a API  to file name registry s=
o
> that protocol specific ones can be defined.
>
>
>
> We are all-ready working on option 1 to secure AT, we need a spec like I
> propose in 2 for bearer tokens.  We can add one request parameter and a b=
it
> more token meta-data to the token response and that takes care of the
> problem.   Honestly we probably should have separated scope and destinati=
on
> in the first place and returned both dst and scope in the response all
> along, so this is update that is consistent with the eisting architecture
> of OAuth 2.
>
>
>
> Lets keep the two issues separate.
>
>
>
> John B.
>
>
>
>
>
>
>
>
>
> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin 
> wrote:
>
>
>
> The relationship between AS and RS need to be scoped to =E2=80=9Cdoes thi=
s RS
> accept tokens from this AS=E2=80=9D as a list is too much information tha=
t could be
> used in the wrong way
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O=
n
> Behalf Of *Nat Sakimura
> *Sent:* Thursday, March 10, 2016 6:25 PM
> *To:* Phil Hunt (IDM) 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> Phil,
>
>
>
> Right. So what my conditional approvals (11 conditions in total) said was
> to drop the word "discovery" from everywhere. This is not a discovery spe=
c.
> This is a configuration lookup spec as you correctly points out. So, I am
> with you here.
>
>
>
> Also, my 2nd conditiion is essentially saying to drop section 3.
>
>
>
> One thing that I overlooked and am with you is that we need to be able to
> express the AS-RS relationships. I have been preaching this in the other
> thread for so many times as you know so I thought I pointed it out, but
> missed apparently in my previous comment. So, I would add my 12th
> condition:
>
>
>
> 12. A way to express a list of valid RSs for this AS needs to be added to
> section 2.
>
>
>
> Best,
>
>
>
> Nat
>
>
>
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>
> I strongly oppose. 2 major issues.
>
>
>
> This is not service discovery this is configuration lookup. The client
> must have already discovered the oauth issuer uri and the resource uri.
>
>
>
> The objective was to provide a method to ensure the client has a valid se=
t
> of endpoints to prevent mitm of endpoints like the token endpoint to the
> resource server.
>
>
>
> The draft does not address the issue of a client being given a bad
> endpoint for an rs. What we end up with is a promiscuous authz service
> giving out tokens to an unwitting client.
>
> Phil
>
>
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
> wrote:
>
> +1 to move forward with these
>
> On 10/03/16 17:35, Brian Campbell wrote:
>
> +1
>
>
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg  <=
roland.hedberg@umu.se>
>
> wrote:
>
>
>
> I support this document being moved forward with these two changes:
>
>
>
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metada=
ta=E2=80=9D as
>
> proposed by Brian and
>
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 in=
stead of
>
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
>
>
>
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
> :
>
>
>
> Hi all,
>
>
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery
>
> specification:
>
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 
>
>
>
> Since this document was only adopted recently we are running this last
>
> call for **3 weeks**.
>
>
>
> Please have your comments in no later than March 10th.
>
>
>
> Ciao
>
> Hannes & Derek
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
>
> =E2=80=94 Roland
>
>
>
> =E2=80=9DEverybody should be quiet near a little stream and listen."
>
> >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
>
>
>
>
>
> _______________________________________________
>
> 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 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
>
>
>
> --
>
> Nat Sakimura (=3Dnat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> 
> @_nat_en
>
> _______________________________________________
> 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
> 
>
>
>
>
>

--001a113eecee73a075052dcec28c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Good to see you are following along with what's happen=
ed. 

    On =
Fri, Mar 11, 2016 at 5:00 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
    






    

    

    Sorry but not true, this started out as =E2=80=9Cdi=
scovery=E2=80=9D and now it=E2=80=99s not
    

    =C2=
=A0
    

    From: Brian Campbell [mailto:bcampbell@pingiden=
tity.com]

    
Sent: Friday, March 11, 2016 3:59 PM
    
To: Anthony Nadalin <tonynad@microsoft.com>
    
Cc: John Bradley <ve7jtb@ve7jtb.com>; oauth <oauth@ietf.org>

    
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discove=
ry
    

    =C2=A0
    

    

    That *is* the scope of the current document, which a=
 majority of folks have agreed with. I was reiterating that the name of the=
 document should reflect its content, something else that has been widely a=
greed with.=C2=A0

    

    

    

    =C2=A0
    

    

    On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin <=
;tonynad@microso=
ft.com> wrote:
    

    

    

    

    Disagree, what purpose is this activity solving the=
n, it was being pushed as what was need to solve the Mix-up, but
 that is not true. So now you are suggesting a change in scope and not deal=
ing with discovery.
    

    <=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">=
=C2=A0
    

    From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell
    
Sent: Friday, March 11, 2016 3:11 PM
    
To: John Bradley <ve7jtb@ve7jtb.com>
    

    

    


    
Cc: oauth <oa=
uth@ietf.org>
    
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discove=
ry
    

    

    

    

    

    =C2=A0
    

    

    I tend to agree with =
John that addressing the concerns Phil raises should be part of (extension =
to) the core protocol.=C2=A0 And that those kinds of concerns don't man=
ifest in the way OAuth
 is typically deployed now. 
    

    
The hopefully soon to be named "OAuth 2.0 Authorization Server Metadat=
a" should keep it's scope to the publishing of authorization serve=
r metadata. The act of doing discovery is beyond its scope and so is trying=
 to prevent a client from presenting a token to
 someplace it shouldn't. 
    

    

    

    =C2=A0
    

    

    On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7jtb@ve7jtb.com&=
gt; wrote:
    

    

    

    Inline
    

    

    

    

    On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) <phil.hunt@oracle.co=
m> wrote:
    

    

    =C2=A0
    

    

    

    

    John
    

    

    

    =C2=A0
    

    

    

    In many case all the AS has to check is the domain n=
ame component to check for mitm.=C2=A0
    

    

    

    =C2=A0
    

    

    

    POP and the other solns are dramatically more comple=
x than a simple check.=C2=A0
    

    

    

    

    

    

    =C2=A0
    

    

    I was proposing ding that check at the authorization=
 endpoint or token endpoint as part of AT issuance.=C2=A0
    

    

    

    =C2=A0
    

    

    

    It is up to the AS how much of the path to validate =
and or put in the aud or dst.=C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

    

    

    

    =C2=A0
    

    

    

    I see it as part of the discovery(bad name aside) pr=
oblem because we discussed that if a client finds

app.example.com how do we ensure it gets a complete set of oauth endpoi=
nts as a valid set of endpoints--that a hacker has not inserted one of thei=
r own endpoints. The most important endpoint to get right is ensuring the r=
esource server (and optionally the
 path) is the correct one. We can't really define resource discovery bu=
t we can validate it to some degree.=C2=A0
    

    

    

    =C2=A0
    

    

    

    

    

    

    I think it is part of core protocol security and sho=
uld/must not require discovery.=C2=A0
    

    

    

    =C2=A0
    

    

    

    What is

app.example.com ?=C2=A0
    

    

    

    =C2=A0
    

    

    

    If it is the resource then the client would be preco=
nfigured for it=E2=80=99s AS out of band or optionally would do discovery o=
n the issuer uri that you admit needs to be configured out
 of band some way (note discovery is optional)
    

    

    

    =C2=A0
    

    

    

    In the AS meta-data draft it would do a get on a wel=
l known file that would have configuration for the AS, but not the RS, thou=
gh some API may optionally list a API endpoint like
 connect has. =C2=A0
    

    

    

    =C2=A0
    

    

    

    The client then makes a authorization request (after=
 registering out of band or dynamically). =C2=A0
    

    

    

    As part of the authorization request for implicit it=
 could provide the aud/dst that it wants the token for.
    

    

    

    If that is not sent then the aud/dst are implicit in=
 the scopes.
    

    

    

    =C2=A0
    

    

    

    The client gets back a AT with a list of scopes gran=
ted, aud/dst allowed and time to live for the token (one extra thing return=
ed)
    

    

    

    =C2=A0
    

    

    

    This doesn=E2=80=99t require any discovery (yes ther=
e is a optional AS meta-data discovery but not required)
    

    

    

    =C2=A0
    

    

    

    I prefer to fix the RS man in the middle issue as pa=
rt of the protocol and not part of discovery that should remain optional.
    

    

    

    =C2=A0
    

    

    

    I honestly don=E2=80=99t quite know how the client l=
earns about this bad RS and starts talking to it, so this may be a solution=
 to a problem that doesn=E2=80=99t yet exist. =C2=A0 The one place this
 is posable is if the registration for the client is compromised.=C2=A0 How=
ever we are discussing other mitigations for that that also explicitly do n=
ot require discovery.
    

    

    

    =C2=A0
    

    

    

    John B.
    

    

    

    

    

    =C2=A0
    

    

    =C2=A0<=
/p>

    

    

    

    

    I am not stuck on webfinger or well-known. Because t=
his is config maybe it should be an oauth endpoint.=C2=A0
    

    
Phil
    

    

    


    
On Mar 11, 2016, at 06:51, John Bradley <ve7jtb@ve7jtb.com> wrote:
    

    

    

    

    I think Phil is proposing something different. =C2=
=A0 Should the client send a token from this AS to that RS. =C2=A0
    

    

    =C2=A0
    

    

    

    His goal is to prevent man in the middle attacks whe=
re a bad RS gets a AT that is audianced to/accepted by another RS.
    

    

    

    =C2=A0
    

    

    

    That is separate from the question of if a RS accept=
s tokens from a good AS. =C2=A0 A bad AS would always say yes.
    

    

    

    =C2=A0
    

    

    

    We need to be careful of what if anything the RS pro=
vides to the client as meta-data without validation.
    

    

    

    =C2=A0
    

    

    

    Currently the client can provide a list of scopes re=
quired to get access. =C2=A0 I personally feel it would be useful to also i=
nclude in the unauthenticated error response an indication
 of what API the resource supports.=C2=A0 Say =E2=80=9Cscim2=E2=80=9D as an=
 example. =C2=A0 I don=E2=80=99t think adding that is however a high priori=
ty as most if all clients know what API they expect. =C2=A0 It might be use=
ful if at some point in the future if a client were to be given a RS URI
 it could check to see if it is a protocol that it supports before botherin=
g with OAuth. =C2=A0 =C2=A0I expect that a lot of people will want that lef=
t to the API definition. =C2=A0 I think we can talk about it but rate this =
low priority.
    

    

    

    =C2=A0
    

    

    

    I agree that the RS giving out a list of AS that it =
trusts is a generally bad idea.=C2=A0 I hope that is not on the table.
    

    

    

    =C2=A0
    

    

    

    I don=E2=80=99t think that preventing a client from =
sending a token to the wrong RS is part of a AS meta-data discovery problem=
.
    

    

    

    =C2=A0
    

    

    

    I do however think that it is important.
    

    

    

    =C2=A0
    

    

    

    We have been discussing this as a separate problem t=
o AS meta-data discovery where the endpoints of the AS and it=E2=80=99s con=
figuration are discovery. =C2=A0 Sorry for perhaps stating the
 obvious, but the RS is explicitly not part of the AS in OAuth 2. =C2=A0 St=
arting in WAP that was a core principal.
    

    

    

    =C2=A0
    

    

    

    So we have a number of options to address the RS tok=
en leakage via MiTM attacks.
    

    

    

    =C2=A0
    

    

    

    1) PoP bound tokens.=C2=A0 If they are bound to the =
TLS channel by mutual TLS or Token binding they cannot be replayed.=C2=A0 S=
igned messages where the signing covers the RS Host and path
 components, =C2=A0also would work.
    

    

    

    =C2=A0
    

    

    

    2) Have the AS audience restrict the resources the A=
T is good at. (AT should be doing that now)=C2=A0
    

    

    

    In the token response include the list of audience/s=
 the token is presentable at.=C2=A0 The client would throw an error if the =
RS it intends to send the token to is not on the list.
 =C2=A0 The RS the token is good at might change based on scopes, client_id=
 and resource owner. =C2=A0 This is the place where all of that comes toget=
her. =C2=A0 In some cases the RS and AS might not have a pre-established re=
lationship. =C2=A0 The client should send the RS base
 URI to the AS as part of the request.=C2=A0 The AS can use that to audienc=
e restrict the AT and issue the AT or refuse to issue the AT based on polic=
y.
    

    

    

    It can also use the audience in the request to down =
audience the AT if the default is to have multiple audiences. =C2=A0 =C2=A0=
We may want to use a term other than audience for this like
 resource or destination.=C2=A0 It is a audience but that term might confus=
e people with AT.
    

    

    

    =C2=A0
    

    

    

    We did talk about breaking audience out of POP key d=
istribution, and Brian Campbell did a draft=C2=A0https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt.
 =C2=A0=C2=A0
    

    

    

    =C2=A0
    

    

    

    To do this we could take dst4jwt and add another spe=
c that adds a new dst parameter to the token and authorization endpoints re=
quests That would be a space separated list of dst
 values. =C2=A0and in the response from the token endpoint would be a JSON =
array of dst values.
    

    

    

    =C2=A0
    

    

    

    3) Have the AS always return all the list of all RS =
the token can be used at (basically Nat's link relationship proposal).=
=C2=A0 It needs a way to handle=C2=A0
    

    

    

    down destinationing of AT and to allow for un-config=
ured RS that it might issue a token for.=C2=A0 So could be combined with ds=
t from 2.=C2=A0 Basically returning the acceptable destinations
 as link headers vs JS in the response is mostly a style issue that other p=
eople can bike shed.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    4) Trying to add all the RS to the AS discovery docu=
ment.=C2=A0 This seems impractical as there would be multiple protocols and=
 doesn=E2=80=99t address un-configured RS.
    

    

    

    =C2=A0
    

    

    

    5) Some new AS endpoint that the client could intros=
pect the RS URI and get back metadata about if the client should send token=
s there.
    

    

    

    =C2=A0 =C2=A0 A couple of problems with this.=C2=A0 =
The first is that it would not support un-configured RS unless you add dst =
to the token and authorization endpoints. =C2=A0 The other is that the
 introspection endpoint doesn=E2=80=99t have the context of the RO and clie=
nt_id unless you also pass the code/RT and client_id, and probably client c=
redentials. =C2=A0 =C2=A0Basically this is trying to introspect the AT to d=
etermine the audiance/dst. =C2=A0 By the time you build
 a new introspection endpoint securely it is going to look like the token e=
ndpoint with a bit more meta data about the token beyond expiry and scopes.=

    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    I think we should go a head with the renamed "O=
Auth 2.0 Authorization Server Discovery Metadata=E2=80=9D=C2=A0
    

    

    

    I am also fine with making the default document '=
;openid-configuration=E2=80=99 =C2=A0as long as we allow for protocol speci=
fic variation so that SCIM2 could define a file name. =C2=A0 =C2=A0If peopl=
e
 want we could do a API =C2=A0to file name registry so that protocol specif=
ic ones can be defined.
    

    

    

    =C2=A0
    

    

    

    We are all-ready working on option 1 to secure AT, w=
e need a spec like I propose in 2 for bearer tokens.=C2=A0 We can add one r=
equest parameter and a bit more token meta-data to the
 token response and that takes care of the problem. =C2=A0 Honestly we prob=
ably should have separated scope and destination in the first place and ret=
urned both dst and scope in the response all along, so this is update that =
is consistent with the eisting architecture
 of OAuth 2.
    

    

    

    =C2=A0
    

    

    

    Lets keep the two issues separate.
    

    

    

    =C2=A0
    

    

    

    John B.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

    

    

    On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tonynad@microsoft.=
com> wrote:
    

    

    =C2=A0
    

    

    

    

    The relationship between AS and RS need to be scope=
d to =E2=80=9Cdoes this RS accept tokens from this AS=E2=80=9D as a list is=
 too
 much information that could be used in the wrong way<=
/p>

    


    

    From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org=
]=C2=A0On
 Behalf Of=C2=A0Nat Sakimura
    
Sent:=C2=A0Thursday, March 10, 2016 6:25 PM
    
To:=C2=A0Phil Hunt (IDM) <phil.hunt@oracle.com>
    
Cc:=C2=A0oauth <oauth@ietf.org>
    
Subject:=C2=A0Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Di=
scovery
    

    

    

    =C2=A0
    

    

    

    

    Phil,=C2=A0
    

    

    

    

    =C2=A0
    

    

    

    

    

    Right. So what my conditional approvals (11 conditio=
ns in total) said was to drop the word "discovery" from everywher=
e. This is not a discovery spec. This is a configuration lookup
 spec as you correctly points out. So, I am with you here.=C2=A0<=
/u>
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    Also, my 2nd conditiion is essentially saying to dro=
p section 3.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    One thing that I overlooked and am with you is that =
we need to be able to express the AS-RS relationships. I have been preachin=
g this in the other thread for so many times as you
 know so I thought I pointed it out, but missed apparently in my previous c=
omment. So, I would add my 12th condition:=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    12. A way to express a list of valid RSs for this AS=
 needs to be added to section 2.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    Best,=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    Nat
    

    

    

    

    

    

    =C2=A0
    

    

    

    

    2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
    

    

    

    

    

    

    I strongly oppose. 2 major issues.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    This is not service discovery this is configuration =
lookup. The client must have already discovered the oauth issuer uri and th=
e resource uri.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    The objective was to provide a method to ensure the =
client has a valid set of endpoints to prevent mitm of endpoints like the t=
oken endpoint to the resource server.=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    

    

    

    The draft does not address the issue of a client bei=
ng given a bad endpoint for an rs. What we end up with is a promiscuous aut=
hz service giving out tokens to an unwitting client.=C2=A0
    

    
Phil
    

    

    

    

    

    


    
On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@c=
onnect2id.com> wrote:
    

    

    

    

    +1 to move forward wi=
th these
    

    

    

    On 10/03/16 17:35, Brian Campbell wrote:
    

    

    

    

    +1
    

    =C2=A0
    

    On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <rolan=
d.hedberg@umu.se>
    

    wrote:
    

    =C2=A0
    

    

    I support this document being moved forward with these two changes:=

    

    =C2=A0
    

    - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Met=
adata=E2=80=9D as
    

    proposed by Brian and
    

    - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99=
 instead of
    

    =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
    

    =C2=A0
    

    

    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <han=
nes.tschofenig@gmx.net
    

    :
    

    =C2=A0
    

    Hi all,
    

    =C2=A0
    

    This is a Last Call for comments on the=C2=A0 OAuth 2.0 Discovery
    

    

    specification:
    

    

    https:=
//tools.ietf.org/html/draft-ietf-oauth-discovery-01
    

    =C2=A0
    

    Since this document was only adopted recently we are running this last=

    

    call for **3 weeks**.
    

    =C2=A0
    

    Please have your comments in no later than March 10th.

    =C2=A0
    

    Ciao
    

    Hannes & Derek
    

    =C2=A0
    

    _______________________________________________
    

    OAuth mailing list
    

    OAuth@ietf.org
    

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

    

    =E2=80=94 Roland
    

    =C2=A0
    

    =E2=80=9DEverybody should be quiet near a little stream and listen.&qu=
ot;
    

    >From =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
    

    =C2=A0
    

    =C2=A0
    

    _______________________________________________
    

    OAuth mailing list
    

    OAuth@ietf.org
    

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

    =C2=A0
    

    =C2=A0
    

    

    =C2=A0<=
/p>

    _______________________________________________
    

    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
    

    

    

    


    

    

    

    

    

    

    =C2=A0
    

    

    

    

    --=C2=A0
    

    

    

    

    Nat Sakimura (=3Dnat)
    

    

    

    

    Chairman, OpenID Foundation
    
http://nat.sakimura.org/
    
@_nat_en
    

    

    

    

    

    

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

    

    

    

    =C2=A0
    

    

    

    

    

    

    

    

    

    

    =C2=A0
    

    


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

    

    

    =C2=A0
    

    

    

    

    

    

    

    

    =C2=A0
    

    

    

    



    

--001a113eecee73a075052dcec28c--


From nobody Fri Mar 11 19:02:30 2016
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 A70EC12D554 for ; Fri, 11 Mar 2016 19:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 B8aP2niGKrr9 for ; Fri, 11 Mar 2016 19:02:28 -0800 (PST)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 E3AA712DAEE for ; Fri, 11 Mar 2016 19:02:27 -0800 (PST)
Received: by mail-lb0-x231.google.com with SMTP id k15so180161576lbg.0 for ; Fri, 11 Mar 2016 19:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:cc; bh=GqwmB+zV42lQWJTDiGZ+mQvUVMpB7dvDXyAs9Wf+Iu8=; b=DP6CCEfPPtY4gNaSPGb1R/PuZuBmeOszLdjBS5UUnfNAyiu4dLUKP0MBz3xjYscwHw bVCL1WMq5CpeelqpxJRRYJER+QaciWFvub2ZsH9l/aotlGe+72fFydiwMaJkh5bRVC+/ oNw89fF+NoGWOvMzSyTXz0JTSa+iqT060k4WFjoYb7eTSLNyYpBKjhdl1wTE1jc+95Od uP3hTdVo69aK669+h2K2QXwYe5/uTPhRrKpPMOYgyFoqGyxCDuM8ZyztM6OlcmS4/hoI zAE0LXAoRz+XYZ7Q9diEI6TBC+6GEP0ftj3peX2RpkUhQwOQVo9SdDCZpyN46/aop7Td mzig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=GqwmB+zV42lQWJTDiGZ+mQvUVMpB7dvDXyAs9Wf+Iu8=; b=R6U5C5VNz91yVPjLV99YkUr6iuaEEIjS5QcA+7zCAQoWpazmDMtlnlXLDn+J9o8NPt zltr06hJgcilCTQ4WA5utEghmAjweDo+UXs4jAc/Eyp9fpGN2JNbToQ+RmO+TZKMN3is n+mWGssQO84fmykLKaT49aJ718kWCQhnSvbryoiel9TLVRYMtefyS6FS1H6H1vJPYYcL SocNqdmU3fem39Q+ZYKP/m6tU421vgx+TAQrFLzZCkzJB+f0LDhlogT4sr9xi49eaNYz 3HL3T71OXrLLfk/NmmPhSs8XRDrdec+OE7XjCMuP7xx4wwrGTEBpM2tF2OckiSDQWaHz qfuw==
X-Gm-Message-State: AD7BkJK4sfidbVEVcyILvY0/8QstULufSffnfRMNwzGEhrUeMbH8zUH9oz3TgASh5gWAA51idLEQBzjr1B78mQ==
MIME-Version: 1.0
X-Received: by 10.25.127.216 with SMTP id a207mr4677816lfd.116.1457751746045;  Fri, 11 Mar 2016 19:02:26 -0800 (PST)
Received: by 10.112.129.100 with HTTP; Fri, 11 Mar 2016 19:02:26 -0800 (PST)
Date: Sat, 12 Mar 2016 12:02:26 +0900
Message-ID: 
From: Takahiko Kawasaki 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ec4dafe7157052dd14693
Archived-At: 
Subject: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 03:02:29 -0000

--001a113ec4dafe7157052dd14693
Content-Type: text/plain; charset=UTF-8

Hello,

I have a question.

If there exist multiple authorization servers that can issue access tokens
for one resource server, when the resource server receives an access token
from a client application, as the first step, the resource server has to
determine which authorization server to use for access token introspection.

Is there any standard way to determine which authorization server to use?

There may be several ways, for example:

(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.

If there is a standard way, I'd like to know it.

Best Regards,
Takahiko Kawasaki

--001a113ec4dafe7157052dd14693
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Hello,
    I have a question.

    If there exist multiple authorization serv=
ers that can issue access tokens for one resource server, when the resource=
 server receives an access token from a client application, as the first st=
ep, the resource server has to determine which authorization server to use =
for access token introspection.

    Is there any standard way to d=
etermine which authorization server to use?

    There may be sever=
al ways, for example:

    (1) Embed information about the access t=
oken issuer in the access token.
    (2) Add a request parameter to id=
entify the access token issuer.
    (3) Separate protected resource en=
dpoints for each authorization server.

    If there is a standard =
way, I'd like to know it.

    Best Regards,
    Takahiko =
Kawasaki

    

--001a113ec4dafe7157052dd14693--


From nobody Sat Mar 12 08:06:34 2016
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 6938512D7AB for ; Sat, 12 Mar 2016 08:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.11
X-Spam-Level: *
X-Spam-Status: No, score=1.11 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 t2fzoFCpm3kq for ; Sat, 12 Mar 2016 08:06:29 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7926E12D774 for ; Sat, 12 Mar 2016 08:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vUAejFjnWlwE488Q/Jvpjv3rYBgXK23faGb0C2p1onM=; b=h692GGr07NLkq+kOXGB0h+ZfIILKvOcLoK80ErV0VhcaM96b13ZzXDvRsbatIfAEM+fXxKz2x71ySIgC5sErOilzeY+jV5UdD1jXuTcT5fqNv6AV++rME1XF9jmURWbII51wpm+HN3VQ2NoPl8puj7TQe2mBEqQL/XWAnDeBAPY=
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (TLS) id 15.1.427.16; Sat, 12 Mar 2016 16:06:10 +0000
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0427.020; Sat, 12 Mar 2016 16:06:08 +0000
From: Mike Jones 
To: Anthony Nadalin , Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH0aW6XIA1+zU6W/8nt5o9Vup9Sxh0AgAAqNQCAAAiJgIAAEaoAgACbQYCAAAvegIAAxNAAgAAF5wCAAA9jAIAAdkGAgAADv4CAAQpLsA==
Date: Sat, 12 Mar 2016 16:06:07 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.73.146.217]
x-ms-office365-filtering-correlation-id: a3351e34-46e3-46c8-d947-08d34a903907
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 5:/vRuS4HvI/lGJA2wk4CirRSNO4Xnu3brEe3OAISEY+EA86QJiQE1jk7yiZBfugzqmYzCW05mLReLgR7TvIvnlaJ3hTJQfiyTJJEm7rAIFvSArUVWlfxWGZZIXrOz1RXld6mDSQNM0/N3tnVZC6edwQ==; 24:ZoHupXZYi8vm/Gv8UZ3HONh4tbsgSw4XIhm9zG28Fc6ZOCIX0l8jSrKuuLKhpqbw9dkpDY22TSyWQGIFTa3rqtvPQlrg8ISCmIzYagqDs8M=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; 
x-forefront-prvs: 0879599414
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(53754006)(377454003)(377424004)(24454002)(1511001)(2421001)(19580395003)(19580405001)(87936001)(106116001)(10090500001)(93886004)(76576001)(66066001)(19617315012)(586003)(19609705001)(561944003)(1096002)(1220700001)(76176999)(54356999)(19625215002)(81166005)(102836003)(3846002)(74316001)(790700001)(5003600100002)(6116002)(2950100001)(2900100001)(50986999)(3660700001)(2561002)(5008740100001)(5001770100001)(4326007)(3280700002)(2906002)(92566002)(5005710100001)(99286002)(86362001)(10400500002)(15975445007)(122556002)(5002640100001)(19300405004)(189998001)(33656002)(10290500002)(77096005)(16236675004)(5004730100002)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645406DCCA1787C10F76B2BF5B60SN1PR0301MB1645_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2016 16:06:08.0058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 16:06:32 -0000

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

VGhlIGRyYWZ0IGVuYWJsZXMgZWFzeSBjb25maWd1cmF0aW9uIG9mIE9BdXRoIGNsaWVudHMgd2l0
aCBhbiBBUy4gIEZvciBpbnN0YW5jZSwgdGhlIE1pY3Jvc29mdCDigJxBREFM4oCdIE9BdXRoIGNs
aWVudCBzb2Z0d2FyZSB1c2VzIEFTIG1ldGFkYXRhIGluIHRoaXMgZm9ybWF0IGFzIGFuIGlucHV0
IGF0IGNsaWVudCBjb25maWd1cmF0aW9uIHRpbWUuDQoNCkFzIGEgc2lkZSBiZW5lZml0LCBoYXZp
bmcgdGhpcyBzdGFuZGFyZCBBUyBtZXRhZGF0YSBmb3JtYXQgYW5kIHJldHVybmluZyB0aGUgaXNz
dWVyIFVSTCBwZXIgdGhlIE1peC1VcCBNaXRpZ2F0aW9uIGRyYWZ0IHdpbGwgYWxzbyBlbmFibGUg
Y2xpZW50cyB0byB2YWxpZGF0ZSB0aGF0IHRoZXkgYXJlIHVzaW5nIGEgY29uc2lzdGVudCBzZXQg
b2YgQVMgZW5kcG9pbnRzIGFuZCBpbmZvcm1hdGlvbi4gIEJ1dCBldmVuIHdpdGhvdXQgdGhlIG1p
dGlnYXRpb24gYmVuZWZpdHMsIHRoZSBjbGllbnQgY29uZmlndXJhdGlvbiBiZW5lZml0IGlzIHRo
ZSBwcmltYXJ5IHJlYXNvbiBmb3IgdGhlIHNwZWNpZmljYXRpb24uDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy
b206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFu
dGhvbnkgTmFkYWxpbg0KU2VudDogRnJpZGF5LCBNYXJjaCAxMSwgMjAxNiAzOjI1IFBNDQpUbzog
QnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPjsgSm9obiBCcmFkbGV5
IDx2ZTdqdGJAdmU3anRiLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlz
Y292ZXJ5DQoNCkRpc2FncmVlLCB3aGF0IHB1cnBvc2UgaXMgdGhpcyBhY3Rpdml0eSBzb2x2aW5n
IHRoZW4sIGl0IHdhcyBiZWluZyBwdXNoZWQgYXMgd2hhdCB3YXMgbmVlZCB0byBzb2x2ZSB0aGUg
TWl4LXVwLCBidXQgdGhhdCBpcyBub3QgdHJ1ZS4gU28gbm93IHlvdSBhcmUgc3VnZ2VzdGluZyBh
IGNoYW5nZSBpbiBzY29wZSBhbmQgbm90IGRlYWxpbmcgd2l0aCBkaXNjb3ZlcnkuDQoNCkZyb206
IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFu
IENhbXBiZWxsDQpTZW50OiBGcmlkYXksIE1hcmNoIDExLCAyMDE2IDM6MTEgUE0NClRvOiBKb2hu
IEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpD
Yzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0
OiBSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlz
Y292ZXJ5DQoNCkkgdGVuZCB0byBhZ3JlZSB3aXRoIEpvaG4gdGhhdCBhZGRyZXNzaW5nIHRoZSBj
b25jZXJucyBQaGlsIHJhaXNlcyBzaG91bGQgYmUgcGFydCBvZiAoZXh0ZW5zaW9uIHRvKSB0aGUg
Y29yZSBwcm90b2NvbC4gIEFuZCB0aGF0IHRob3NlIGtpbmRzIG9mIGNvbmNlcm5zIGRvbid0IG1h
bmlmZXN0IGluIHRoZSB3YXkgT0F1dGggaXMgdHlwaWNhbGx5IGRlcGxveWVkIG5vdy4NCg0KVGhl
IGhvcGVmdWxseSBzb29uIHRvIGJlIG5hbWVkICJPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2
ZXIgTWV0YWRhdGEiIHNob3VsZCBrZWVwIGl0J3Mgc2NvcGUgdG8gdGhlIHB1Ymxpc2hpbmcgb2Yg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWV0YWRhdGEuIFRoZSBhY3Qgb2YgZG9pbmcgZGlzY292ZXJ5
IGlzIGJleW9uZCBpdHMgc2NvcGUgYW5kIHNvIGlzIHRyeWluZyB0byBwcmV2ZW50IGEgY2xpZW50
IGZyb20gcHJlc2VudGluZyBhIHRva2VuIHRvIHNvbWVwbGFjZSBpdCBzaG91bGRuJ3QuDQoNCk9u
IEZyaSwgTWFyIDExLCAyMDE2IGF0IDk6MDggQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0
Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpJbmxpbmUNCk9uIE1hciAx
MSwgMjAxNiwgYXQgMTI6MTMgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5j
b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkpvaG4NCg0KSW4gbWFu
eSBjYXNlIGFsbCB0aGUgQVMgaGFzIHRvIGNoZWNrIGlzIHRoZSBkb21haW4gbmFtZSBjb21wb25l
bnQgdG8gY2hlY2sgZm9yIG1pdG0uDQoNClBPUCBhbmQgdGhlIG90aGVyIHNvbG5zIGFyZSBkcmFt
YXRpY2FsbHkgbW9yZSBjb21wbGV4IHRoYW4gYSBzaW1wbGUgY2hlY2suDQoNCkkgd2FzIHByb3Bv
c2luZyBkaW5nIHRoYXQgY2hlY2sgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb3IgdG9r
ZW4gZW5kcG9pbnQgYXMgcGFydCBvZiBBVCBpc3N1YW5jZS4NCg0KSXQgaXMgdXAgdG8gdGhlIEFT
IGhvdyBtdWNoIG9mIHRoZSBwYXRoIHRvIHZhbGlkYXRlIGFuZCBvciBwdXQgaW4gdGhlIGF1ZCBv
ciBkc3QuDQoNCg0KDQpJIHNlZSBpdCBhcyBwYXJ0IG9mIHRoZSBkaXNjb3ZlcnkoYmFkIG5hbWUg
YXNpZGUpIHByb2JsZW0gYmVjYXVzZSB3ZSBkaXNjdXNzZWQgdGhhdCBpZiBhIGNsaWVudCBmaW5k
cyBhcHAuZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv
b2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5leGFtcGxlLmNvbSUyZiZkYXRhPTAxJTdjMDEl
N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMx
ZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWZpUzhmNjB5
cGlYaHlNMHFWVGVxbCUyYiUyYk96SDJ3Ym1FQ1FFN0o1VHRHUFFNJTNkPiBob3cgZG8gd2UgZW5z
dXJlIGl0IGdldHMgYSBjb21wbGV0ZSBzZXQgb2Ygb2F1dGggZW5kcG9pbnRzIGFzIGEgdmFsaWQg
c2V0IG9mIGVuZHBvaW50cy0tdGhhdCBhIGhhY2tlciBoYXMgbm90IGluc2VydGVkIG9uZSBvZiB0
aGVpciBvd24gZW5kcG9pbnRzLiBUaGUgbW9zdCBpbXBvcnRhbnQgZW5kcG9pbnQgdG8gZ2V0IHJp
Z2h0IGlzIGVuc3VyaW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgKGFuZCBvcHRpb25hbGx5IHRoZSBw
YXRoKSBpcyB0aGUgY29ycmVjdCBvbmUuIFdlIGNhbid0IHJlYWxseSBkZWZpbmUgcmVzb3VyY2Ug
ZGlzY292ZXJ5IGJ1dCB3ZSBjYW4gdmFsaWRhdGUgaXQgdG8gc29tZSBkZWdyZWUuDQoNCkkgdGhp
bmsgaXQgaXMgcGFydCBvZiBjb3JlIHByb3RvY29sIHNlY3VyaXR5IGFuZCBzaG91bGQvbXVzdCBu
b3QgcmVxdWlyZSBkaXNjb3ZlcnkuDQoNCldoYXQgaXMgYXBwLmV4YW1wbGUuY29tPGh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZh
cHAuZXhhbXBsZS5jb20mZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0
YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdjMSZzZGF0YT1qQXNaUWVDaEolMmJSMWxieUJvVkt3aGVJWWkzUGlXTHJxJTJi
eERMYnFVNnJ4ayUzZD4gPw0KDQpJZiBpdCBpcyB0aGUgcmVzb3VyY2UgdGhlbiB0aGUgY2xpZW50
IHdvdWxkIGJlIHByZWNvbmZpZ3VyZWQgZm9yIGl04oCZcyBBUyBvdXQgb2YgYmFuZCBvciBvcHRp
b25hbGx5IHdvdWxkIGRvIGRpc2NvdmVyeSBvbiB0aGUgaXNzdWVyIHVyaSB0aGF0IHlvdSBhZG1p
dCBuZWVkcyB0byBiZSBjb25maWd1cmVkIG91dCBvZiBiYW5kIHNvbWUgd2F5IChub3RlIGRpc2Nv
dmVyeSBpcyBvcHRpb25hbCkNCg0KSW4gdGhlIEFTIG1ldGEtZGF0YSBkcmFmdCBpdCB3b3VsZCBk
byBhIGdldCBvbiBhIHdlbGwga25vd24gZmlsZSB0aGF0IHdvdWxkIGhhdmUgY29uZmlndXJhdGlv
biBmb3IgdGhlIEFTLCBidXQgbm90IHRoZSBSUywgdGhvdWdoIHNvbWUgQVBJIG1heSBvcHRpb25h
bGx5IGxpc3QgYSBBUEkgZW5kcG9pbnQgbGlrZSBjb25uZWN0IGhhcy4NCg0KVGhlIGNsaWVudCB0
aGVuIG1ha2VzIGEgYXV0aG9yaXphdGlvbiByZXF1ZXN0IChhZnRlciByZWdpc3RlcmluZyBvdXQg
b2YgYmFuZCBvciBkeW5hbWljYWxseSkuDQpBcyBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHJl
cXVlc3QgZm9yIGltcGxpY2l0IGl0IGNvdWxkIHByb3ZpZGUgdGhlIGF1ZC9kc3QgdGhhdCBpdCB3
YW50cyB0aGUgdG9rZW4gZm9yLg0KSWYgdGhhdCBpcyBub3Qgc2VudCB0aGVuIHRoZSBhdWQvZHN0
IGFyZSBpbXBsaWNpdCBpbiB0aGUgc2NvcGVzLg0KDQpUaGUgY2xpZW50IGdldHMgYmFjayBhIEFU
IHdpdGggYSBsaXN0IG9mIHNjb3BlcyBncmFudGVkLCBhdWQvZHN0IGFsbG93ZWQgYW5kIHRpbWUg
dG8gbGl2ZSBmb3IgdGhlIHRva2VuIChvbmUgZXh0cmEgdGhpbmcgcmV0dXJuZWQpDQoNClRoaXMg
ZG9lc27igJl0IHJlcXVpcmUgYW55IGRpc2NvdmVyeSAoeWVzIHRoZXJlIGlzIGEgb3B0aW9uYWwg
QVMgbWV0YS1kYXRhIGRpc2NvdmVyeSBidXQgbm90IHJlcXVpcmVkKQ0KDQpJIHByZWZlciB0byBm
aXggdGhlIFJTIG1hbiBpbiB0aGUgbWlkZGxlIGlzc3VlIGFzIHBhcnQgb2YgdGhlIHByb3RvY29s
IGFuZCBub3QgcGFydCBvZiBkaXNjb3ZlcnkgdGhhdCBzaG91bGQgcmVtYWluIG9wdGlvbmFsLg0K
DQpJIGhvbmVzdGx5IGRvbuKAmXQgcXVpdGUga25vdyBob3cgdGhlIGNsaWVudCBsZWFybnMgYWJv
dXQgdGhpcyBiYWQgUlMgYW5kIHN0YXJ0cyB0YWxraW5nIHRvIGl0LCBzbyB0aGlzIG1heSBiZSBh
IHNvbHV0aW9uIHRvIGEgcHJvYmxlbSB0aGF0IGRvZXNu4oCZdCB5ZXQgZXhpc3QuICAgVGhlIG9u
ZSBwbGFjZSB0aGlzIGlzIHBvc2FibGUgaXMgaWYgdGhlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIGNs
aWVudCBpcyBjb21wcm9taXNlZC4gIEhvd2V2ZXIgd2UgYXJlIGRpc2N1c3Npbmcgb3RoZXIgbWl0
aWdhdGlvbnMgZm9yIHRoYXQgdGhhdCBhbHNvIGV4cGxpY2l0bHkgZG8gbm90IHJlcXVpcmUgZGlz
Y292ZXJ5Lg0KDQpKb2huIEIuDQoNCg0KSSBhbSBub3Qgc3R1Y2sgb24gd2ViZmluZ2VyIG9yIHdl
bGwta25vd24uIEJlY2F1c2UgdGhpcyBpcyBjb25maWcgbWF5YmUgaXQgc2hvdWxkIGJlIGFuIG9h
dXRoIGVuZHBvaW50Lg0KDQpQaGlsDQoNCk9uIE1hciAxMSwgMjAxNiwgYXQgMDY6NTEsIEpvaG4g
QnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3Jv
dGU6DQpJIHRoaW5rIFBoaWwgaXMgcHJvcG9zaW5nIHNvbWV0aGluZyBkaWZmZXJlbnQuICAgU2hv
dWxkIHRoZSBjbGllbnQgc2VuZCBhIHRva2VuIGZyb20gdGhpcyBBUyB0byB0aGF0IFJTLg0KDQpI
aXMgZ29hbCBpcyB0byBwcmV2ZW50IG1hbiBpbiB0aGUgbWlkZGxlIGF0dGFja3Mgd2hlcmUgYSBi
YWQgUlMgZ2V0cyBhIEFUIHRoYXQgaXMgYXVkaWFuY2VkIHRvL2FjY2VwdGVkIGJ5IGFub3RoZXIg
UlMuDQoNClRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUgcXVlc3Rpb24gb2YgaWYgYSBSUyBhY2Nl
cHRzIHRva2VucyBmcm9tIGEgZ29vZCBBUy4gICBBIGJhZCBBUyB3b3VsZCBhbHdheXMgc2F5IHll
cy4NCg0KV2UgbmVlZCB0byBiZSBjYXJlZnVsIG9mIHdoYXQgaWYgYW55dGhpbmcgdGhlIFJTIHBy
b3ZpZGVzIHRvIHRoZSBjbGllbnQgYXMgbWV0YS1kYXRhIHdpdGhvdXQgdmFsaWRhdGlvbi4NCg0K
Q3VycmVudGx5IHRoZSBjbGllbnQgY2FuIHByb3ZpZGUgYSBsaXN0IG9mIHNjb3BlcyByZXF1aXJl
ZCB0byBnZXQgYWNjZXNzLiAgIEkgcGVyc29uYWxseSBmZWVsIGl0IHdvdWxkIGJlIHVzZWZ1bCB0
byBhbHNvIGluY2x1ZGUgaW4gdGhlIHVuYXV0aGVudGljYXRlZCBlcnJvciByZXNwb25zZSBhbiBp
bmRpY2F0aW9uIG9mIHdoYXQgQVBJIHRoZSByZXNvdXJjZSBzdXBwb3J0cy4gIFNheSDigJxzY2lt
MuKAnSBhcyBhbiBleGFtcGxlLiAgIEkgZG9u4oCZdCB0aGluayBhZGRpbmcgdGhhdCBpcyBob3dl
dmVyIGEgaGlnaCBwcmlvcml0eSBhcyBtb3N0IGlmIGFsbCBjbGllbnRzIGtub3cgd2hhdCBBUEkg
dGhleSBleHBlY3QuICAgSXQgbWlnaHQgYmUgdXNlZnVsIGlmIGF0IHNvbWUgcG9pbnQgaW4gdGhl
IGZ1dHVyZSBpZiBhIGNsaWVudCB3ZXJlIHRvIGJlIGdpdmVuIGEgUlMgVVJJIGl0IGNvdWxkIGNo
ZWNrIHRvIHNlZSBpZiBpdCBpcyBhIHByb3RvY29sIHRoYXQgaXQgc3VwcG9ydHMgYmVmb3JlIGJv
dGhlcmluZyB3aXRoIE9BdXRoLiAgICBJIGV4cGVjdCB0aGF0IGEgbG90IG9mIHBlb3BsZSB3aWxs
IHdhbnQgdGhhdCBsZWZ0IHRvIHRoZSBBUEkgZGVmaW5pdGlvbi4gICBJIHRoaW5rIHdlIGNhbiB0
YWxrIGFib3V0IGl0IGJ1dCByYXRlIHRoaXMgbG93IHByaW9yaXR5Lg0KDQpJIGFncmVlIHRoYXQg
dGhlIFJTIGdpdmluZyBvdXQgYSBsaXN0IG9mIEFTIHRoYXQgaXQgdHJ1c3RzIGlzIGEgZ2VuZXJh
bGx5IGJhZCBpZGVhLiAgSSBob3BlIHRoYXQgaXMgbm90IG9uIHRoZSB0YWJsZS4NCg0KSSBkb27i
gJl0IHRoaW5rIHRoYXQgcHJldmVudGluZyBhIGNsaWVudCBmcm9tIHNlbmRpbmcgYSB0b2tlbiB0
byB0aGUgd3JvbmcgUlMgaXMgcGFydCBvZiBhIEFTIG1ldGEtZGF0YSBkaXNjb3ZlcnkgcHJvYmxl
bS4NCg0KSSBkbyBob3dldmVyIHRoaW5rIHRoYXQgaXQgaXMgaW1wb3J0YW50Lg0KDQpXZSBoYXZl
IGJlZW4gZGlzY3Vzc2luZyB0aGlzIGFzIGEgc2VwYXJhdGUgcHJvYmxlbSB0byBBUyBtZXRhLWRh
dGEgZGlzY292ZXJ5IHdoZXJlIHRoZSBlbmRwb2ludHMgb2YgdGhlIEFTIGFuZCBpdOKAmXMgY29u
ZmlndXJhdGlvbiBhcmUgZGlzY292ZXJ5LiAgIFNvcnJ5IGZvciBwZXJoYXBzIHN0YXRpbmcgdGhl
IG9idmlvdXMsIGJ1dCB0aGUgUlMgaXMgZXhwbGljaXRseSBub3QgcGFydCBvZiB0aGUgQVMgaW4g
T0F1dGggMi4gICBTdGFydGluZyBpbiBXQVAgdGhhdCB3YXMgYSBjb3JlIHByaW5jaXBhbC4NCg0K
U28gd2UgaGF2ZSBhIG51bWJlciBvZiBvcHRpb25zIHRvIGFkZHJlc3MgdGhlIFJTIHRva2VuIGxl
YWthZ2UgdmlhIE1pVE0gYXR0YWNrcy4NCg0KMSkgUG9QIGJvdW5kIHRva2Vucy4gIElmIHRoZXkg
YXJlIGJvdW5kIHRvIHRoZSBUTFMgY2hhbm5lbCBieSBtdXR1YWwgVExTIG9yIFRva2VuIGJpbmRp
bmcgdGhleSBjYW5ub3QgYmUgcmVwbGF5ZWQuICBTaWduZWQgbWVzc2FnZXMgd2hlcmUgdGhlIHNp
Z25pbmcgY292ZXJzIHRoZSBSUyBIb3N0IGFuZCBwYXRoIGNvbXBvbmVudHMsICBhbHNvIHdvdWxk
IHdvcmsuDQoNCjIpIEhhdmUgdGhlIEFTIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSByZXNvdXJjZXMg
dGhlIEFUIGlzIGdvb2QgYXQuIChBVCBzaG91bGQgYmUgZG9pbmcgdGhhdCBub3cpDQpJbiB0aGUg
dG9rZW4gcmVzcG9uc2UgaW5jbHVkZSB0aGUgbGlzdCBvZiBhdWRpZW5jZS9zIHRoZSB0b2tlbiBp
cyBwcmVzZW50YWJsZSBhdC4gIFRoZSBjbGllbnQgd291bGQgdGhyb3cgYW4gZXJyb3IgaWYgdGhl
IFJTIGl0IGludGVuZHMgdG8gc2VuZCB0aGUgdG9rZW4gdG8gaXMgbm90IG9uIHRoZSBsaXN0LiAg
IFRoZSBSUyB0aGUgdG9rZW4gaXMgZ29vZCBhdCBtaWdodCBjaGFuZ2UgYmFzZWQgb24gc2NvcGVz
LCBjbGllbnRfaWQgYW5kIHJlc291cmNlIG93bmVyLiAgIFRoaXMgaXMgdGhlIHBsYWNlIHdoZXJl
IGFsbCBvZiB0aGF0IGNvbWVzIHRvZ2V0aGVyLiAgIEluIHNvbWUgY2FzZXMgdGhlIFJTIGFuZCBB
UyBtaWdodCBub3QgaGF2ZSBhIHByZS1lc3RhYmxpc2hlZCByZWxhdGlvbnNoaXAuICAgVGhlIGNs
aWVudCBzaG91bGQgc2VuZCB0aGUgUlMgYmFzZSBVUkkgdG8gdGhlIEFTIGFzIHBhcnQgb2YgdGhl
IHJlcXVlc3QuICBUaGUgQVMgY2FuIHVzZSB0aGF0IHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSBB
VCBhbmQgaXNzdWUgdGhlIEFUIG9yIHJlZnVzZSB0byBpc3N1ZSB0aGUgQVQgYmFzZWQgb24gcG9s
aWN5Lg0KSXQgY2FuIGFsc28gdXNlIHRoZSBhdWRpZW5jZSBpbiB0aGUgcmVxdWVzdCB0byBkb3du
IGF1ZGllbmNlIHRoZSBBVCBpZiB0aGUgZGVmYXVsdCBpcyB0byBoYXZlIG11bHRpcGxlIGF1ZGll
bmNlcy4gICAgV2UgbWF5IHdhbnQgdG8gdXNlIGEgdGVybSBvdGhlciB0aGFuIGF1ZGllbmNlIGZv
ciB0aGlzIGxpa2UgcmVzb3VyY2Ugb3IgZGVzdGluYXRpb24uICBJdCBpcyBhIGF1ZGllbmNlIGJ1
dCB0aGF0IHRlcm0gbWlnaHQgY29uZnVzZSBwZW9wbGUgd2l0aCBBVC4NCg0KV2UgZGlkIHRhbGsg
YWJvdXQgYnJlYWtpbmcgYXVkaWVuY2Ugb3V0IG9mIFBPUCBrZXkgZGlzdHJpYnV0aW9uLCBhbmQg
QnJpYW4gQ2FtcGJlbGwgZGlkIGEgZHJhZnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWNhbXBiZWxsLW9hdXRoLWRzdDRqd3Q8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0
aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwl
MmZkcmFmdC1jYW1wYmVsbC1vYXV0aC1kc3Q0and0JmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9U1RyJTJiNGtyZDFoeThoNmVIT0NM
aDFQelFhS01VaFdsS1YyaSUyZkNMMEsxU1ElM2Q+Lg0KDQpUbyBkbyB0aGlzIHdlIGNvdWxkIHRh
a2UgZHN0NGp3dCBhbmQgYWRkIGFub3RoZXIgc3BlYyB0aGF0IGFkZHMgYSBuZXcgZHN0IHBhcmFt
ZXRlciB0byB0aGUgdG9rZW4gYW5kIGF1dGhvcml6YXRpb24gZW5kcG9pbnRzIHJlcXVlc3RzIFRo
YXQgd291bGQgYmUgYSBzcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBkc3QgdmFsdWVzLiAgYW5kIGlu
IHRoZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB3b3VsZCBiZSBhIEpTT04gYXJy
YXkgb2YgZHN0IHZhbHVlcy4NCg0KMykgSGF2ZSB0aGUgQVMgYWx3YXlzIHJldHVybiBhbGwgdGhl
IGxpc3Qgb2YgYWxsIFJTIHRoZSB0b2tlbiBjYW4gYmUgdXNlZCBhdCAoYmFzaWNhbGx5IE5hdCdz
IGxpbmsgcmVsYXRpb25zaGlwIHByb3Bvc2FsKS4gIEl0IG5lZWRzIGEgd2F5IHRvIGhhbmRsZQ0K
ZG93biBkZXN0aW5hdGlvbmluZyBvZiBBVCBhbmQgdG8gYWxsb3cgZm9yIHVuLWNvbmZpZ3VyZWQg
UlMgdGhhdCBpdCBtaWdodCBpc3N1ZSBhIHRva2VuIGZvci4gIFNvIGNvdWxkIGJlIGNvbWJpbmVk
IHdpdGggZHN0IGZyb20gMi4gIEJhc2ljYWxseSByZXR1cm5pbmcgdGhlIGFjY2VwdGFibGUgZGVz
dGluYXRpb25zIGFzIGxpbmsgaGVhZGVycyB2cyBKUyBpbiB0aGUgcmVzcG9uc2UgaXMgbW9zdGx5
IGEgc3R5bGUgaXNzdWUgdGhhdCBvdGhlciBwZW9wbGUgY2FuIGJpa2Ugc2hlZC4NCg0KDQo0KSBU
cnlpbmcgdG8gYWRkIGFsbCB0aGUgUlMgdG8gdGhlIEFTIGRpc2NvdmVyeSBkb2N1bWVudC4gIFRo
aXMgc2VlbXMgaW1wcmFjdGljYWwgYXMgdGhlcmUgd291bGQgYmUgbXVsdGlwbGUgcHJvdG9jb2xz
IGFuZCBkb2VzbuKAmXQgYWRkcmVzcyB1bi1jb25maWd1cmVkIFJTLg0KDQo1KSBTb21lIG5ldyBB
UyBlbmRwb2ludCB0aGF0IHRoZSBjbGllbnQgY291bGQgaW50cm9zcGVjdCB0aGUgUlMgVVJJIGFu
ZCBnZXQgYmFjayBtZXRhZGF0YSBhYm91dCBpZiB0aGUgY2xpZW50IHNob3VsZCBzZW5kIHRva2Vu
cyB0aGVyZS4NCiAgICBBIGNvdXBsZSBvZiBwcm9ibGVtcyB3aXRoIHRoaXMuICBUaGUgZmlyc3Qg
aXMgdGhhdCBpdCB3b3VsZCBub3Qgc3VwcG9ydCB1bi1jb25maWd1cmVkIFJTIHVubGVzcyB5b3Ug
YWRkIGRzdCB0byB0aGUgdG9rZW4gYW5kIGF1dGhvcml6YXRpb24gZW5kcG9pbnRzLiAgIFRoZSBv
dGhlciBpcyB0aGF0IHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGRvZXNu4oCZdCBoYXZlIHRo
ZSBjb250ZXh0IG9mIHRoZSBSTyBhbmQgY2xpZW50X2lkIHVubGVzcyB5b3UgYWxzbyBwYXNzIHRo
ZSBjb2RlL1JUIGFuZCBjbGllbnRfaWQsIGFuZCBwcm9iYWJseSBjbGllbnQgY3JlZGVudGlhbHMu
ICAgIEJhc2ljYWxseSB0aGlzIGlzIHRyeWluZyB0byBpbnRyb3NwZWN0IHRoZSBBVCB0byBkZXRl
cm1pbmUgdGhlIGF1ZGlhbmNlL2RzdC4gICBCeSB0aGUgdGltZSB5b3UgYnVpbGQgYSBuZXcgaW50
cm9zcGVjdGlvbiBlbmRwb2ludCBzZWN1cmVseSBpdCBpcyBnb2luZyB0byBsb29rIGxpa2UgdGhl
IHRva2VuIGVuZHBvaW50IHdpdGggYSBiaXQgbW9yZSBtZXRhIGRhdGEgYWJvdXQgdGhlIHRva2Vu
IGJleW9uZCBleHBpcnkgYW5kIHNjb3Blcy4NCg0KDQpJIHRoaW5rIHdlIHNob3VsZCBnbyBhIGhl
YWQgd2l0aCB0aGUgcmVuYW1lZCAiT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2Nv
dmVyeSBNZXRhZGF0YeKAnQ0KSSBhbSBhbHNvIGZpbmUgd2l0aCBtYWtpbmcgdGhlIGRlZmF1bHQg
ZG9jdW1lbnQgJ29wZW5pZC1jb25maWd1cmF0aW9u4oCZICBhcyBsb25nIGFzIHdlIGFsbG93IGZv
ciBwcm90b2NvbCBzcGVjaWZpYyB2YXJpYXRpb24gc28gdGhhdCBTQ0lNMiBjb3VsZCBkZWZpbmUg
YSBmaWxlIG5hbWUuICAgIElmIHBlb3BsZSB3YW50IHdlIGNvdWxkIGRvIGEgQVBJICB0byBmaWxl
IG5hbWUgcmVnaXN0cnkgc28gdGhhdCBwcm90b2NvbCBzcGVjaWZpYyBvbmVzIGNhbiBiZSBkZWZp
bmVkLg0KDQpXZSBhcmUgYWxsLXJlYWR5IHdvcmtpbmcgb24gb3B0aW9uIDEgdG8gc2VjdXJlIEFU
LCB3ZSBuZWVkIGEgc3BlYyBsaWtlIEkgcHJvcG9zZSBpbiAyIGZvciBiZWFyZXIgdG9rZW5zLiAg
V2UgY2FuIGFkZCBvbmUgcmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGEgYml0IG1vcmUgdG9rZW4gbWV0
YS1kYXRhIHRvIHRoZSB0b2tlbiByZXNwb25zZSBhbmQgdGhhdCB0YWtlcyBjYXJlIG9mIHRoZSBw
cm9ibGVtLiAgIEhvbmVzdGx5IHdlIHByb2JhYmx5IHNob3VsZCBoYXZlIHNlcGFyYXRlZCBzY29w
ZSBhbmQgZGVzdGluYXRpb24gaW4gdGhlIGZpcnN0IHBsYWNlIGFuZCByZXR1cm5lZCBib3RoIGRz
dCBhbmQgc2NvcGUgaW4gdGhlIHJlc3BvbnNlIGFsbCBhbG9uZywgc28gdGhpcyBpcyB1cGRhdGUg
dGhhdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGVpc3RpbmcgYXJjaGl0ZWN0dXJlIG9mIE9BdXRo
IDIuDQoNCkxldHMga2VlcCB0aGUgdHdvIGlzc3VlcyBzZXBhcmF0ZS4NCg0KSm9obiBCLg0KDQoN
Cg0KDQpPbiBNYXIgMTEsIDIwMTYsIGF0IDEyOjA3IEFNLCBBbnRob255IE5hZGFsaW4gPHRvbnlu
YWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoN
ClRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBBUyBhbmQgUlMgbmVlZCB0byBiZSBzY29wZWQgdG8g
4oCcZG9lcyB0aGlzIFJTIGFjY2VwdCB0b2tlbnMgZnJvbSB0aGlzIEFT4oCdIGFzIGEgbGlzdCBp
cyB0b28gbXVjaCBpbmZvcm1hdGlvbiB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gdGhlIHdyb25nIHdh
eQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBOYXQgU2FraW11cmENClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxMCwgMjAxNiA2OjI1IFBN
DQpUbzogUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o
dW50QG9yYWNsZS5jb20+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA
aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENh
bGwgb24gT0F1dGggMi4wIERpc2NvdmVyeQ0KDQpQaGlsLA0KDQpSaWdodC4gU28gd2hhdCBteSBj
b25kaXRpb25hbCBhcHByb3ZhbHMgKDExIGNvbmRpdGlvbnMgaW4gdG90YWwpIHNhaWQgd2FzIHRv
IGRyb3AgdGhlIHdvcmQgImRpc2NvdmVyeSIgZnJvbSBldmVyeXdoZXJlLiBUaGlzIGlzIG5vdCBh
IGRpc2NvdmVyeSBzcGVjLiBUaGlzIGlzIGEgY29uZmlndXJhdGlvbiBsb29rdXAgc3BlYyBhcyB5
b3UgY29ycmVjdGx5IHBvaW50cyBvdXQuIFNvLCBJIGFtIHdpdGggeW91IGhlcmUuDQoNCkFsc28s
IG15IDJuZCBjb25kaXRpaW9uIGlzIGVzc2VudGlhbGx5IHNheWluZyB0byBkcm9wIHNlY3Rpb24g
My4NCg0KT25lIHRoaW5nIHRoYXQgSSBvdmVybG9va2VkIGFuZCBhbSB3aXRoIHlvdSBpcyB0aGF0
IHdlIG5lZWQgdG8gYmUgYWJsZSB0byBleHByZXNzIHRoZSBBUy1SUyByZWxhdGlvbnNoaXBzLiBJ
IGhhdmUgYmVlbiBwcmVhY2hpbmcgdGhpcyBpbiB0aGUgb3RoZXIgdGhyZWFkIGZvciBzbyBtYW55
IHRpbWVzIGFzIHlvdSBrbm93IHNvIEkgdGhvdWdodCBJIHBvaW50ZWQgaXQgb3V0LCBidXQgbWlz
c2VkIGFwcGFyZW50bHkgaW4gbXkgcHJldmlvdXMgY29tbWVudC4gU28sIEkgd291bGQgYWRkIG15
IDEydGggY29uZGl0aW9uOg0KDQoxMi4gQSB3YXkgdG8gZXhwcmVzcyBhIGxpc3Qgb2YgdmFsaWQg
UlNzIGZvciB0aGlzIEFTIG5lZWRzIHRvIGJlIGFkZGVkIHRvIHNlY3Rpb24gMi4NCg0KQmVzdCwN
Cg0KTmF0DQoNCjIwMTYtMDMtMTEgMjowOSBHTVQrMDk6MDAgUGhpbCBIdW50IChJRE0pIDxwaGls
Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNCkkgc3Ryb25n
bHkgb3Bwb3NlLiAyIG1ham9yIGlzc3Vlcy4NCg0KVGhpcyBpcyBub3Qgc2VydmljZSBkaXNjb3Zl
cnkgdGhpcyBpcyBjb25maWd1cmF0aW9uIGxvb2t1cC4gVGhlIGNsaWVudCBtdXN0IGhhdmUgYWxy
ZWFkeSBkaXNjb3ZlcmVkIHRoZSBvYXV0aCBpc3N1ZXIgdXJpIGFuZCB0aGUgcmVzb3VyY2UgdXJp
Lg0KDQpUaGUgb2JqZWN0aXZlIHdhcyB0byBwcm92aWRlIGEgbWV0aG9kIHRvIGVuc3VyZSB0aGUg
Y2xpZW50IGhhcyBhIHZhbGlkIHNldCBvZiBlbmRwb2ludHMgdG8gcHJldmVudCBtaXRtIG9mIGVu
ZHBvaW50cyBsaWtlIHRoZSB0b2tlbiBlbmRwb2ludCB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLg0K
DQpUaGUgZHJhZnQgZG9lcyBub3QgYWRkcmVzcyB0aGUgaXNzdWUgb2YgYSBjbGllbnQgYmVpbmcg
Z2l2ZW4gYSBiYWQgZW5kcG9pbnQgZm9yIGFuIHJzLiBXaGF0IHdlIGVuZCB1cCB3aXRoIGlzIGEg
cHJvbWlzY3VvdXMgYXV0aHogc2VydmljZSBnaXZpbmcgb3V0IHRva2VucyB0byBhbiB1bndpdHRp
bmcgY2xpZW50Lg0KDQpQaGlsDQoNCk9uIE1hciAxMCwgMjAxNiwgYXQgMDg6MDYsIFZsYWRpbWly
IER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWlyQGNvbm5l
Y3QyaWQuY29tPj4gd3JvdGU6DQorMSB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGVzZQ0KT24gMTAv
MDMvMTYgMTc6MzUsIEJyaWFuIENhbXBiZWxsIHdyb3RlOg0KDQorMQ0KDQoNCg0KT24gVGh1LCBN
YXIgMTAsIDIwMTYgYXQgNjowNCBBTSwgUm9sYW5kIEhlZGJlcmcgPHJvbGFuZC5oZWRiZXJnQHVt
dS5zZT48bWFpbHRvOnJvbGFuZC5oZWRiZXJnQHVtdS5zZT4NCg0Kd3JvdGU6DQoNCg0KDQpJIHN1
cHBvcnQgdGhpcyBkb2N1bWVudCBiZWluZyBtb3ZlZCBmb3J3YXJkIHdpdGggdGhlc2UgdHdvIGNo
YW5nZXM6DQoNCg0KDQotIGNoYW5nZSBuYW1lIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9u
IFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRhdGHigJ0gYXMNCg0KcHJvcG9zZWQgYnkgQnJpYW4gYW5k
DQoNCi0gdXNlIHRoZSBVUkkgcGF0aCBzdWZmaXgg4oCZb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2
ZXLigJkgaW5zdGVhZCBvZg0KDQrigJlvcGVuaWQtY29uZmlndXJhdGlvbuKAmSBhcyBwcm9wb3Nl
ZCBieSBKdXN0aW4uDQoNCg0KDQoxOCBmZWIgMjAxNiBrbC4gMTQ6NDAgc2tyZXYgSGFubmVzIFRz
Y2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2Zl
bmlnQGdteC5uZXQ+DQoNCjoNCg0KDQoNCkhpIGFsbCwNCg0KDQoNClRoaXMgaXMgYSBMYXN0IENh
bGwgZm9yIGNvbW1lbnRzIG9uIHRoZSAgT0F1dGggMi4wIERpc2NvdmVyeQ0KDQpzcGVjaWZpY2F0
aW9uOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNj
b3ZlcnktMDE8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91
cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRo
LWRpc2NvdmVyeS0wMSZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzEx
NmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJnNkYXRhPXczJTJiaWlhV29uODFMSkNVJTJiMm1DUFJtQSUyYnJFQ0JIZ3F5
UnIwT2dxaVdTSFUlM2Q+DQoNCg0KDQpTaW5jZSB0aGlzIGRvY3VtZW50IHdhcyBvbmx5IGFkb3B0
ZWQgcmVjZW50bHkgd2UgYXJlIHJ1bm5pbmcgdGhpcyBsYXN0DQoNCmNhbGwgZm9yICoqMyB3ZWVr
cyoqLg0KDQoNCg0KUGxlYXNlIGhhdmUgeW91ciBjb21tZW50cyBpbiBubyBsYXRlciB0aGFuIE1h
cmNoIDEwdGguDQoNCg0KDQpDaWFvDQoNCkhhbm5lcyAmIERlcmVrDQoNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3
UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoNCuKAlCBSb2xhbmQNCg0KDQoNCuKAnUV2
ZXJ5Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBhIGxpdHRsZSBzdHJlYW0gYW5kIGxpc3Rlbi4i
DQoNCj5Gcm9tIOKAmU9wZW4gSG91c2UgZm9yIEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNz
DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDEl
N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQz
NDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5D
aWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQoN
Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy
ZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2Mw
MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1
NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5DaWtt
WERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3
UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9
bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9y
Zy88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0
cCUzYSUyZiUyZm5hdC5zYWtpbXVyYS5vcmclMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT02RlZtZE43YWQwWXpvWUtTTkYlMmZE
TyUyZmZHMkVGMWhhajVhT0hpTWlkNlVNSSUzZD4NCkBfbmF0X2VuDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0
aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v
dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxp
c3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0
YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3
Y2QwMTFkYjQ3JTdjMSZzZGF0YT1iS3NFVkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJiRkpDUXJucTlh
c3hSbzVIZTglM2Q+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz
JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0w
MSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4
ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1i
S3NFVkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJiRkpDUXJucTlhc3hSbzVIZTglM2Q+DQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0
aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w
aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs
YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDIwNjAiPlRoZSBkcmFmdCBlbmFibGVzIGVhc3kgY29uZmlndXJhdGlvbiBvZiBP
QXV0aCBjbGllbnRzIHdpdGggYW4gQVMuJm5ic3A7IEZvciBpbnN0YW5jZSwgdGhlIE1pY3Jvc29m
dCDigJxBREFM4oCdIE9BdXRoIGNsaWVudCBzb2Z0d2FyZSB1c2VzIEFTIG1ldGFkYXRhIGluIHRo
aXMgZm9ybWF0IGFzDQogYW4gaW5wdXQgYXQgY2xpZW50IGNvbmZpZ3VyYXRpb24gdGltZS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFzIGEgc2lkZSBiZW5lZml0
LCBoYXZpbmcgdGhpcyBzdGFuZGFyZCBBUyBtZXRhZGF0YSBmb3JtYXQgYW5kIHJldHVybmluZyB0
aGUgaXNzdWVyIFVSTCBwZXIgdGhlIE1peC1VcCBNaXRpZ2F0aW9uIGRyYWZ0IHdpbGwgYWxzbyBl
bmFibGUgY2xpZW50cyB0byB2YWxpZGF0ZSB0aGF0DQogdGhleSBhcmUgdXNpbmcgYSBjb25zaXN0
ZW50IHNldCBvZiBBUyBlbmRwb2ludHMgYW5kIGluZm9ybWF0aW9uLiZuYnNwOyBCdXQgZXZlbiB3
aXRob3V0IHRoZSBtaXRpZ2F0aW9uIGJlbmVmaXRzLCB0aGUgY2xpZW50IGNvbmZpZ3VyYXRpb24g
YmVuZWZpdCBpcyB0aGUgcHJpbWFyeSByZWFzb24gZm9yIHRoZSBzcGVjaWZpY2F0aW9uLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv
c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwv
c3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPkFudGhvbnkgTmFkYWxpbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDExLCAy
MDE2IDM6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxA
cGluZ2lkZW50aXR5LmNvbSZndDs7IEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20m
Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIE9B
dXRoIDIuMCBEaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRpc2FncmVlLCB3aGF0IHB1cnBvc2UgaXMgdGhpcyBh
Y3Rpdml0eSBzb2x2aW5nIHRoZW4sIGl0IHdhcyBiZWluZyBwdXNoZWQgYXMgd2hhdCB3YXMgbmVl
ZCB0byBzb2x2ZSB0aGUgTWl4LXVwLCBidXQgdGhhdCBpcyBub3QgdHJ1ZS4gU28gbm93IHlvdSBh
cmUgc3VnZ2VzdGluZyBhIGNoYW5nZSBpbg0KIHNjb3BlIGFuZCBub3QgZGVhbGluZyB3aXRoIGRp
c2NvdmVyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+IE9BdXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBD
YW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDExLCAyMDE2IDM6MTEgUE08
YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2
ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBvYXV0
aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4m
Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFz
dCBDYWxsIG9uIE9BdXRoIDIuMCBEaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgdGVuZCB0byBhZ3JlZSB3
aXRoIEpvaG4gdGhhdCBhZGRyZXNzaW5nIHRoZSBjb25jZXJucyBQaGlsIHJhaXNlcyBzaG91bGQg
YmUgcGFydCBvZiAoZXh0ZW5zaW9uIHRvKSB0aGUgY29yZSBwcm90b2NvbC4mbmJzcDsgQW5kIHRo
YXQgdGhvc2Uga2luZHMgb2YgY29uY2VybnMgZG9uJ3QgbWFuaWZlc3QgaW4gdGhlIHdheSBPQXV0
aCBpcyB0eXBpY2FsbHkgZGVwbG95ZWQNCiBub3cuIDxicj4NCjxicj4NClRoZSBob3BlZnVsbHkg
c29vbiB0byBiZSBuYW1lZCAmcXVvdDtPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0
YWRhdGEmcXVvdDsgc2hvdWxkIGtlZXAgaXQncyBzY29wZSB0byB0aGUgcHVibGlzaGluZyBvZiBh
dXRob3JpemF0aW9uIHNlcnZlciBtZXRhZGF0YS4gVGhlIGFjdCBvZiBkb2luZyBkaXNjb3Zlcnkg
aXMgYmV5b25kIGl0cyBzY29wZSBhbmQgc28gaXMgdHJ5aW5nIHRvIHByZXZlbnQgYSBjbGllbnQg
ZnJvbSBwcmVzZW50aW5nIGEgdG9rZW4gdG8NCiBzb21lcGxhY2UgaXQgc2hvdWxkbid0LiA8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDEx
LCAyMDE2IGF0IDk6MDggQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0
YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklubGluZTxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAxMSwg
MjAxNiwgYXQgMTI6MTMgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208
L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5Kb2huPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkluIG1hbnkgY2FzZSBhbGwgdGhlIEFTIGhhcyB0byBjaGVjayBpcyB0aGUg
ZG9tYWluIG5hbWUgY29tcG9uZW50IHRvIGNoZWNrIGZvciBtaXRtLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QT1AgYW5kIHRoZSBv
dGhlciBzb2xucyBhcmUgZHJhbWF0aWNhbGx5IG1vcmUgY29tcGxleCB0aGFuIGEgc2ltcGxlIGNo
ZWNrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBwcm9wb3NpbmcgZGluZyB0aGF0
IGNoZWNrIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IG9yIHRva2VuIGVuZHBvaW50IGFz
IHBhcnQgb2YgQVQgaXNzdWFuY2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIHVwIHRvIHRoZSBBUyBob3cgbXVjaCBvZiB0
aGUgcGF0aCB0byB2YWxpZGF0ZSBhbmQgb3IgcHV0IGluIHRoZSBhdWQgb3IgZHN0LiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSBpdCBhcyBwYXJ0IG9mIHRoZSBkaXNjb3Zlcnko
YmFkIG5hbWUgYXNpZGUpIHByb2JsZW0gYmVjYXVzZSB3ZSBkaXNjdXNzZWQgdGhhdCBpZiBhIGNs
aWVudCBmaW5kcw0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5leGFtcGxlLmNvbSUyZiZhbXA7ZGF0YT0w
MSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4
ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2Rh
dGE9ZmlTOGY2MHlwaVhoeU0wcVZUZXFsJTJiJTJiT3pIMndibUVDUUU3SjVUdEdQUU0lM2QiIHRh
cmdldD0iX2JsYW5rIj4NCmFwcC5leGFtcGxlLmNvbTwvYT4gaG93IGRvIHdlIGVuc3VyZSBpdCBn
ZXRzIGEgY29tcGxldGUgc2V0IG9mIG9hdXRoIGVuZHBvaW50cyBhcyBhIHZhbGlkIHNldCBvZiBl
bmRwb2ludHMtLXRoYXQgYSBoYWNrZXIgaGFzIG5vdCBpbnNlcnRlZCBvbmUgb2YgdGhlaXIgb3du
IGVuZHBvaW50cy4gVGhlIG1vc3QgaW1wb3J0YW50IGVuZHBvaW50IHRvIGdldCByaWdodCBpcyBl
bnN1cmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyIChhbmQgb3B0aW9uYWxseSB0aGUNCiBwYXRoKSBp
cyB0aGUgY29ycmVjdCBvbmUuIFdlIGNhbid0IHJlYWxseSBkZWZpbmUgcmVzb3VyY2UgZGlzY292
ZXJ5IGJ1dCB3ZSBjYW4gdmFsaWRhdGUgaXQgdG8gc29tZSBkZWdyZWUuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IGlzIHBhcnQgb2YgY29yZSBwcm90b2NvbCBz
ZWN1cml0eSBhbmQgc2hvdWxkL211c3Qgbm90IHJlcXVpcmUgZGlzY292ZXJ5LiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGlz
IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHAlM2ElMmYlMmZhcHAuZXhhbXBsZS5jb20mYW1wO2RhdGE9MDElN2MwMSU3Y3Rvbnlu
YWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3
MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWpBc1pRZUNoSiUy
YlIxbGJ5Qm9WS3doZUlZaTNQaVdMcnElMmJ4RExicVU2cnhrJTNkIiB0YXJnZXQ9Il9ibGFuayI+
DQphcHAuZXhhbXBsZS5jb208L2E+ID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgaXQgaXMgdGhlIHJlc291cmNlIHRoZW4gdGhl
IGNsaWVudCB3b3VsZCBiZSBwcmVjb25maWd1cmVkIGZvciBpdOKAmXMgQVMgb3V0IG9mIGJhbmQg
b3Igb3B0aW9uYWxseSB3b3VsZCBkbyBkaXNjb3Zlcnkgb24gdGhlIGlzc3VlciB1cmkgdGhhdCB5
b3UgYWRtaXQgbmVlZHMgdG8gYmUgY29uZmlndXJlZCBvdXQgb2YgYmFuZCBzb21lIHdheSAobm90
ZSBkaXNjb3ZlcnkgaXMgb3B0aW9uYWwpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBBUyBtZXRhLWRhdGEgZHJhZnQgaXQgd291bGQg
ZG8gYSBnZXQgb24gYSB3ZWxsIGtub3duIGZpbGUgdGhhdCB3b3VsZCBoYXZlIGNvbmZpZ3VyYXRp
b24gZm9yIHRoZSBBUywgYnV0IG5vdCB0aGUgUlMsIHRob3VnaCBzb21lIEFQSSBtYXkgb3B0aW9u
YWxseSBsaXN0IGEgQVBJIGVuZHBvaW50IGxpa2UgY29ubmVjdCBoYXMuICZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2xpZW50
IHRoZW4gbWFrZXMgYSBhdXRob3JpemF0aW9uIHJlcXVlc3QgKGFmdGVyIHJlZ2lzdGVyaW5nIG91
dCBvZiBiYW5kIG9yIGR5bmFtaWNhbGx5KS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9u
IHJlcXVlc3QgZm9yIGltcGxpY2l0IGl0IGNvdWxkIHByb3ZpZGUgdGhlIGF1ZC9kc3QgdGhhdCBp
dCB3YW50cyB0aGUgdG9rZW4gZm9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhhdCBpcyBub3Qgc2VudCB0aGVuIHRoZSBhdWQvZHN0IGFy
ZSBpbXBsaWNpdCBpbiB0aGUgc2NvcGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2xpZW50IGdldHMgYmFjayBhIEFUIHdpdGggYSBs
aXN0IG9mIHNjb3BlcyBncmFudGVkLCBhdWQvZHN0IGFsbG93ZWQgYW5kIHRpbWUgdG8gbGl2ZSBm
b3IgdGhlIHRva2VuIChvbmUgZXh0cmEgdGhpbmcgcmV0dXJuZWQpPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZG9lc27igJl0IHJlcXVp
cmUgYW55IGRpc2NvdmVyeSAoeWVzIHRoZXJlIGlzIGEgb3B0aW9uYWwgQVMgbWV0YS1kYXRhIGRp
c2NvdmVyeSBidXQgbm90IHJlcXVpcmVkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHByZWZlciB0byBmaXggdGhlIFJTIG1hbiBpbiB0aGUg
bWlkZGxlIGlzc3VlIGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIGFuZCBub3QgcGFydCBvZiBkaXNj
b3ZlcnkgdGhhdCBzaG91bGQgcmVtYWluIG9wdGlvbmFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhvbmVzdGx5IGRvbuKAmXQgcXVpdGUg
a25vdyBob3cgdGhlIGNsaWVudCBsZWFybnMgYWJvdXQgdGhpcyBiYWQgUlMgYW5kIHN0YXJ0cyB0
YWxraW5nIHRvIGl0LCBzbyB0aGlzIG1heSBiZSBhIHNvbHV0aW9uIHRvIGEgcHJvYmxlbSB0aGF0
IGRvZXNu4oCZdCB5ZXQgZXhpc3QuICZuYnNwOyBUaGUgb25lIHBsYWNlIHRoaXMgaXMgcG9zYWJs
ZSBpcyBpZiB0aGUgcmVnaXN0cmF0aW9uIGZvciB0aGUgY2xpZW50IGlzIGNvbXByb21pc2VkLiZu
YnNwOw0KIEhvd2V2ZXIgd2UgYXJlIGRpc2N1c3Npbmcgb3RoZXIgbWl0aWdhdGlvbnMgZm9yIHRo
YXQgdGhhdCBhbHNvIGV4cGxpY2l0bHkgZG8gbm90IHJlcXVpcmUgZGlzY292ZXJ5LjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzdHVjayBv
biB3ZWJmaW5nZXIgb3Igd2VsbC1rbm93bi4gQmVjYXVzZSB0aGlzIGlzIGNvbmZpZyBtYXliZSBp
dCBzaG91bGQgYmUgYW4gb2F1dGggZW5kcG9pbnQuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBNYXIgMTEsIDIwMTYsIGF0IDA2OjUxLCBKb2hu
IEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgUGhpbCBpcyBwcm9w
b3Npbmcgc29tZXRoaW5nIGRpZmZlcmVudC4gJm5ic3A7IFNob3VsZCB0aGUgY2xpZW50IHNlbmQg
YSB0b2tlbiBmcm9tIHRoaXMgQVMgdG8gdGhhdCBSUy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaXMgZ29hbCBpcyB0byBwcmV2ZW50IG1hbiBp
biB0aGUgbWlkZGxlIGF0dGFja3Mgd2hlcmUgYSBiYWQgUlMgZ2V0cyBhIEFUIHRoYXQgaXMgYXVk
aWFuY2VkIHRvL2FjY2VwdGVkIGJ5IGFub3RoZXIgUlMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUg
cXVlc3Rpb24gb2YgaWYgYSBSUyBhY2NlcHRzIHRva2VucyBmcm9tIGEgZ29vZCBBUy4gJm5ic3A7
IEEgYmFkIEFTIHdvdWxkIGFsd2F5cyBzYXkgeWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBuZWVkIHRvIGJlIGNhcmVmdWwgb2Ygd2hh
dCBpZiBhbnl0aGluZyB0aGUgUlMgcHJvdmlkZXMgdG8gdGhlIGNsaWVudCBhcyBtZXRhLWRhdGEg
d2l0aG91dCB2YWxpZGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5DdXJyZW50bHkgdGhlIGNsaWVudCBjYW4gcHJvdmlkZSBhIGxpc3Qg
b2Ygc2NvcGVzIHJlcXVpcmVkIHRvIGdldCBhY2Nlc3MuICZuYnNwOyBJIHBlcnNvbmFsbHkgZmVl
bCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gYWxzbyBpbmNsdWRlIGluIHRoZSB1bmF1dGhlbnRpY2F0
ZWQgZXJyb3IgcmVzcG9uc2UgYW4gaW5kaWNhdGlvbiBvZiB3aGF0IEFQSSB0aGUgcmVzb3VyY2Ug
c3VwcG9ydHMuJm5ic3A7IFNheSDigJxzY2ltMuKAnSBhcyBhbiBleGFtcGxlLg0KICZuYnNwOyBJ
IGRvbuKAmXQgdGhpbmsgYWRkaW5nIHRoYXQgaXMgaG93ZXZlciBhIGhpZ2ggcHJpb3JpdHkgYXMg
bW9zdCBpZiBhbGwgY2xpZW50cyBrbm93IHdoYXQgQVBJIHRoZXkgZXhwZWN0LiAmbmJzcDsgSXQg
bWlnaHQgYmUgdXNlZnVsIGlmIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZSBpZiBhIGNsaWVu
dCB3ZXJlIHRvIGJlIGdpdmVuIGEgUlMgVVJJIGl0IGNvdWxkIGNoZWNrIHRvIHNlZSBpZiBpdCBp
cyBhIHByb3RvY29sIHRoYXQgaXQgc3VwcG9ydHMgYmVmb3JlDQogYm90aGVyaW5nIHdpdGggT0F1
dGguICZuYnNwOyAmbmJzcDtJIGV4cGVjdCB0aGF0IGEgbG90IG9mIHBlb3BsZSB3aWxsIHdhbnQg
dGhhdCBsZWZ0IHRvIHRoZSBBUEkgZGVmaW5pdGlvbi4gJm5ic3A7IEkgdGhpbmsgd2UgY2FuIHRh
bGsgYWJvdXQgaXQgYnV0IHJhdGUgdGhpcyBsb3cgcHJpb3JpdHkuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCB0aGUgUlMg
Z2l2aW5nIG91dCBhIGxpc3Qgb2YgQVMgdGhhdCBpdCB0cnVzdHMgaXMgYSBnZW5lcmFsbHkgYmFk
IGlkZWEuJm5ic3A7IEkgaG9wZSB0aGF0IGlzIG5vdCBvbiB0aGUgdGFibGUuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGlu
ayB0aGF0IHByZXZlbnRpbmcgYSBjbGllbnQgZnJvbSBzZW5kaW5nIGEgdG9rZW4gdG8gdGhlIHdy
b25nIFJTIGlzIHBhcnQgb2YgYSBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5IHByb2JsZW0uPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gaG93
ZXZlciB0aGluayB0aGF0IGl0IGlzIGltcG9ydGFudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhp
cyBhcyBhIHNlcGFyYXRlIHByb2JsZW0gdG8gQVMgbWV0YS1kYXRhIGRpc2NvdmVyeSB3aGVyZSB0
aGUgZW5kcG9pbnRzIG9mIHRoZSBBUyBhbmQgaXTigJlzIGNvbmZpZ3VyYXRpb24gYXJlIGRpc2Nv
dmVyeS4gJm5ic3A7IFNvcnJ5IGZvciBwZXJoYXBzIHN0YXRpbmcgdGhlIG9idmlvdXMsIGJ1dCB0
aGUgUlMgaXMgZXhwbGljaXRseSBub3QgcGFydCBvZiB0aGUgQVMgaW4gT0F1dGgNCiAyLiAmbmJz
cDsgU3RhcnRpbmcgaW4gV0FQIHRoYXQgd2FzIGEgY29yZSBwcmluY2lwYWwuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHdlIGhhdmUgYSBu
dW1iZXIgb2Ygb3B0aW9ucyB0byBhZGRyZXNzIHRoZSBSUyB0b2tlbiBsZWFrYWdlIHZpYSBNaVRN
IGF0dGFja3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjEpIFBvUCBib3VuZCB0b2tlbnMuJm5ic3A7IElmIHRoZXkgYXJlIGJvdW5kIHRvIHRo
ZSBUTFMgY2hhbm5lbCBieSBtdXR1YWwgVExTIG9yIFRva2VuIGJpbmRpbmcgdGhleSBjYW5ub3Qg
YmUgcmVwbGF5ZWQuJm5ic3A7IFNpZ25lZCBtZXNzYWdlcyB3aGVyZSB0aGUgc2lnbmluZyBjb3Zl
cnMgdGhlIFJTIEhvc3QgYW5kIHBhdGggY29tcG9uZW50cywgJm5ic3A7YWxzbyB3b3VsZCB3b3Jr
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y
KSBIYXZlIHRoZSBBUyBhdWRpZW5jZSByZXN0cmljdCB0aGUgcmVzb3VyY2VzIHRoZSBBVCBpcyBn
b29kIGF0LiAoQVQgc2hvdWxkIGJlIGRvaW5nIHRoYXQgbm93KSZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIHRva2VuIHJlc3Bv
bnNlIGluY2x1ZGUgdGhlIGxpc3Qgb2YgYXVkaWVuY2UvcyB0aGUgdG9rZW4gaXMgcHJlc2VudGFi
bGUgYXQuJm5ic3A7IFRoZSBjbGllbnQgd291bGQgdGhyb3cgYW4gZXJyb3IgaWYgdGhlIFJTIGl0
IGludGVuZHMgdG8gc2VuZCB0aGUgdG9rZW4gdG8gaXMgbm90IG9uIHRoZSBsaXN0LiAmbmJzcDsg
VGhlIFJTIHRoZSB0b2tlbiBpcyBnb29kIGF0IG1pZ2h0IGNoYW5nZSBiYXNlZCBvbiBzY29wZXMs
DQogY2xpZW50X2lkIGFuZCByZXNvdXJjZSBvd25lci4gJm5ic3A7IFRoaXMgaXMgdGhlIHBsYWNl
IHdoZXJlIGFsbCBvZiB0aGF0IGNvbWVzIHRvZ2V0aGVyLiAmbmJzcDsgSW4gc29tZSBjYXNlcyB0
aGUgUlMgYW5kIEFTIG1pZ2h0IG5vdCBoYXZlIGEgcHJlLWVzdGFibGlzaGVkIHJlbGF0aW9uc2hp
cC4gJm5ic3A7IFRoZSBjbGllbnQgc2hvdWxkIHNlbmQgdGhlIFJTIGJhc2UgVVJJIHRvIHRoZSBB
UyBhcyBwYXJ0IG9mIHRoZSByZXF1ZXN0LiZuYnNwOyBUaGUgQVMgY2FuIHVzZSB0aGF0DQogdG8g
YXVkaWVuY2UgcmVzdHJpY3QgdGhlIEFUIGFuZCBpc3N1ZSB0aGUgQVQgb3IgcmVmdXNlIHRvIGlz
c3VlIHRoZSBBVCBiYXNlZCBvbiBwb2xpY3kuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBjYW4gYWxzbyB1c2UgdGhlIGF1ZGllbmNlIGluIHRo
ZSByZXF1ZXN0IHRvIGRvd24gYXVkaWVuY2UgdGhlIEFUIGlmIHRoZSBkZWZhdWx0IGlzIHRvIGhh
dmUgbXVsdGlwbGUgYXVkaWVuY2VzLiAmbmJzcDsgJm5ic3A7V2UgbWF5IHdhbnQgdG8gdXNlIGEg
dGVybSBvdGhlciB0aGFuIGF1ZGllbmNlIGZvciB0aGlzIGxpa2UgcmVzb3VyY2Ugb3IgZGVzdGlu
YXRpb24uJm5ic3A7IEl0IGlzIGEgYXVkaWVuY2UgYnV0IHRoYXQgdGVybSBtaWdodA0KIGNvbmZ1
c2UgcGVvcGxlIHdpdGggQVQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPldlIGRpZCB0YWxrIGFib3V0IGJyZWFraW5nIGF1ZGllbmNlIG91dCBv
ZiBQT1Aga2V5IGRpc3RyaWJ1dGlvbiwgYW5kIEJyaWFuIENhbXBiZWxsIGRpZCBhIGRyYWZ0Jm5i
c3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t
Lz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1jYW1wYmVs
bC1vYXV0aC1kc3Q0and0JmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv
bSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkx
YWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1TVHIlMmI0a3JkMWh5OGg2ZUhPQ0xoMVB6UWFL
TVVoV2xLVjJpJTJmQ0wwSzFTUSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1kc3Q0and0PC9hPi4NCiAmbmJzcDsmbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VG8gZG8gdGhpcyB3ZSBjb3VsZCB0YWtlIGRzdDRqd3QgYW5kIGFkZCBhbm90aGVyIHNwZWMgdGhh
dCBhZGRzIGEgbmV3IGRzdCBwYXJhbWV0ZXIgdG8gdGhlIHRva2VuIGFuZCBhdXRob3JpemF0aW9u
IGVuZHBvaW50cyByZXF1ZXN0cyBUaGF0IHdvdWxkIGJlIGEgc3BhY2Ugc2VwYXJhdGVkIGxpc3Qg
b2YgZHN0IHZhbHVlcy4gJm5ic3A7YW5kIGluIHRoZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbiBl
bmRwb2ludCB3b3VsZA0KIGJlIGEgSlNPTiBhcnJheSBvZiBkc3QgdmFsdWVzLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBIYXZlIHRoZSBB
UyBhbHdheXMgcmV0dXJuIGFsbCB0aGUgbGlzdCBvZiBhbGwgUlMgdGhlIHRva2VuIGNhbiBiZSB1
c2VkIGF0IChiYXNpY2FsbHkgTmF0J3MgbGluayByZWxhdGlvbnNoaXAgcHJvcG9zYWwpLiZuYnNw
OyBJdCBuZWVkcyBhIHdheSB0byBoYW5kbGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRvd24gZGVzdGluYXRpb25pbmcgb2YgQVQgYW5k
IHRvIGFsbG93IGZvciB1bi1jb25maWd1cmVkIFJTIHRoYXQgaXQgbWlnaHQgaXNzdWUgYSB0b2tl
biBmb3IuJm5ic3A7IFNvIGNvdWxkIGJlIGNvbWJpbmVkIHdpdGggZHN0IGZyb20gMi4mbmJzcDsg
QmFzaWNhbGx5IHJldHVybmluZyB0aGUgYWNjZXB0YWJsZSBkZXN0aW5hdGlvbnMgYXMgbGluayBo
ZWFkZXJzIHZzIEpTIGluIHRoZSByZXNwb25zZSBpcyBtb3N0bHkgYSBzdHlsZQ0KIGlzc3VlIHRo
YXQgb3RoZXIgcGVvcGxlIGNhbiBiaWtlIHNoZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NCkgVHJ5aW5nIHRvIGFkZCBhbGwgdGhlIFJT
IHRvIHRoZSBBUyBkaXNjb3ZlcnkgZG9jdW1lbnQuJm5ic3A7IFRoaXMgc2VlbXMgaW1wcmFjdGlj
YWwgYXMgdGhlcmUgd291bGQgYmUgbXVsdGlwbGUgcHJvdG9jb2xzIGFuZCBkb2VzbuKAmXQgYWRk
cmVzcyB1bi1jb25maWd1cmVkIFJTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj41KSBTb21lIG5ldyBBUyBlbmRwb2ludCB0aGF0IHRoZSBjbGll
bnQgY291bGQgaW50cm9zcGVjdCB0aGUgUlMgVVJJIGFuZCBnZXQgYmFjayBtZXRhZGF0YSBhYm91
dCBpZiB0aGUgY2xpZW50IHNob3VsZCBzZW5kIHRva2VucyB0aGVyZS48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgQSBjb3Vw
bGUgb2YgcHJvYmxlbXMgd2l0aCB0aGlzLiZuYnNwOyBUaGUgZmlyc3QgaXMgdGhhdCBpdCB3b3Vs
ZCBub3Qgc3VwcG9ydCB1bi1jb25maWd1cmVkIFJTIHVubGVzcyB5b3UgYWRkIGRzdCB0byB0aGUg
dG9rZW4gYW5kIGF1dGhvcml6YXRpb24gZW5kcG9pbnRzLiAmbmJzcDsgVGhlIG90aGVyIGlzIHRo
YXQgdGhlIGludHJvc3BlY3Rpb24gZW5kcG9pbnQgZG9lc27igJl0IGhhdmUgdGhlIGNvbnRleHQg
b2YgdGhlIFJPDQogYW5kIGNsaWVudF9pZCB1bmxlc3MgeW91IGFsc28gcGFzcyB0aGUgY29kZS9S
VCBhbmQgY2xpZW50X2lkLCBhbmQgcHJvYmFibHkgY2xpZW50IGNyZWRlbnRpYWxzLiAmbmJzcDsg
Jm5ic3A7QmFzaWNhbGx5IHRoaXMgaXMgdHJ5aW5nIHRvIGludHJvc3BlY3QgdGhlIEFUIHRvIGRl
dGVybWluZSB0aGUgYXVkaWFuY2UvZHN0LiAmbmJzcDsgQnkgdGhlIHRpbWUgeW91IGJ1aWxkIGEg
bmV3IGludHJvc3BlY3Rpb24gZW5kcG9pbnQgc2VjdXJlbHkgaXQgaXMgZ29pbmcgdG8gbG9vaw0K
IGxpa2UgdGhlIHRva2VuIGVuZHBvaW50IHdpdGggYSBiaXQgbW9yZSBtZXRhIGRhdGEgYWJvdXQg
dGhlIHRva2VuIGJleW9uZCBleHBpcnkgYW5kIHNjb3Blcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHdlIHNob3VsZCBnbyBh
IGhlYWQgd2l0aCB0aGUgcmVuYW1lZCAmcXVvdDtPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2
ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCdJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGFsc28gZmluZSB3aXRoIG1ha2luZyB0aGUg
ZGVmYXVsdCBkb2N1bWVudCAnb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgJm5ic3A7YXMgbG9uZyBh
cyB3ZSBhbGxvdyBmb3IgcHJvdG9jb2wgc3BlY2lmaWMgdmFyaWF0aW9uIHNvIHRoYXQgU0NJTTIg
Y291bGQgZGVmaW5lIGEgZmlsZSBuYW1lLiAmbmJzcDsgJm5ic3A7SWYgcGVvcGxlIHdhbnQgd2Ug
Y291bGQgZG8gYSBBUEkgJm5ic3A7dG8gZmlsZSBuYW1lIHJlZ2lzdHJ5IHNvIHRoYXQgcHJvdG9j
b2wNCiBzcGVjaWZpYyBvbmVzIGNhbiBiZSBkZWZpbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgYWxsLXJlYWR5IHdvcmtpbmcg
b24gb3B0aW9uIDEgdG8gc2VjdXJlIEFULCB3ZSBuZWVkIGEgc3BlYyBsaWtlIEkgcHJvcG9zZSBp
biAyIGZvciBiZWFyZXIgdG9rZW5zLiZuYnNwOyBXZSBjYW4gYWRkIG9uZSByZXF1ZXN0IHBhcmFt
ZXRlciBhbmQgYSBiaXQgbW9yZSB0b2tlbiBtZXRhLWRhdGEgdG8gdGhlIHRva2VuIHJlc3BvbnNl
IGFuZCB0aGF0IHRha2VzIGNhcmUgb2YgdGhlIHByb2JsZW0uICZuYnNwOyBIb25lc3RseQ0KIHdl
IHByb2JhYmx5IHNob3VsZCBoYXZlIHNlcGFyYXRlZCBzY29wZSBhbmQgZGVzdGluYXRpb24gaW4g
dGhlIGZpcnN0IHBsYWNlIGFuZCByZXR1cm5lZCBib3RoIGRzdCBhbmQgc2NvcGUgaW4gdGhlIHJl
c3BvbnNlIGFsbCBhbG9uZywgc28gdGhpcyBpcyB1cGRhdGUgdGhhdCBpcyBjb25zaXN0ZW50IHdp
dGggdGhlIGVpc3RpbmcgYXJjaGl0ZWN0dXJlIG9mIE9BdXRoIDIuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxldHMga2VlcCB0aGUgdHdvIGlz
c3VlcyBzZXBhcmF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWFyIDExLCAyMDE2LCBh
dCAxMjowNyBBTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBt
aWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gQVMgYW5kIFJT
IG5lZWQgdG8gYmUgc2NvcGVkIHRvIOKAnGRvZXMgdGhpcyBSUyBhY2NlcHQgdG9rZW5zIGZyb20g
dGhpcyBBU+KAnSBhcyBhIGxpc3QgaXMgdG9vIG11Y2ggaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBi
ZSB1c2VkIGluIHRoZSB3cm9uZyB3YXk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSIxMjcyODk2NDI5X19NYWlsRW5kQ29t
cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDtPQXV0aCBbPGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzwvYT5dJm5ic3A7PGI+T24NCiBCZWhhbGYgT2YmbmJzcDs8L2I+TmF0
IFNha2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7VGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2
IDY6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVm
PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA
b3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiZuYnNwO29hdXRoICZsdDs8YSBocmVm
PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwv
YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFtPQVVUSC1XR10gV29ya2luZyBH
cm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWwsJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdodC4gU28gd2hhdCBteSBjb25kaXRpb25hbCBhcHBy
b3ZhbHMgKDExIGNvbmRpdGlvbnMgaW4gdG90YWwpIHNhaWQgd2FzIHRvIGRyb3AgdGhlIHdvcmQg
JnF1b3Q7ZGlzY292ZXJ5JnF1b3Q7IGZyb20gZXZlcnl3aGVyZS4gVGhpcyBpcyBub3QgYSBkaXNj
b3Zlcnkgc3BlYy4gVGhpcyBpcyBhIGNvbmZpZ3VyYXRpb24gbG9va3VwIHNwZWMgYXMgeW91IGNv
cnJlY3RseSBwb2ludHMgb3V0LiBTbywgSSBhbSB3aXRoIHlvdSBoZXJlLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBteSAybmQgY29uZGl0aWlvbiBpcyBlc3NlbnRpYWxs
eSBzYXlpbmcgdG8gZHJvcCBzZWN0aW9uIDMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uZSB0aGluZyB0aGF0IEkgb3Zlcmxvb2tlZCBhbmQgYW0gd2l0aCB5b3UgaXMgdGhhdCB3
ZSBuZWVkIHRvIGJlIGFibGUgdG8gZXhwcmVzcyB0aGUgQVMtUlMgcmVsYXRpb25zaGlwcy4gSSBo
YXZlIGJlZW4gcHJlYWNoaW5nIHRoaXMgaW4gdGhlIG90aGVyIHRocmVhZCBmb3Igc28gbWFueSB0
aW1lcyBhcyB5b3Uga25vdyBzbyBJIHRob3VnaHQgSSBwb2ludGVkIGl0IG91dCwgYnV0IG1pc3Nl
ZCBhcHBhcmVudGx5DQogaW4gbXkgcHJldmlvdXMgY29tbWVudC4gU28sIEkgd291bGQgYWRkIG15
IDEydGggY29uZGl0aW9uOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMi4gQSB3
YXkgdG8gZXhwcmVzcyBhIGxpc3Qgb2YgdmFsaWQgUlNzIGZvciB0aGlzIEFTIG5lZWRzIHRvIGJl
IGFkZGVkIHRvIHNlY3Rpb24gMi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVz
dCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjIwMTYtMDMtMTEgMjowOSBHTVQmIzQzOzA5OjAwIFBoaWwgSHVudCAoSURNKSAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9h
PiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SSBzdHJvbmdseSBvcHBvc2UuIDIgbWFqb3IgaXNzdWVzLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIG5vdCBzZXJ2aWNlIGRpc2NvdmVyeSB0aGlzIGlz
IGNvbmZpZ3VyYXRpb24gbG9va3VwLiBUaGUgY2xpZW50IG11c3QgaGF2ZSBhbHJlYWR5IGRpc2Nv
dmVyZWQgdGhlIG9hdXRoIGlzc3VlciB1cmkgYW5kIHRoZSByZXNvdXJjZSB1cmkuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvYmplY3RpdmUgd2FzIHRvIHByb3ZpZGUgYSBt
ZXRob2QgdG8gZW5zdXJlIHRoZSBjbGllbnQgaGFzIGEgdmFsaWQgc2V0IG9mIGVuZHBvaW50cyB0
byBwcmV2ZW50IG1pdG0gb2YgZW5kcG9pbnRzIGxpa2UgdGhlIHRva2VuIGVuZHBvaW50IHRvIHRo
ZSByZXNvdXJjZSBzZXJ2ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBk
cmFmdCBkb2VzIG5vdCBhZGRyZXNzIHRoZSBpc3N1ZSBvZiBhIGNsaWVudCBiZWluZyBnaXZlbiBh
IGJhZCBlbmRwb2ludCBmb3IgYW4gcnMuIFdoYXQgd2UgZW5kIHVwIHdpdGggaXMgYSBwcm9taXNj
dW91cyBhdXRoeiBzZXJ2aWNlIGdpdmluZyBvdXQgdG9rZW5zIHRvIGFuIHVud2l0dGluZyBjbGll
bnQuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NClBoaWw8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpP
biBNYXIgMTAsIDIwMTYsIGF0IDA4OjA2LCBWbGFkaW1pciBEemh1dmlub3YgJmx0OzxhIGhyZWY9
Im1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPC9zcGFuPjwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiYjNDM7MSB0byBtb3ZlIGZvcndhcmQg
d2l0aCB0aGVzZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiAxMC8wMy8xNiAxNzozNSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiYjNDM7MTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9uIFRodSwgTWFyIDEwLCAyMDE2IGF0IDY6
MDQgQU0sIFJvbGFuZCBIZWRiZXJnIDxhIGhyZWY9Im1haWx0bzpyb2xhbmQuaGVkYmVyZ0B1bXUu
c2UiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mbHQ7cm9sYW5k
LmhlZGJlcmdAdW11LnNlJmd0Ozwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+d3Jv
dGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy
ZT5JIHN1cHBvcnQgdGhpcyBkb2N1bWVudCBiZWluZyBtb3ZlZCBmb3J3YXJkIHdpdGggdGhlc2Ug
dHdvIGNoYW5nZXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+LSBjaGFuZ2UgbmFtZSB0byDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2
ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCdIGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+cHJvcG9z
ZWQgYnkgQnJpYW4gYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+LSB1c2UgdGhlIFVSSSBwYXRo
IHN1ZmZpeCDigJlvYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAmSBpbnN0ZWFkIG9mPG86cD48
L286cD48L3ByZT4NCjxwcmU+4oCZb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgYXMgcHJvcG9zZWQg
YnkgSnVzdGluLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwcmU+MTggZmViIDIwMTYga2wuIDE0OjQwIHNrcmV2IEhhbm5lcyBUc2Nob2ZlbmlnICZs
dDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxh
bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8
L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IaSBhbGwsPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBpcyBhIExhc3QgQ2FsbCBm
b3IgY29tbWVudHMgb24gdGhlJm5ic3A7IE9BdXRoIDIuMCBEaXNjb3Zlcnk8bzpwPjwvbzpwPjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5zcGVjaWZpY2F0aW9uOjxvOnA+PC9vOnA+PC9wcmU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv
b2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1p
ZXRmLW9hdXRoLWRpc2NvdmVyeS0wMSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9dzMlMmJpaWFXb244MUxKQ1UlMmIy
bUNQUm1BJTJickVDQkhncXlScjBPZ3FpV1NIVSUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW9hdXRoLWRpc2NvdmVyeS0wMTwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+U2luY2UgdGhpcyBkb2N1bWVudCB3YXMgb25seSBh
ZG9wdGVkIHJlY2VudGx5IHdlIGFyZSBydW5uaW5nIHRoaXMgbGFzdDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmNhbGwgZm9yICoqMyB3ZWVrcyoqLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBsZWFzZSBoYXZlIHlvdXIgY29tbWVudHMgaW4gbm8g
bGF0ZXIgdGhhbiBNYXJjaCAxMHRoLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkNpYW88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IYW5uZXMgJmFt
cDsgRGVyZWs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u
b3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZs
aXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv
bSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkx
YWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIw
TEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT7igJQgUm9s
YW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
4oCdRXZlcnlib2R5IHNob3VsZCBiZSBxdWlldCBuZWFyIGEgbGl0dGxlIHN0cmVhbSBhbmQgbGlz
dGVuLiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDtGcm9tIOKAmU9wZW4gSG91c2Ug
Zm9yIEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw
cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlz
dGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20l
N2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJ
elFYQSUyZmslMmJxUjltNVdnQTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv
bG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv
c3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3By
ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj
dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1h
biUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv
ZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0
MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekpp
WHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0
cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJk
NTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh
bXA7c2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdn
QTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286
cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQgU2Fr
aW11cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0i
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz
YSUyZiUyZm5hdC5zYWtpbXVyYS5vcmclMmYmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTZGVm1kTjdhZDBZem9ZS1NO
RiUyZkRPJTJmZkcyRUYxaGFqNWFPSGlNaWQ2VU1JJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9zcGFuPjwvYT48
YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v
cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9YktzRVZCVVhjNTI4
eWFBTUxteWNYY0wzMyUyYkZKQ1FybnE5YXN4Um81SGU4JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u
b3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZs
aXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv
bSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkx
YWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1iS3NFVkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJi
RkpDUXJucTlhc3hSbzVIZTglM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_SN1PR0301MB1645406DCCA1787C10F76B2BF5B60SN1PR0301MB1645_--


From nobody Sat Mar 12 08:19:45 2016
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 C3ACD12D6EE for ; Sat, 12 Mar 2016 08:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.109
X-Spam-Level: *
X-Spam-Status: No, score=1.109 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 66R-lp6X06qT for ; Sat, 12 Mar 2016 08:19:40 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEE512D774 for ; Sat, 12 Mar 2016 08:19:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UrkqKglTOoONof/dxlPBqKYf500KngaDo+Nyn3lwCn0=; b=mZ79umMxP3paoxZAopIcKsVsvucJZbly4QB1F3jCSfRUFRrHm2EimAAntKGHjRSGPyswj+O/H6VvxBYTtH8H4O81TaFTnf9vcdsZ5Ji7zimnpBGcFdvKGDegE2bxGhn9FK+zlNFEJ4Qq4WHjoFJKIk8PWHIBxddo4zDTn5HmFEw=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (TLS) id 15.1.427.16; Sat, 12 Mar 2016 16:19:37 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0427.020; Sat, 12 Mar 2016 16:19:37 +0000
From: Anthony Nadalin 
To: Mike Jones , Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH06DIAQfC9O0686lpsTuUfK59Sxh0AgAAqNQCAAAiJgIAAEaoAgACbQYCAAAsN0IAAxaEAgAAF5wCAAA9jAIAAdkGAgAACUgCAARk2gIAAAk+A
Date: Sat, 12 Mar 2016 16:19:37 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.46.126.7]
x-ms-office365-filtering-correlation-id: 83abd8ce-555c-459d-5f97-08d34a921bac
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 5:S1/p7I/uPchrT5T05ISrkgCfXnaI8ctcgVawi67OvZZOkgwcZvY1HmBT4wuAVlGSLiZGCxfU+pE+jr1H09lssWCen/LszVED+M2Acfj4GRpmrnPZHlPuzNgtpn18Ytd+K8Hzhj6WH2kbtWq6G9qqmw==; 24:1WQGm+XmLWbbPGoRFQnIL71w1t+6blyt7jvvZtnq0dgynQUx13dBlNeHxpDoCs7oeoDoTeiixlYOU87epgnQ0jxnvEOfKCRZ8JfDTEinXhc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; 
x-forefront-prvs: 0879599414
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(479174004)(377424004)(24454002)(2950100001)(74316001)(4326007)(5005710100001)(2906002)(5001770100001)(5008740100001)(10400500002)(66066001)(19580405001)(19300405004)(2900100001)(189998001)(19580395003)(1511001)(10290500002)(5002640100001)(15975445007)(77096005)(86362001)(11100500001)(561944003)(19625215002)(3900700001)(81166005)(122556002)(1220700001)(2561002)(16236675004)(5003600100002)(3280700002)(3660700001)(102836003)(6116002)(586003)(3846002)(790700001)(54356999)(5004730100002)(93886004)(8990500004)(1096002)(106116001)(10090500001)(87936001)(99286002)(19609705001)(76176999)(50986999)(76576001)(33656002)(2421001)(92566002)(19617315012)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234C67C9D564A763AD63B98A6B60BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2016 16:19:37.6521 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 16:19:43 -0000

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

V2UgYWdyZWVkIHVwb24gYSBkaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbiB0aGF0IHRoZSBXRyB3b3Vs
ZCB3b3JrIG9uLCB3ZSBkaWQgbm90IGFncmVlIHVwb24gd2hhdCB0aGlzIGhhcyB0dXJuZWQgb3V0
IHRvIGFjdHVhbGx5IGJlLCBzbyBhdCB0aGUgbWluaW11bSB0aGUgY2hhaXJzIHNob3VsZCBjYWxs
IGZvciBhZG9wdGlvbiBvZiBhIEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIHNwZWNpZmlj
YXRpb24gYW5kIHdlIGNhbiBjb250aW51ZSB0byB3b3JrIG9uIGEgRGlzY292ZXJ5IHNwZWNpZmlj
YXRpb24NCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogU2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2
IDg6MDYgQU0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT47IEJy
aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IEpvaG4gQnJhZGxleSA8
dmU3anRiQHZlN2p0Yi5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog
UkU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2Nv
dmVyeQ0KDQpUaGUgZHJhZnQgZW5hYmxlcyBlYXN5IGNvbmZpZ3VyYXRpb24gb2YgT0F1dGggY2xp
ZW50cyB3aXRoIGFuIEFTLiAgRm9yIGluc3RhbmNlLCB0aGUgTWljcm9zb2Z0IOKAnEFEQUzigJ0g
T0F1dGggY2xpZW50IHNvZnR3YXJlIHVzZXMgQVMgbWV0YWRhdGEgaW4gdGhpcyBmb3JtYXQgYXMg
YW4gaW5wdXQgYXQgY2xpZW50IGNvbmZpZ3VyYXRpb24gdGltZS4NCg0KQXMgYSBzaWRlIGJlbmVm
aXQsIGhhdmluZyB0aGlzIHN0YW5kYXJkIEFTIG1ldGFkYXRhIGZvcm1hdCBhbmQgcmV0dXJuaW5n
IHRoZSBpc3N1ZXIgVVJMIHBlciB0aGUgTWl4LVVwIE1pdGlnYXRpb24gZHJhZnQgd2lsbCBhbHNv
IGVuYWJsZSBjbGllbnRzIHRvIHZhbGlkYXRlIHRoYXQgdGhleSBhcmUgdXNpbmcgYSBjb25zaXN0
ZW50IHNldCBvZiBBUyBlbmRwb2ludHMgYW5kIGluZm9ybWF0aW9uLiAgQnV0IGV2ZW4gd2l0aG91
dCB0aGUgbWl0aWdhdGlvbiBiZW5lZml0cywgdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIGJlbmVm
aXQgaXMgdGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p
a2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgQW50aG9ueSBOYWRhbGluDQpTZW50OiBGcmlkYXksIE1hcmNoIDExLCAyMDE2IDM6MjUg
UE0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv
OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj47IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0
Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdvcmtp
bmcgR3JvdXAgTGFzdCBDYWxsIG9uIE9BdXRoIDIuMCBEaXNjb3ZlcnkNCg0KRGlzYWdyZWUsIHdo
YXQgcHVycG9zZSBpcyB0aGlzIGFjdGl2aXR5IHNvbHZpbmcgdGhlbiwgaXQgd2FzIGJlaW5nIHB1
c2hlZCBhcyB3aGF0IHdhcyBuZWVkIHRvIHNvbHZlIHRoZSBNaXgtdXAsIGJ1dCB0aGF0IGlzIG5v
dCB0cnVlLiBTbyBub3cgeW91IGFyZSBzdWdnZXN0aW5nIGEgY2hhbmdlIGluIHNjb3BlIGFuZCBu
b3QgZGVhbGluZyB3aXRoIGRpc2NvdmVyeS4NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IEZyaWRh
eSwgTWFyY2ggMTEsIDIwMTYgMzoxMSBQTQ0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0
Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFdvcmtp
bmcgR3JvdXAgTGFzdCBDYWxsIG9uIE9BdXRoIDIuMCBEaXNjb3ZlcnkNCg0KSSB0ZW5kIHRvIGFn
cmVlIHdpdGggSm9obiB0aGF0IGFkZHJlc3NpbmcgdGhlIGNvbmNlcm5zIFBoaWwgcmFpc2VzIHNo
b3VsZCBiZSBwYXJ0IG9mIChleHRlbnNpb24gdG8pIHRoZSBjb3JlIHByb3RvY29sLiAgQW5kIHRo
YXQgdGhvc2Uga2luZHMgb2YgY29uY2VybnMgZG9uJ3QgbWFuaWZlc3QgaW4gdGhlIHdheSBPQXV0
aCBpcyB0eXBpY2FsbHkgZGVwbG95ZWQgbm93Lg0KDQpUaGUgaG9wZWZ1bGx5IHNvb24gdG8gYmUg
bmFtZWQgIk9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSIgc2hvdWxkIGtl
ZXAgaXQncyBzY29wZSB0byB0aGUgcHVibGlzaGluZyBvZiBhdXRob3JpemF0aW9uIHNlcnZlciBt
ZXRhZGF0YS4gVGhlIGFjdCBvZiBkb2luZyBkaXNjb3ZlcnkgaXMgYmV5b25kIGl0cyBzY29wZSBh
bmQgc28gaXMgdHJ5aW5nIHRvIHByZXZlbnQgYSBjbGllbnQgZnJvbSBwcmVzZW50aW5nIGEgdG9r
ZW4gdG8gc29tZXBsYWNlIGl0IHNob3VsZG4ndC4NCg0KT24gRnJpLCBNYXIgMTEsIDIwMTYgYXQg
OTowOCBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZl
N2p0Yi5jb20+PiB3cm90ZToNCklubGluZQ0KT24gTWFyIDExLCAyMDE2LCBhdCAxMjoxMyBQTSwg
UGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20+PiB3cm90ZToNCg0KSm9obg0KDQpJbiBtYW55IGNhc2UgYWxsIHRoZSBBUyBoYXMg
dG8gY2hlY2sgaXMgdGhlIGRvbWFpbiBuYW1lIGNvbXBvbmVudCB0byBjaGVjayBmb3IgbWl0bS4N
Cg0KUE9QIGFuZCB0aGUgb3RoZXIgc29sbnMgYXJlIGRyYW1hdGljYWxseSBtb3JlIGNvbXBsZXgg
dGhhbiBhIHNpbXBsZSBjaGVjay4NCg0KSSB3YXMgcHJvcG9zaW5nIGRpbmcgdGhhdCBjaGVjayBh
dCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBvciB0b2tlbiBlbmRwb2ludCBhcyBwYXJ0IG9m
IEFUIGlzc3VhbmNlLg0KDQpJdCBpcyB1cCB0byB0aGUgQVMgaG93IG11Y2ggb2YgdGhlIHBhdGgg
dG8gdmFsaWRhdGUgYW5kIG9yIHB1dCBpbiB0aGUgYXVkIG9yIGRzdC4NCg0KDQoNCkkgc2VlIGl0
IGFzIHBhcnQgb2YgdGhlIGRpc2NvdmVyeShiYWQgbmFtZSBhc2lkZSkgcHJvYmxlbSBiZWNhdXNl
IHdlIGRpc2N1c3NlZCB0aGF0IGlmIGEgY2xpZW50IGZpbmRzIGFwcC5leGFtcGxlLmNvbTxodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJm
JTJmYXBwLmV4YW1wbGUuY29tJTJmJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu
Y29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFm
OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9ZmlTOGY2MHlwaVhoeU0wcVZUZXFsJTJiJTJiT3pI
MndibUVDUUU3SjVUdEdQUU0lM2Q+IGhvdyBkbyB3ZSBlbnN1cmUgaXQgZ2V0cyBhIGNvbXBsZXRl
IHNldCBvZiBvYXV0aCBlbmRwb2ludHMgYXMgYSB2YWxpZCBzZXQgb2YgZW5kcG9pbnRzLS10aGF0
IGEgaGFja2VyIGhhcyBub3QgaW5zZXJ0ZWQgb25lIG9mIHRoZWlyIG93biBlbmRwb2ludHMuIFRo
ZSBtb3N0IGltcG9ydGFudCBlbmRwb2ludCB0byBnZXQgcmlnaHQgaXMgZW5zdXJpbmcgdGhlIHJl
c291cmNlIHNlcnZlciAoYW5kIG9wdGlvbmFsbHkgdGhlIHBhdGgpIGlzIHRoZSBjb3JyZWN0IG9u
ZS4gV2UgY2FuJ3QgcmVhbGx5IGRlZmluZSByZXNvdXJjZSBkaXNjb3ZlcnkgYnV0IHdlIGNhbiB2
YWxpZGF0ZSBpdCB0byBzb21lIGRlZ3JlZS4NCg0KSSB0aGluayBpdCBpcyBwYXJ0IG9mIGNvcmUg
cHJvdG9jb2wgc2VjdXJpdHkgYW5kIHNob3VsZC9tdXN0IG5vdCByZXF1aXJlIGRpc2NvdmVyeS4N
Cg0KV2hhdCBpcyBhcHAuZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0
aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5leGFtcGxlLmNvbSZkYXRhPTAx
JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhk
MzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWpB
c1pRZUNoSiUyYlIxbGJ5Qm9WS3doZUlZaTNQaVdMcnElMmJ4RExicVU2cnhrJTNkPiA/DQoNCklm
IGl0IGlzIHRoZSByZXNvdXJjZSB0aGVuIHRoZSBjbGllbnQgd291bGQgYmUgcHJlY29uZmlndXJl
ZCBmb3IgaXTigJlzIEFTIG91dCBvZiBiYW5kIG9yIG9wdGlvbmFsbHkgd291bGQgZG8gZGlzY292
ZXJ5IG9uIHRoZSBpc3N1ZXIgdXJpIHRoYXQgeW91IGFkbWl0IG5lZWRzIHRvIGJlIGNvbmZpZ3Vy
ZWQgb3V0IG9mIGJhbmQgc29tZSB3YXkgKG5vdGUgZGlzY292ZXJ5IGlzIG9wdGlvbmFsKQ0KDQpJ
biB0aGUgQVMgbWV0YS1kYXRhIGRyYWZ0IGl0IHdvdWxkIGRvIGEgZ2V0IG9uIGEgd2VsbCBrbm93
biBmaWxlIHRoYXQgd291bGQgaGF2ZSBjb25maWd1cmF0aW9uIGZvciB0aGUgQVMsIGJ1dCBub3Qg
dGhlIFJTLCB0aG91Z2ggc29tZSBBUEkgbWF5IG9wdGlvbmFsbHkgbGlzdCBhIEFQSSBlbmRwb2lu
dCBsaWtlIGNvbm5lY3QgaGFzLg0KDQpUaGUgY2xpZW50IHRoZW4gbWFrZXMgYSBhdXRob3JpemF0
aW9uIHJlcXVlc3QgKGFmdGVyIHJlZ2lzdGVyaW5nIG91dCBvZiBiYW5kIG9yIGR5bmFtaWNhbGx5
KS4NCkFzIHBhcnQgb2YgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBmb3IgaW1wbGljaXQgaXQg
Y291bGQgcHJvdmlkZSB0aGUgYXVkL2RzdCB0aGF0IGl0IHdhbnRzIHRoZSB0b2tlbiBmb3IuDQpJ
ZiB0aGF0IGlzIG5vdCBzZW50IHRoZW4gdGhlIGF1ZC9kc3QgYXJlIGltcGxpY2l0IGluIHRoZSBz
Y29wZXMuDQoNClRoZSBjbGllbnQgZ2V0cyBiYWNrIGEgQVQgd2l0aCBhIGxpc3Qgb2Ygc2NvcGVz
IGdyYW50ZWQsIGF1ZC9kc3QgYWxsb3dlZCBhbmQgdGltZSB0byBsaXZlIGZvciB0aGUgdG9rZW4g
KG9uZSBleHRyYSB0aGluZyByZXR1cm5lZCkNCg0KVGhpcyBkb2VzbuKAmXQgcmVxdWlyZSBhbnkg
ZGlzY292ZXJ5ICh5ZXMgdGhlcmUgaXMgYSBvcHRpb25hbCBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5
IGJ1dCBub3QgcmVxdWlyZWQpDQoNCkkgcHJlZmVyIHRvIGZpeCB0aGUgUlMgbWFuIGluIHRoZSBt
aWRkbGUgaXNzdWUgYXMgcGFydCBvZiB0aGUgcHJvdG9jb2wgYW5kIG5vdCBwYXJ0IG9mIGRpc2Nv
dmVyeSB0aGF0IHNob3VsZCByZW1haW4gb3B0aW9uYWwuDQoNCkkgaG9uZXN0bHkgZG9u4oCZdCBx
dWl0ZSBrbm93IGhvdyB0aGUgY2xpZW50IGxlYXJucyBhYm91dCB0aGlzIGJhZCBSUyBhbmQgc3Rh
cnRzIHRhbGtpbmcgdG8gaXQsIHNvIHRoaXMgbWF5IGJlIGEgc29sdXRpb24gdG8gYSBwcm9ibGVt
IHRoYXQgZG9lc27igJl0IHlldCBleGlzdC4gICBUaGUgb25lIHBsYWNlIHRoaXMgaXMgcG9zYWJs
ZSBpcyBpZiB0aGUgcmVnaXN0cmF0aW9uIGZvciB0aGUgY2xpZW50IGlzIGNvbXByb21pc2VkLiAg
SG93ZXZlciB3ZSBhcmUgZGlzY3Vzc2luZyBvdGhlciBtaXRpZ2F0aW9ucyBmb3IgdGhhdCB0aGF0
IGFsc28gZXhwbGljaXRseSBkbyBub3QgcmVxdWlyZSBkaXNjb3ZlcnkuDQoNCkpvaG4gQi4NCg0K
DQpJIGFtIG5vdCBzdHVjayBvbiB3ZWJmaW5nZXIgb3Igd2VsbC1rbm93bi4gQmVjYXVzZSB0aGlz
IGlzIGNvbmZpZyBtYXliZSBpdCBzaG91bGQgYmUgYW4gb2F1dGggZW5kcG9pbnQuDQoNClBoaWwN
Cg0KT24gTWFyIDExLCAyMDE2LCBhdCAwNjo1MSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRi
LmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkkgdGhpbmsgUGhpbCBpcyBw
cm9wb3Npbmcgc29tZXRoaW5nIGRpZmZlcmVudC4gICBTaG91bGQgdGhlIGNsaWVudCBzZW5kIGEg
dG9rZW4gZnJvbSB0aGlzIEFTIHRvIHRoYXQgUlMuDQoNCkhpcyBnb2FsIGlzIHRvIHByZXZlbnQg
bWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrcyB3aGVyZSBhIGJhZCBSUyBnZXRzIGEgQVQgdGhhdCBp
cyBhdWRpYW5jZWQgdG8vYWNjZXB0ZWQgYnkgYW5vdGhlciBSUy4NCg0KVGhhdCBpcyBzZXBhcmF0
ZSBmcm9tIHRoZSBxdWVzdGlvbiBvZiBpZiBhIFJTIGFjY2VwdHMgdG9rZW5zIGZyb20gYSBnb29k
IEFTLiAgIEEgYmFkIEFTIHdvdWxkIGFsd2F5cyBzYXkgeWVzLg0KDQpXZSBuZWVkIHRvIGJlIGNh
cmVmdWwgb2Ygd2hhdCBpZiBhbnl0aGluZyB0aGUgUlMgcHJvdmlkZXMgdG8gdGhlIGNsaWVudCBh
cyBtZXRhLWRhdGEgd2l0aG91dCB2YWxpZGF0aW9uLg0KDQpDdXJyZW50bHkgdGhlIGNsaWVudCBj
YW4gcHJvdmlkZSBhIGxpc3Qgb2Ygc2NvcGVzIHJlcXVpcmVkIHRvIGdldCBhY2Nlc3MuICAgSSBw
ZXJzb25hbGx5IGZlZWwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGFsc28gaW5jbHVkZSBpbiB0aGUg
dW5hdXRoZW50aWNhdGVkIGVycm9yIHJlc3BvbnNlIGFuIGluZGljYXRpb24gb2Ygd2hhdCBBUEkg
dGhlIHJlc291cmNlIHN1cHBvcnRzLiAgU2F5IOKAnHNjaW0y4oCdIGFzIGFuIGV4YW1wbGUuICAg
SSBkb27igJl0IHRoaW5rIGFkZGluZyB0aGF0IGlzIGhvd2V2ZXIgYSBoaWdoIHByaW9yaXR5IGFz
IG1vc3QgaWYgYWxsIGNsaWVudHMga25vdyB3aGF0IEFQSSB0aGV5IGV4cGVjdC4gICBJdCBtaWdo
dCBiZSB1c2VmdWwgaWYgYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlIGlmIGEgY2xpZW50IHdl
cmUgdG8gYmUgZ2l2ZW4gYSBSUyBVUkkgaXQgY291bGQgY2hlY2sgdG8gc2VlIGlmIGl0IGlzIGEg
cHJvdG9jb2wgdGhhdCBpdCBzdXBwb3J0cyBiZWZvcmUgYm90aGVyaW5nIHdpdGggT0F1dGguICAg
IEkgZXhwZWN0IHRoYXQgYSBsb3Qgb2YgcGVvcGxlIHdpbGwgd2FudCB0aGF0IGxlZnQgdG8gdGhl
IEFQSSBkZWZpbml0aW9uLiAgIEkgdGhpbmsgd2UgY2FuIHRhbGsgYWJvdXQgaXQgYnV0IHJhdGUg
dGhpcyBsb3cgcHJpb3JpdHkuDQoNCkkgYWdyZWUgdGhhdCB0aGUgUlMgZ2l2aW5nIG91dCBhIGxp
c3Qgb2YgQVMgdGhhdCBpdCB0cnVzdHMgaXMgYSBnZW5lcmFsbHkgYmFkIGlkZWEuICBJIGhvcGUg
dGhhdCBpcyBub3Qgb24gdGhlIHRhYmxlLg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhhdCBwcmV2ZW50
aW5nIGEgY2xpZW50IGZyb20gc2VuZGluZyBhIHRva2VuIHRvIHRoZSB3cm9uZyBSUyBpcyBwYXJ0
IG9mIGEgQVMgbWV0YS1kYXRhIGRpc2NvdmVyeSBwcm9ibGVtLg0KDQpJIGRvIGhvd2V2ZXIgdGhp
bmsgdGhhdCBpdCBpcyBpbXBvcnRhbnQuDQoNCldlIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMg
YXMgYSBzZXBhcmF0ZSBwcm9ibGVtIHRvIEFTIG1ldGEtZGF0YSBkaXNjb3Zlcnkgd2hlcmUgdGhl
IGVuZHBvaW50cyBvZiB0aGUgQVMgYW5kIGl04oCZcyBjb25maWd1cmF0aW9uIGFyZSBkaXNjb3Zl
cnkuICAgU29ycnkgZm9yIHBlcmhhcHMgc3RhdGluZyB0aGUgb2J2aW91cywgYnV0IHRoZSBSUyBp
cyBleHBsaWNpdGx5IG5vdCBwYXJ0IG9mIHRoZSBBUyBpbiBPQXV0aCAyLiAgIFN0YXJ0aW5nIGlu
IFdBUCB0aGF0IHdhcyBhIGNvcmUgcHJpbmNpcGFsLg0KDQpTbyB3ZSBoYXZlIGEgbnVtYmVyIG9m
IG9wdGlvbnMgdG8gYWRkcmVzcyB0aGUgUlMgdG9rZW4gbGVha2FnZSB2aWEgTWlUTSBhdHRhY2tz
Lg0KDQoxKSBQb1AgYm91bmQgdG9rZW5zLiAgSWYgdGhleSBhcmUgYm91bmQgdG8gdGhlIFRMUyBj
aGFubmVsIGJ5IG11dHVhbCBUTFMgb3IgVG9rZW4gYmluZGluZyB0aGV5IGNhbm5vdCBiZSByZXBs
YXllZC4gIFNpZ25lZCBtZXNzYWdlcyB3aGVyZSB0aGUgc2lnbmluZyBjb3ZlcnMgdGhlIFJTIEhv
c3QgYW5kIHBhdGggY29tcG9uZW50cywgIGFsc28gd291bGQgd29yay4NCg0KMikgSGF2ZSB0aGUg
QVMgYXVkaWVuY2UgcmVzdHJpY3QgdGhlIHJlc291cmNlcyB0aGUgQVQgaXMgZ29vZCBhdC4gKEFU
IHNob3VsZCBiZSBkb2luZyB0aGF0IG5vdykNCkluIHRoZSB0b2tlbiByZXNwb25zZSBpbmNsdWRl
IHRoZSBsaXN0IG9mIGF1ZGllbmNlL3MgdGhlIHRva2VuIGlzIHByZXNlbnRhYmxlIGF0LiAgVGhl
IGNsaWVudCB3b3VsZCB0aHJvdyBhbiBlcnJvciBpZiB0aGUgUlMgaXQgaW50ZW5kcyB0byBzZW5k
IHRoZSB0b2tlbiB0byBpcyBub3Qgb24gdGhlIGxpc3QuICAgVGhlIFJTIHRoZSB0b2tlbiBpcyBn
b29kIGF0IG1pZ2h0IGNoYW5nZSBiYXNlZCBvbiBzY29wZXMsIGNsaWVudF9pZCBhbmQgcmVzb3Vy
Y2Ugb3duZXIuICAgVGhpcyBpcyB0aGUgcGxhY2Ugd2hlcmUgYWxsIG9mIHRoYXQgY29tZXMgdG9n
ZXRoZXIuICAgSW4gc29tZSBjYXNlcyB0aGUgUlMgYW5kIEFTIG1pZ2h0IG5vdCBoYXZlIGEgcHJl
LWVzdGFibGlzaGVkIHJlbGF0aW9uc2hpcC4gICBUaGUgY2xpZW50IHNob3VsZCBzZW5kIHRoZSBS
UyBiYXNlIFVSSSB0byB0aGUgQVMgYXMgcGFydCBvZiB0aGUgcmVxdWVzdC4gIFRoZSBBUyBjYW4g
dXNlIHRoYXQgdG8gYXVkaWVuY2UgcmVzdHJpY3QgdGhlIEFUIGFuZCBpc3N1ZSB0aGUgQVQgb3Ig
cmVmdXNlIHRvIGlzc3VlIHRoZSBBVCBiYXNlZCBvbiBwb2xpY3kuDQpJdCBjYW4gYWxzbyB1c2Ug
dGhlIGF1ZGllbmNlIGluIHRoZSByZXF1ZXN0IHRvIGRvd24gYXVkaWVuY2UgdGhlIEFUIGlmIHRo
ZSBkZWZhdWx0IGlzIHRvIGhhdmUgbXVsdGlwbGUgYXVkaWVuY2VzLiAgICBXZSBtYXkgd2FudCB0
byB1c2UgYSB0ZXJtIG90aGVyIHRoYW4gYXVkaWVuY2UgZm9yIHRoaXMgbGlrZSByZXNvdXJjZSBv
ciBkZXN0aW5hdGlvbi4gIEl0IGlzIGEgYXVkaWVuY2UgYnV0IHRoYXQgdGVybSBtaWdodCBjb25m
dXNlIHBlb3BsZSB3aXRoIEFULg0KDQpXZSBkaWQgdGFsayBhYm91dCBicmVha2luZyBhdWRpZW5j
ZSBvdXQgb2YgUE9QIGtleSBkaXN0cmlidXRpb24sIGFuZCBCcmlhbiBDYW1wYmVsbCBkaWQgYSBk
cmFmdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0
NGp3dDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o
dHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWNhbXBiZWxsLW9hdXRo
LWRzdDRqd3QmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1
ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk
YjQ3JTdjMSZzZGF0YT1TVHIlMmI0a3JkMWh5OGg2ZUhPQ0xoMVB6UWFLTVVoV2xLVjJpJTJmQ0ww
SzFTUSUzZD4uDQoNClRvIGRvIHRoaXMgd2UgY291bGQgdGFrZSBkc3Q0and0IGFuZCBhZGQgYW5v
dGhlciBzcGVjIHRoYXQgYWRkcyBhIG5ldyBkc3QgcGFyYW1ldGVyIHRvIHRoZSB0b2tlbiBhbmQg
YXV0aG9yaXphdGlvbiBlbmRwb2ludHMgcmVxdWVzdHMgVGhhdCB3b3VsZCBiZSBhIHNwYWNlIHNl
cGFyYXRlZCBsaXN0IG9mIGRzdCB2YWx1ZXMuICBhbmQgaW4gdGhlIHJlc3BvbnNlIGZyb20gdGhl
IHRva2VuIGVuZHBvaW50IHdvdWxkIGJlIGEgSlNPTiBhcnJheSBvZiBkc3QgdmFsdWVzLg0KDQoz
KSBIYXZlIHRoZSBBUyBhbHdheXMgcmV0dXJuIGFsbCB0aGUgbGlzdCBvZiBhbGwgUlMgdGhlIHRv
a2VuIGNhbiBiZSB1c2VkIGF0IChiYXNpY2FsbHkgTmF0J3MgbGluayByZWxhdGlvbnNoaXAgcHJv
cG9zYWwpLiAgSXQgbmVlZHMgYSB3YXkgdG8gaGFuZGxlDQpkb3duIGRlc3RpbmF0aW9uaW5nIG9m
IEFUIGFuZCB0byBhbGxvdyBmb3IgdW4tY29uZmlndXJlZCBSUyB0aGF0IGl0IG1pZ2h0IGlzc3Vl
IGEgdG9rZW4gZm9yLiAgU28gY291bGQgYmUgY29tYmluZWQgd2l0aCBkc3QgZnJvbSAyLiAgQmFz
aWNhbGx5IHJldHVybmluZyB0aGUgYWNjZXB0YWJsZSBkZXN0aW5hdGlvbnMgYXMgbGluayBoZWFk
ZXJzIHZzIEpTIGluIHRoZSByZXNwb25zZSBpcyBtb3N0bHkgYSBzdHlsZSBpc3N1ZSB0aGF0IG90
aGVyIHBlb3BsZSBjYW4gYmlrZSBzaGVkLg0KDQoNCjQpIFRyeWluZyB0byBhZGQgYWxsIHRoZSBS
UyB0byB0aGUgQVMgZGlzY292ZXJ5IGRvY3VtZW50LiAgVGhpcyBzZWVtcyBpbXByYWN0aWNhbCBh
cyB0aGVyZSB3b3VsZCBiZSBtdWx0aXBsZSBwcm90b2NvbHMgYW5kIGRvZXNu4oCZdCBhZGRyZXNz
IHVuLWNvbmZpZ3VyZWQgUlMuDQoNCjUpIFNvbWUgbmV3IEFTIGVuZHBvaW50IHRoYXQgdGhlIGNs
aWVudCBjb3VsZCBpbnRyb3NwZWN0IHRoZSBSUyBVUkkgYW5kIGdldCBiYWNrIG1ldGFkYXRhIGFi
b3V0IGlmIHRoZSBjbGllbnQgc2hvdWxkIHNlbmQgdG9rZW5zIHRoZXJlLg0KICAgIEEgY291cGxl
IG9mIHByb2JsZW1zIHdpdGggdGhpcy4gIFRoZSBmaXJzdCBpcyB0aGF0IGl0IHdvdWxkIG5vdCBz
dXBwb3J0IHVuLWNvbmZpZ3VyZWQgUlMgdW5sZXNzIHlvdSBhZGQgZHN0IHRvIHRoZSB0b2tlbiBh
bmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludHMuICAgVGhlIG90aGVyIGlzIHRoYXQgdGhlIGludHJv
c3BlY3Rpb24gZW5kcG9pbnQgZG9lc27igJl0IGhhdmUgdGhlIGNvbnRleHQgb2YgdGhlIFJPIGFu
ZCBjbGllbnRfaWQgdW5sZXNzIHlvdSBhbHNvIHBhc3MgdGhlIGNvZGUvUlQgYW5kIGNsaWVudF9p
ZCwgYW5kIHByb2JhYmx5IGNsaWVudCBjcmVkZW50aWFscy4gICAgQmFzaWNhbGx5IHRoaXMgaXMg
dHJ5aW5nIHRvIGludHJvc3BlY3QgdGhlIEFUIHRvIGRldGVybWluZSB0aGUgYXVkaWFuY2UvZHN0
LiAgIEJ5IHRoZSB0aW1lIHlvdSBidWlsZCBhIG5ldyBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IHNl
Y3VyZWx5IGl0IGlzIGdvaW5nIHRvIGxvb2sgbGlrZSB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBh
IGJpdCBtb3JlIG1ldGEgZGF0YSBhYm91dCB0aGUgdG9rZW4gYmV5b25kIGV4cGlyeSBhbmQgc2Nv
cGVzLg0KDQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGdvIGEgaGVhZCB3aXRoIHRoZSByZW5hbWVkICJP
QXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ5IE1ldGFkYXRh4oCdDQpJIGFt
IGFsc28gZmluZSB3aXRoIG1ha2luZyB0aGUgZGVmYXVsdCBkb2N1bWVudCAnb3BlbmlkLWNvbmZp
Z3VyYXRpb27igJkgIGFzIGxvbmcgYXMgd2UgYWxsb3cgZm9yIHByb3RvY29sIHNwZWNpZmljIHZh
cmlhdGlvbiBzbyB0aGF0IFNDSU0yIGNvdWxkIGRlZmluZSBhIGZpbGUgbmFtZS4gICAgSWYgcGVv
cGxlIHdhbnQgd2UgY291bGQgZG8gYSBBUEkgIHRvIGZpbGUgbmFtZSByZWdpc3RyeSBzbyB0aGF0
IHByb3RvY29sIHNwZWNpZmljIG9uZXMgY2FuIGJlIGRlZmluZWQuDQoNCldlIGFyZSBhbGwtcmVh
ZHkgd29ya2luZyBvbiBvcHRpb24gMSB0byBzZWN1cmUgQVQsIHdlIG5lZWQgYSBzcGVjIGxpa2Ug
SSBwcm9wb3NlIGluIDIgZm9yIGJlYXJlciB0b2tlbnMuICBXZSBjYW4gYWRkIG9uZSByZXF1ZXN0
IHBhcmFtZXRlciBhbmQgYSBiaXQgbW9yZSB0b2tlbiBtZXRhLWRhdGEgdG8gdGhlIHRva2VuIHJl
c3BvbnNlIGFuZCB0aGF0IHRha2VzIGNhcmUgb2YgdGhlIHByb2JsZW0uICAgSG9uZXN0bHkgd2Ug
cHJvYmFibHkgc2hvdWxkIGhhdmUgc2VwYXJhdGVkIHNjb3BlIGFuZCBkZXN0aW5hdGlvbiBpbiB0
aGUgZmlyc3QgcGxhY2UgYW5kIHJldHVybmVkIGJvdGggZHN0IGFuZCBzY29wZSBpbiB0aGUgcmVz
cG9uc2UgYWxsIGFsb25nLCBzbyB0aGlzIGlzIHVwZGF0ZSB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0
aCB0aGUgZWlzdGluZyBhcmNoaXRlY3R1cmUgb2YgT0F1dGggMi4NCg0KTGV0cyBrZWVwIHRoZSB0
d28gaXNzdWVzIHNlcGFyYXRlLg0KDQpKb2huIEIuDQoNCg0KDQoNCk9uIE1hciAxMSwgMjAxNiwg
YXQgMTI6MDcgQU0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0
bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KVGhlIHJlbGF0aW9uc2hpcCBiZXR3
ZWVuIEFTIGFuZCBSUyBuZWVkIHRvIGJlIHNjb3BlZCB0byDigJxkb2VzIHRoaXMgUlMgYWNjZXB0
IHRva2VucyBmcm9tIHRoaXMgQVPigJ0gYXMgYSBsaXN0IGlzIHRvbyBtdWNoIGluZm9ybWF0aW9u
IHRoYXQgY291bGQgYmUgdXNlZCBpbiB0aGUgd3Jvbmcgd2F5DQoNCkZyb206IE9BdXRoIFttYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5hdCBTYWtpbXVyYQ0KU2Vu
dDogVGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2IDY6MjUgUE0NClRvOiBQaGlsIEh1bnQgKElETSkg
PHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpDYzog
b2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292
ZXJ5DQoNClBoaWwsDQoNClJpZ2h0LiBTbyB3aGF0IG15IGNvbmRpdGlvbmFsIGFwcHJvdmFscyAo
MTEgY29uZGl0aW9ucyBpbiB0b3RhbCkgc2FpZCB3YXMgdG8gZHJvcCB0aGUgd29yZCAiZGlzY292
ZXJ5IiBmcm9tIGV2ZXJ5d2hlcmUuIFRoaXMgaXMgbm90IGEgZGlzY292ZXJ5IHNwZWMuIFRoaXMg
aXMgYSBjb25maWd1cmF0aW9uIGxvb2t1cCBzcGVjIGFzIHlvdSBjb3JyZWN0bHkgcG9pbnRzIG91
dC4gU28sIEkgYW0gd2l0aCB5b3UgaGVyZS4NCg0KQWxzbywgbXkgMm5kIGNvbmRpdGlpb24gaXMg
ZXNzZW50aWFsbHkgc2F5aW5nIHRvIGRyb3Agc2VjdGlvbiAzLg0KDQpPbmUgdGhpbmcgdGhhdCBJ
IG92ZXJsb29rZWQgYW5kIGFtIHdpdGggeW91IGlzIHRoYXQgd2UgbmVlZCB0byBiZSBhYmxlIHRv
IGV4cHJlc3MgdGhlIEFTLVJTIHJlbGF0aW9uc2hpcHMuIEkgaGF2ZSBiZWVuIHByZWFjaGluZyB0
aGlzIGluIHRoZSBvdGhlciB0aHJlYWQgZm9yIHNvIG1hbnkgdGltZXMgYXMgeW91IGtub3cgc28g
SSB0aG91Z2h0IEkgcG9pbnRlZCBpdCBvdXQsIGJ1dCBtaXNzZWQgYXBwYXJlbnRseSBpbiBteSBw
cmV2aW91cyBjb21tZW50LiBTbywgSSB3b3VsZCBhZGQgbXkgMTJ0aCBjb25kaXRpb246DQoNCjEy
LiBBIHdheSB0byBleHByZXNzIGEgbGlzdCBvZiB2YWxpZCBSU3MgZm9yIHRoaXMgQVMgbmVlZHMg
dG8gYmUgYWRkZWQgdG8gc2VjdGlvbiAyLg0KDQpCZXN0LA0KDQpOYXQNCg0KMjAxNi0wMy0xMSAy
OjA5IEdNVCswOTowMCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0
bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+Og0KSSBzdHJvbmdseSBvcHBvc2UuIDIgbWFqb3IgaXNz
dWVzLg0KDQpUaGlzIGlzIG5vdCBzZXJ2aWNlIGRpc2NvdmVyeSB0aGlzIGlzIGNvbmZpZ3VyYXRp
b24gbG9va3VwLiBUaGUgY2xpZW50IG11c3QgaGF2ZSBhbHJlYWR5IGRpc2NvdmVyZWQgdGhlIG9h
dXRoIGlzc3VlciB1cmkgYW5kIHRoZSByZXNvdXJjZSB1cmkuDQoNClRoZSBvYmplY3RpdmUgd2Fz
IHRvIHByb3ZpZGUgYSBtZXRob2QgdG8gZW5zdXJlIHRoZSBjbGllbnQgaGFzIGEgdmFsaWQgc2V0
IG9mIGVuZHBvaW50cyB0byBwcmV2ZW50IG1pdG0gb2YgZW5kcG9pbnRzIGxpa2UgdGhlIHRva2Vu
IGVuZHBvaW50IHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIuDQoNClRoZSBkcmFmdCBkb2VzIG5vdCBh
ZGRyZXNzIHRoZSBpc3N1ZSBvZiBhIGNsaWVudCBiZWluZyBnaXZlbiBhIGJhZCBlbmRwb2ludCBm
b3IgYW4gcnMuIFdoYXQgd2UgZW5kIHVwIHdpdGggaXMgYSBwcm9taXNjdW91cyBhdXRoeiBzZXJ2
aWNlIGdpdmluZyBvdXQgdG9rZW5zIHRvIGFuIHVud2l0dGluZyBjbGllbnQuDQoNClBoaWwNCg0K
T24gTWFyIDEwLCAyMDE2LCBhdCAwODowNiwgVmxhZGltaXIgRHpodXZpbm92IDx2bGFkaW1pckBj
b25uZWN0MmlkLmNvbTxtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20+PiB3cm90ZToNCisx
IHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZXNlDQpPbiAxMC8wMy8xNiAxNzozNSwgQnJpYW4gQ2Ft
cGJlbGwgd3JvdGU6DQoNCisxDQoNCg0KDQpPbiBUaHUsIE1hciAxMCwgMjAxNiBhdCA2OjA0IEFN
LCBSb2xhbmQgSGVkYmVyZyA8cm9sYW5kLmhlZGJlcmdAdW11LnNlPjxtYWlsdG86cm9sYW5kLmhl
ZGJlcmdAdW11LnNlPg0KDQp3cm90ZToNCg0KDQoNCkkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IGJl
aW5nIG1vdmVkIGZvcndhcmQgd2l0aCB0aGVzZSB0d28gY2hhbmdlczoNCg0KDQoNCi0gY2hhbmdl
IG5hbWUgdG8g4oCcT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVyeSBNZXRh
ZGF0YeKAnSBhcw0KDQpwcm9wb3NlZCBieSBCcmlhbiBhbmQNCg0KLSB1c2UgdGhlIFVSSSBwYXRo
IHN1ZmZpeCDigJlvYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlcuKAmSBpbnN0ZWFkIG9mDQoNCuKA
mW9wZW5pZC1jb25maWd1cmF0aW9u4oCZIGFzIHByb3Bvc2VkIGJ5IEp1c3Rpbi4NCg0KDQoNCjE4
IGZlYiAyMDE2IGtsLiAxNDo0MCBza3JldiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hv
ZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCg0KOg0KDQoN
Cg0KSGkgYWxsLA0KDQoNCg0KVGhpcyBpcyBhIExhc3QgQ2FsbCBmb3IgY29tbWVudHMgb24gdGhl
ICBPQXV0aCAyLjAgRGlzY292ZXJ5DQoNCnNwZWNpZmljYXRpb246DQoNCmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wMTxodHRwczovL25hMDEu
c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xz
LmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxJmRhdGE9MDEl
N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQz
NDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dzMl
MmJpaWFXb244MUxKQ1UlMmIybUNQUm1BJTJickVDQkhncXlScjBPZ3FpV1NIVSUzZD4NCg0KDQoN
ClNpbmNlIHRoaXMgZG9jdW1lbnQgd2FzIG9ubHkgYWRvcHRlZCByZWNlbnRseSB3ZSBhcmUgcnVu
bmluZyB0aGlzIGxhc3QNCg0KY2FsbCBmb3IgKiozIHdlZWtzKiouDQoNCg0KDQpQbGVhc2UgaGF2
ZSB5b3VyIGNvbW1lbnRzIGluIG5vIGxhdGVyIHRoYW4gTWFyY2ggMTB0aC4NCg0KDQoNCkNpYW8N
Cg0KSGFubmVzICYgRGVyZWsNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t
Lz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZv
YXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFi
MjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl
N2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVX
Z0EyayUzZD4NCg0K4oCUIFJvbGFuZA0KDQoNCg0K4oCdRXZlcnlib2R5IHNob3VsZCBiZSBxdWll
dCBuZWFyIGEgbGl0dGxlIHN0cmVhbSBhbmQgbGlzdGVuLiINCg0KPkZyb20g4oCZT3BlbiBIb3Vz
ZSBmb3IgQnV0dGVyZmxpZXPigJkgYnkgUnV0aCBLcmF1c3MNCg0KDQoNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxp
c3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3
UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QN
Cg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFp
bG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29m
dC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQx
YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIw
TEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn
PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t
Lz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZv
YXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFi
MjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl
N2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVX
Z0EyayUzZD4NCg0KDQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklE
IEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmbmF0LnNha2ltdXJh
Lm9yZyUyZiZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZi
ZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi
NDclN2MxJnNkYXRhPTZGVm1kTjdhZDBZem9ZS1NORiUyZkRPJTJmZkcyRUYxaGFqNWFPSGlNaWQ2
VU1JJTNkPg0KQF9uYXRfZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl
M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAx
JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhk
MzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWJL
c0VWQlVYYzUyOHlhQU1MbXljWGNMMzMlMmJGSkNRcm5xOWFzeFJvNUhlOCUzZD4NCg0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls
aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj
cm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4
NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWJLc0VWQlVYYzUyOHlhQU1MbXljWGNM
MzMlMmJGSkNRcm5xOWFzeFJvNUhlOCUzZD4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlIGFncmVl
ZCB1cG9uIGEgZGlzY292ZXJ5IHNwZWNpZmljYXRpb24gdGhhdCB0aGUgV0cgd291bGQgd29yayBv
biwgd2UgZGlkIG5vdCBhZ3JlZSB1cG9uIHdoYXQgdGhpcyBoYXMgdHVybmVkIG91dCB0byBhY3R1
YWxseSBiZSwgc28gYXQgdGhlIG1pbmltdW0gdGhlIGNoYWlycyBzaG91bGQgY2FsbA0KIGZvciBh
ZG9wdGlvbiBvZiBhIEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIHNwZWNpZmljYXRpb24g
YW5kIHdlIGNhbiBjb250aW51ZSB0byB3b3JrIG9uIGEgRGlzY292ZXJ5IHNwZWNpZmljYXRpb248
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp
bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h
PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PiBNaWtlIEpvbmVzDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2
IDg6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbiAmbHQ7dG9ueW5hZEBtaWNy
b3NvZnQuY29tJmd0OzsgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHku
Y29tJmd0OzsgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs8YnI+DQo8Yj5D
Yzo8L2I+IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UkU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2Nv
dmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgZHJhZnQgZW5hYmxlcyBlYXN5IGNvbmZpZ3Vy
YXRpb24gb2YgT0F1dGggY2xpZW50cyB3aXRoIGFuIEFTLiZuYnNwOyBGb3IgaW5zdGFuY2UsIHRo
ZSBNaWNyb3NvZnQg4oCcQURBTOKAnSBPQXV0aCBjbGllbnQgc29mdHdhcmUgdXNlcyBBUyBtZXRh
ZGF0YSBpbiB0aGlzIGZvcm1hdCBhcw0KIGFuIGlucHV0IGF0IGNsaWVudCBjb25maWd1cmF0aW9u
IHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BcyBhIHNp
ZGUgYmVuZWZpdCwgaGF2aW5nIHRoaXMgc3RhbmRhcmQgQVMgbWV0YWRhdGEgZm9ybWF0IGFuZCBy
ZXR1cm5pbmcgdGhlIGlzc3VlciBVUkwgcGVyIHRoZSBNaXgtVXAgTWl0aWdhdGlvbiBkcmFmdCB3
aWxsIGFsc28gZW5hYmxlIGNsaWVudHMgdG8gdmFsaWRhdGUgdGhhdA0KIHRoZXkgYXJlIHVzaW5n
IGEgY29uc2lzdGVudCBzZXQgb2YgQVMgZW5kcG9pbnRzIGFuZCBpbmZvcm1hdGlvbi4mbmJzcDsg
QnV0IGV2ZW4gd2l0aG91dCB0aGUgbWl0aWdhdGlvbiBiZW5lZml0cywgdGhlIGNsaWVudCBjb25m
aWd1cmF0aW9uIGJlbmVmaXQgaXMgdGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGUgc3BlY2lmaWNh
dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEgaHJl
Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGll
dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW50aG9ueSBOYWRhbGluPGJyPg0KPGI+
U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMTEsIDIwMTYgMzoyNSBQTTxicj4NCjxiPlRvOjwvYj4g
QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5
LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OzsgSm9obiBCcmFkbGV5ICZs
dDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9h
PiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0
Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP
QVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+RGlzYWdyZWUsIHdoYXQgcHVycG9zZSBpcyB0aGlzIGFjdGl2aXR5IHNvbHZpbmcgdGhl
biwgaXQgd2FzIGJlaW5nIHB1c2hlZCBhcyB3aGF0IHdhcyBuZWVkIHRvIHNvbHZlIHRoZSBNaXgt
dXAsIGJ1dCB0aGF0IGlzIG5vdCB0cnVlLiBTbyBub3cgeW91IGFyZSBzdWdnZXN0aW5nIGEgY2hh
bmdlIGluDQogc2NvcGUgYW5kIG5vdCBkZWFsaW5nIHdpdGggZGlzY292ZXJ5LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggWzxhIGhyZWY9
Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2Vu
dDo8L2I+IEZyaWRheSwgTWFyY2ggMTEsIDIwMTYgMzoxMSBQTTxicj4NCjxiPlRvOjwvYj4gSm9o
biBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2
ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWls
dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4w
IERpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+SSB0ZW5kIHRvIGFncmVlIHdpdGggSm9obiB0aGF0IGFkZHJl
c3NpbmcgdGhlIGNvbmNlcm5zIFBoaWwgcmFpc2VzIHNob3VsZCBiZSBwYXJ0IG9mIChleHRlbnNp
b24gdG8pIHRoZSBjb3JlIHByb3RvY29sLiZuYnNwOyBBbmQgdGhhdCB0aG9zZSBraW5kcyBvZiBj
b25jZXJucyBkb24ndCBtYW5pZmVzdCBpbiB0aGUgd2F5IE9BdXRoIGlzIHR5cGljYWxseSBkZXBs
b3llZA0KIG5vdy4gPGJyPg0KPGJyPg0KVGhlIGhvcGVmdWxseSBzb29uIHRvIGJlIG5hbWVkICZx
dW90O09BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSZxdW90OyBzaG91bGQg
a2VlcCBpdCdzIHNjb3BlIHRvIHRoZSBwdWJsaXNoaW5nIG9mIGF1dGhvcml6YXRpb24gc2VydmVy
IG1ldGFkYXRhLiBUaGUgYWN0IG9mIGRvaW5nIGRpc2NvdmVyeSBpcyBiZXlvbmQgaXRzIHNjb3Bl
IGFuZCBzbyBpcyB0cnlpbmcgdG8gcHJldmVudCBhIGNsaWVudCBmcm9tIHByZXNlbnRpbmcgYSB0
b2tlbiB0bw0KIHNvbWVwbGFjZSBpdCBzaG91bGRuJ3QuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXIgMTEsIDIwMTYgYXQgOTowOCBBTSwg
Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdl
dD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5saW5lPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWFyIDExLCAyMDE2LCBhdCAxMjoxMyBQTSwg
UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i
IHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gbWFu
eSBjYXNlIGFsbCB0aGUgQVMgaGFzIHRvIGNoZWNrIGlzIHRoZSBkb21haW4gbmFtZSBjb21wb25l
bnQgdG8gY2hlY2sgZm9yIG1pdG0uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBPUCBhbmQgdGhlIG90aGVyIHNvbG5zIGFyZSBkcmFt
YXRpY2FsbHkgbW9yZSBjb21wbGV4IHRoYW4gYSBzaW1wbGUgY2hlY2suJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkkgd2FzIHByb3Bvc2luZyBkaW5nIHRoYXQgY2hlY2sgYXQgdGhlIGF1dGhv
cml6YXRpb24gZW5kcG9pbnQgb3IgdG9rZW4gZW5kcG9pbnQgYXMgcGFydCBvZiBBVCBpc3N1YW5j
ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SXQgaXMgdXAgdG8gdGhlIEFTIGhvdyBtdWNoIG9mIHRoZSBwYXRoIHRvIHZhbGlkYXRl
IGFuZCBvciBwdXQgaW4gdGhlIGF1ZCBvciBkc3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgc2VlIGl0IGFzIHBhcnQgb2YgdGhlIGRpc2NvdmVyeShiYWQgbmFtZSBhc2lkZSkgcHJv
YmxlbSBiZWNhdXNlIHdlIGRpc2N1c3NlZCB0aGF0IGlmIGEgY2xpZW50IGZpbmRzDQo8YSBocmVm
PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw
JTNhJTJmJTJmYXBwLmV4YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1maVM4ZjYweXBpWGh5TTBx
VlRlcWwlMmIlMmJPekgyd2JtRUNRRTdKNVR0R1BRTSUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KYXBw
LmV4YW1wbGUuY29tPC9hPiBob3cgZG8gd2UgZW5zdXJlIGl0IGdldHMgYSBjb21wbGV0ZSBzZXQg
b2Ygb2F1dGggZW5kcG9pbnRzIGFzIGEgdmFsaWQgc2V0IG9mIGVuZHBvaW50cy0tdGhhdCBhIGhh
Y2tlciBoYXMgbm90IGluc2VydGVkIG9uZSBvZiB0aGVpciBvd24gZW5kcG9pbnRzLiBUaGUgbW9z
dCBpbXBvcnRhbnQgZW5kcG9pbnQgdG8gZ2V0IHJpZ2h0IGlzIGVuc3VyaW5nIHRoZSByZXNvdXJj
ZSBzZXJ2ZXIgKGFuZCBvcHRpb25hbGx5IHRoZQ0KIHBhdGgpIGlzIHRoZSBjb3JyZWN0IG9uZS4g
V2UgY2FuJ3QgcmVhbGx5IGRlZmluZSByZXNvdXJjZSBkaXNjb3ZlcnkgYnV0IHdlIGNhbiB2YWxp
ZGF0ZSBpdCB0byBzb21lIGRlZ3JlZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkkgdGhpbmsgaXQgaXMgcGFydCBvZiBjb3JlIHByb3RvY29sIHNlY3VyaXR5IGFuZCBzaG91bGQv
bXVzdCBub3QgcmVxdWlyZSBkaXNjb3ZlcnkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaXMgPGEgaHJlZj0iaHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFw
cC5leGFtcGxlLmNvbSZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20l
N2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFi
MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9akFzWlFlQ2hKJTJiUjFsYnlCb1ZLd2hlSVlpM1Bp
V0xycSUyYnhETGJxVTZyeGslM2QiIHRhcmdldD0iX2JsYW5rIj4NCmFwcC5leGFtcGxlLmNvbTwv
YT4gPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JZiBpdCBpcyB0aGUgcmVzb3VyY2UgdGhlbiB0aGUgY2xpZW50IHdvdWxkIGJlIHBy
ZWNvbmZpZ3VyZWQgZm9yIGl04oCZcyBBUyBvdXQgb2YgYmFuZCBvciBvcHRpb25hbGx5IHdvdWxk
IGRvIGRpc2NvdmVyeSBvbiB0aGUgaXNzdWVyIHVyaSB0aGF0IHlvdSBhZG1pdCBuZWVkcyB0byBi
ZSBjb25maWd1cmVkIG91dCBvZiBiYW5kIHNvbWUgd2F5IChub3RlIGRpc2NvdmVyeSBpcyBvcHRp
b25hbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SW4gdGhlIEFTIG1ldGEtZGF0YSBkcmFmdCBpdCB3b3VsZCBkbyBhIGdldCBvbiBhIHdlbGwg
a25vd24gZmlsZSB0aGF0IHdvdWxkIGhhdmUgY29uZmlndXJhdGlvbiBmb3IgdGhlIEFTLCBidXQg
bm90IHRoZSBSUywgdGhvdWdoIHNvbWUgQVBJIG1heSBvcHRpb25hbGx5IGxpc3QgYSBBUEkgZW5k
cG9pbnQgbGlrZSBjb25uZWN0IGhhcy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjbGllbnQgdGhlbiBtYWtlcyBhIGF1dGhv
cml6YXRpb24gcmVxdWVzdCAoYWZ0ZXIgcmVnaXN0ZXJpbmcgb3V0IG9mIGJhbmQgb3IgZHluYW1p
Y2FsbHkpLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFzIHBhcnQgb2YgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBmb3IgaW1wbGlj
aXQgaXQgY291bGQgcHJvdmlkZSB0aGUgYXVkL2RzdCB0aGF0IGl0IHdhbnRzIHRoZSB0b2tlbiBm
b3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
ZiB0aGF0IGlzIG5vdCBzZW50IHRoZW4gdGhlIGF1ZC9kc3QgYXJlIGltcGxpY2l0IGluIHRoZSBz
Y29wZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRoZSBjbGllbnQgZ2V0cyBiYWNrIGEgQVQgd2l0aCBhIGxpc3Qgb2Ygc2NvcGVzIGdyYW50
ZWQsIGF1ZC9kc3QgYWxsb3dlZCBhbmQgdGltZSB0byBsaXZlIGZvciB0aGUgdG9rZW4gKG9uZSBl
eHRyYSB0aGluZyByZXR1cm5lZCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2VzbuKAmXQgcmVxdWlyZSBhbnkgZGlzY292ZXJ5ICh5
ZXMgdGhlcmUgaXMgYSBvcHRpb25hbCBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5IGJ1dCBub3QgcmVx
dWlyZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgcHJlZmVyIHRvIGZpeCB0aGUgUlMgbWFuIGluIHRoZSBtaWRkbGUgaXNzdWUgYXMgcGFy
dCBvZiB0aGUgcHJvdG9jb2wgYW5kIG5vdCBwYXJ0IG9mIGRpc2NvdmVyeSB0aGF0IHNob3VsZCBy
ZW1haW4gb3B0aW9uYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkkgaG9uZXN0bHkgZG9u4oCZdCBxdWl0ZSBrbm93IGhvdyB0aGUgY2xpZW50
IGxlYXJucyBhYm91dCB0aGlzIGJhZCBSUyBhbmQgc3RhcnRzIHRhbGtpbmcgdG8gaXQsIHNvIHRo
aXMgbWF5IGJlIGEgc29sdXRpb24gdG8gYSBwcm9ibGVtIHRoYXQgZG9lc27igJl0IHlldCBleGlz
dC4gJm5ic3A7IFRoZSBvbmUgcGxhY2UgdGhpcyBpcyBwb3NhYmxlIGlzIGlmIHRoZSByZWdpc3Ry
YXRpb24gZm9yIHRoZSBjbGllbnQgaXMgY29tcHJvbWlzZWQuJm5ic3A7DQogSG93ZXZlciB3ZSBh
cmUgZGlzY3Vzc2luZyBvdGhlciBtaXRpZ2F0aW9ucyBmb3IgdGhhdCB0aGF0IGFsc28gZXhwbGlj
aXRseSBkbyBub3QgcmVxdWlyZSBkaXNjb3ZlcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHN0dWNrIG9uIHdlYmZpbmdlciBvciB3ZWxs
LWtub3duLiBCZWNhdXNlIHRoaXMgaXMgY29uZmlnIG1heWJlIGl0IHNob3VsZCBiZSBhbiBvYXV0
aCBlbmRwb2ludC4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
Pjxicj4NCk9uIE1hciAxMSwgMjAxNiwgYXQgMDY6NTEsIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0
Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBQaGlsIGlzIHByb3Bvc2luZyBzb21ldGhpbmcgZGlm
ZmVyZW50LiAmbmJzcDsgU2hvdWxkIHRoZSBjbGllbnQgc2VuZCBhIHRva2VuIGZyb20gdGhpcyBB
UyB0byB0aGF0IFJTLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkhpcyBnb2FsIGlzIHRvIHByZXZlbnQgbWFuIGluIHRoZSBtaWRkbGUgYXR0YWNr
cyB3aGVyZSBhIGJhZCBSUyBnZXRzIGEgQVQgdGhhdCBpcyBhdWRpYW5jZWQgdG8vYWNjZXB0ZWQg
YnkgYW5vdGhlciBSUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhhdCBpcyBzZXBhcmF0ZSBmcm9tIHRoZSBxdWVzdGlvbiBvZiBpZiBhIFJT
IGFjY2VwdHMgdG9rZW5zIGZyb20gYSBnb29kIEFTLiAmbmJzcDsgQSBiYWQgQVMgd291bGQgYWx3
YXlzIHNheSB5ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPldlIG5lZWQgdG8gYmUgY2FyZWZ1bCBvZiB3aGF0IGlmIGFueXRoaW5nIHRoZSBS
UyBwcm92aWRlcyB0byB0aGUgY2xpZW50IGFzIG1ldGEtZGF0YSB3aXRob3V0IHZhbGlkYXRpb24u
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN1
cnJlbnRseSB0aGUgY2xpZW50IGNhbiBwcm92aWRlIGEgbGlzdCBvZiBzY29wZXMgcmVxdWlyZWQg
dG8gZ2V0IGFjY2Vzcy4gJm5ic3A7IEkgcGVyc29uYWxseSBmZWVsIGl0IHdvdWxkIGJlIHVzZWZ1
bCB0byBhbHNvIGluY2x1ZGUgaW4gdGhlIHVuYXV0aGVudGljYXRlZCBlcnJvciByZXNwb25zZSBh
biBpbmRpY2F0aW9uIG9mIHdoYXQgQVBJIHRoZSByZXNvdXJjZSBzdXBwb3J0cy4mbmJzcDsgU2F5
IOKAnHNjaW0y4oCdIGFzIGFuIGV4YW1wbGUuDQogJm5ic3A7IEkgZG9u4oCZdCB0aGluayBhZGRp
bmcgdGhhdCBpcyBob3dldmVyIGEgaGlnaCBwcmlvcml0eSBhcyBtb3N0IGlmIGFsbCBjbGllbnRz
IGtub3cgd2hhdCBBUEkgdGhleSBleHBlY3QuICZuYnNwOyBJdCBtaWdodCBiZSB1c2VmdWwgaWYg
YXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlIGlmIGEgY2xpZW50IHdlcmUgdG8gYmUgZ2l2ZW4g
YSBSUyBVUkkgaXQgY291bGQgY2hlY2sgdG8gc2VlIGlmIGl0IGlzIGEgcHJvdG9jb2wgdGhhdCBp
dCBzdXBwb3J0cyBiZWZvcmUNCiBib3RoZXJpbmcgd2l0aCBPQXV0aC4gJm5ic3A7ICZuYnNwO0kg
ZXhwZWN0IHRoYXQgYSBsb3Qgb2YgcGVvcGxlIHdpbGwgd2FudCB0aGF0IGxlZnQgdG8gdGhlIEFQ
SSBkZWZpbml0aW9uLiAmbmJzcDsgSSB0aGluayB3ZSBjYW4gdGFsayBhYm91dCBpdCBidXQgcmF0
ZSB0aGlzIGxvdyBwcmlvcml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IHRoZSBSUyBnaXZpbmcgb3V0IGEgbGlzdCBv
ZiBBUyB0aGF0IGl0IHRydXN0cyBpcyBhIGdlbmVyYWxseSBiYWQgaWRlYS4mbmJzcDsgSSBob3Bl
IHRoYXQgaXMgbm90IG9uIHRoZSB0YWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IHRoaW5rIHRoYXQgcHJldmVudGluZyBh
IGNsaWVudCBmcm9tIHNlbmRpbmcgYSB0b2tlbiB0byB0aGUgd3JvbmcgUlMgaXMgcGFydCBvZiBh
IEFTIG1ldGEtZGF0YSBkaXNjb3ZlcnkgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBob3dldmVyIHRoaW5rIHRoYXQgaXQg
aXMgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5XZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlzIGFzIGEgc2VwYXJhdGUgcHJv
YmxlbSB0byBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5IHdoZXJlIHRoZSBlbmRwb2ludHMgb2YgdGhl
IEFTIGFuZCBpdOKAmXMgY29uZmlndXJhdGlvbiBhcmUgZGlzY292ZXJ5LiAmbmJzcDsgU29ycnkg
Zm9yIHBlcmhhcHMgc3RhdGluZyB0aGUgb2J2aW91cywgYnV0IHRoZSBSUyBpcyBleHBsaWNpdGx5
IG5vdCBwYXJ0IG9mIHRoZSBBUyBpbiBPQXV0aA0KIDIuICZuYnNwOyBTdGFydGluZyBpbiBXQVAg
dGhhdCB3YXMgYSBjb3JlIHByaW5jaXBhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gd2UgaGF2ZSBhIG51bWJlciBvZiBvcHRpb25zIHRv
IGFkZHJlc3MgdGhlIFJTIHRva2VuIGxlYWthZ2UgdmlhIE1pVE0gYXR0YWNrcy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgUG9QIGJvdW5k
IHRva2Vucy4mbmJzcDsgSWYgdGhleSBhcmUgYm91bmQgdG8gdGhlIFRMUyBjaGFubmVsIGJ5IG11
dHVhbCBUTFMgb3IgVG9rZW4gYmluZGluZyB0aGV5IGNhbm5vdCBiZSByZXBsYXllZC4mbmJzcDsg
U2lnbmVkIG1lc3NhZ2VzIHdoZXJlIHRoZSBzaWduaW5nIGNvdmVycyB0aGUgUlMgSG9zdCBhbmQg
cGF0aCBjb21wb25lbnRzLCAmbmJzcDthbHNvIHdvdWxkIHdvcmsuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIEhhdmUgdGhlIEFTIGF1ZGll
bmNlIHJlc3RyaWN0IHRoZSByZXNvdXJjZXMgdGhlIEFUIGlzIGdvb2QgYXQuIChBVCBzaG91bGQg
YmUgZG9pbmcgdGhhdCBub3cpJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgdG9rZW4gcmVzcG9uc2UgaW5jbHVkZSB0aGUgbGlz
dCBvZiBhdWRpZW5jZS9zIHRoZSB0b2tlbiBpcyBwcmVzZW50YWJsZSBhdC4mbmJzcDsgVGhlIGNs
aWVudCB3b3VsZCB0aHJvdyBhbiBlcnJvciBpZiB0aGUgUlMgaXQgaW50ZW5kcyB0byBzZW5kIHRo
ZSB0b2tlbiB0byBpcyBub3Qgb24gdGhlIGxpc3QuICZuYnNwOyBUaGUgUlMgdGhlIHRva2VuIGlz
IGdvb2QgYXQgbWlnaHQgY2hhbmdlIGJhc2VkIG9uIHNjb3BlcywNCiBjbGllbnRfaWQgYW5kIHJl
c291cmNlIG93bmVyLiAmbmJzcDsgVGhpcyBpcyB0aGUgcGxhY2Ugd2hlcmUgYWxsIG9mIHRoYXQg
Y29tZXMgdG9nZXRoZXIuICZuYnNwOyBJbiBzb21lIGNhc2VzIHRoZSBSUyBhbmQgQVMgbWlnaHQg
bm90IGhhdmUgYSBwcmUtZXN0YWJsaXNoZWQgcmVsYXRpb25zaGlwLiAmbmJzcDsgVGhlIGNsaWVu
dCBzaG91bGQgc2VuZCB0aGUgUlMgYmFzZSBVUkkgdG8gdGhlIEFTIGFzIHBhcnQgb2YgdGhlIHJl
cXVlc3QuJm5ic3A7IFRoZSBBUyBjYW4gdXNlIHRoYXQNCiB0byBhdWRpZW5jZSByZXN0cmljdCB0
aGUgQVQgYW5kIGlzc3VlIHRoZSBBVCBvciByZWZ1c2UgdG8gaXNzdWUgdGhlIEFUIGJhc2VkIG9u
IHBvbGljeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkl0IGNhbiBhbHNvIHVzZSB0aGUgYXVkaWVuY2UgaW4gdGhlIHJlcXVlc3QgdG8gZG93biBh
dWRpZW5jZSB0aGUgQVQgaWYgdGhlIGRlZmF1bHQgaXMgdG8gaGF2ZSBtdWx0aXBsZSBhdWRpZW5j
ZXMuICZuYnNwOyAmbmJzcDtXZSBtYXkgd2FudCB0byB1c2UgYSB0ZXJtIG90aGVyIHRoYW4gYXVk
aWVuY2UgZm9yIHRoaXMgbGlrZSByZXNvdXJjZSBvciBkZXN0aW5hdGlvbi4mbmJzcDsgSXQgaXMg
YSBhdWRpZW5jZSBidXQgdGhhdCB0ZXJtIG1pZ2h0DQogY29uZnVzZSBwZW9wbGUgd2l0aCBBVC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ug
ZGlkIHRhbGsgYWJvdXQgYnJlYWtpbmcgYXVkaWVuY2Ugb3V0IG9mIFBPUCBrZXkgZGlzdHJpYnV0
aW9uLCBhbmQgQnJpYW4gQ2FtcGJlbGwgZGlkIGEgZHJhZnQmbmJzcDs8YSBocmVmPSJodHRwczov
L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUy
ZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWNhbXBiZWxsLW9hdXRoLWRzdDRqd3QmYW1w
O2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUw
OTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm
YW1wO3NkYXRhPVNUciUyYjRrcmQxaHk4aDZlSE9DTGgxUHpRYUtNVWhXbEtWMmklMmZDTDBLMVNR
JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNh
bXBiZWxsLW9hdXRoLWRzdDRqd3Q8L2E+Lg0KICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBkbyB0aGlzIHdlIGNvdWxk
IHRha2UgZHN0NGp3dCBhbmQgYWRkIGFub3RoZXIgc3BlYyB0aGF0IGFkZHMgYSBuZXcgZHN0IHBh
cmFtZXRlciB0byB0aGUgdG9rZW4gYW5kIGF1dGhvcml6YXRpb24gZW5kcG9pbnRzIHJlcXVlc3Rz
IFRoYXQgd291bGQgYmUgYSBzcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBkc3QgdmFsdWVzLiAmbmJz
cDthbmQgaW4gdGhlIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdvdWxkDQogYmUg
YSBKU09OIGFycmF5IG9mIGRzdCB2YWx1ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIEhhdmUgdGhlIEFTIGFsd2F5cyByZXR1cm4gYWxs
IHRoZSBsaXN0IG9mIGFsbCBSUyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQgYXQgKGJhc2ljYWxseSBO
YXQncyBsaW5rIHJlbGF0aW9uc2hpcCBwcm9wb3NhbCkuJm5ic3A7IEl0IG5lZWRzIGEgd2F5IHRv
IGhhbmRsZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+ZG93biBkZXN0aW5hdGlvbmluZyBvZiBBVCBhbmQgdG8gYWxsb3cgZm9yIHVuLWNv
bmZpZ3VyZWQgUlMgdGhhdCBpdCBtaWdodCBpc3N1ZSBhIHRva2VuIGZvci4mbmJzcDsgU28gY291
bGQgYmUgY29tYmluZWQgd2l0aCBkc3QgZnJvbSAyLiZuYnNwOyBCYXNpY2FsbHkgcmV0dXJuaW5n
IHRoZSBhY2NlcHRhYmxlIGRlc3RpbmF0aW9ucyBhcyBsaW5rIGhlYWRlcnMgdnMgSlMgaW4gdGhl
IHJlc3BvbnNlIGlzIG1vc3RseSBhIHN0eWxlDQogaXNzdWUgdGhhdCBvdGhlciBwZW9wbGUgY2Fu
IGJpa2Ugc2hlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj40KSBUcnlpbmcgdG8gYWRkIGFsbCB0aGUgUlMgdG8gdGhlIEFTIGRpc2NvdmVy
eSBkb2N1bWVudC4mbmJzcDsgVGhpcyBzZWVtcyBpbXByYWN0aWNhbCBhcyB0aGVyZSB3b3VsZCBi
ZSBtdWx0aXBsZSBwcm90b2NvbHMgYW5kIGRvZXNu4oCZdCBhZGRyZXNzIHVuLWNvbmZpZ3VyZWQg
UlMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjUpIFNvbWUgbmV3IEFTIGVuZHBvaW50IHRoYXQgdGhlIGNsaWVudCBjb3VsZCBpbnRyb3NwZWN0
IHRoZSBSUyBVUkkgYW5kIGdldCBiYWNrIG1ldGFkYXRhIGFib3V0IGlmIHRoZSBjbGllbnQgc2hv
dWxkIHNlbmQgdG9rZW5zIHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBBIGNvdXBsZSBvZiBwcm9ibGVtcyB3aXRo
IHRoaXMuJm5ic3A7IFRoZSBmaXJzdCBpcyB0aGF0IGl0IHdvdWxkIG5vdCBzdXBwb3J0IHVuLWNv
bmZpZ3VyZWQgUlMgdW5sZXNzIHlvdSBhZGQgZHN0IHRvIHRoZSB0b2tlbiBhbmQgYXV0aG9yaXph
dGlvbiBlbmRwb2ludHMuICZuYnNwOyBUaGUgb3RoZXIgaXMgdGhhdCB0aGUgaW50cm9zcGVjdGlv
biBlbmRwb2ludCBkb2VzbuKAmXQgaGF2ZSB0aGUgY29udGV4dCBvZiB0aGUgUk8NCiBhbmQgY2xp
ZW50X2lkIHVubGVzcyB5b3UgYWxzbyBwYXNzIHRoZSBjb2RlL1JUIGFuZCBjbGllbnRfaWQsIGFu
ZCBwcm9iYWJseSBjbGllbnQgY3JlZGVudGlhbHMuICZuYnNwOyAmbmJzcDtCYXNpY2FsbHkgdGhp
cyBpcyB0cnlpbmcgdG8gaW50cm9zcGVjdCB0aGUgQVQgdG8gZGV0ZXJtaW5lIHRoZSBhdWRpYW5j
ZS9kc3QuICZuYnNwOyBCeSB0aGUgdGltZSB5b3UgYnVpbGQgYSBuZXcgaW50cm9zcGVjdGlvbiBl
bmRwb2ludCBzZWN1cmVseSBpdCBpcyBnb2luZyB0byBsb29rDQogbGlrZSB0aGUgdG9rZW4gZW5k
cG9pbnQgd2l0aCBhIGJpdCBtb3JlIG1ldGEgZGF0YSBhYm91dCB0aGUgdG9rZW4gYmV5b25kIGV4
cGlyeSBhbmQgc2NvcGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2Ugc2hvdWxkIGdvIGEgaGVhZCB3aXRoIHRoZSByZW5h
bWVkICZxdW90O09BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRh
dGHigJ0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkkgYW0gYWxzbyBmaW5lIHdpdGggbWFraW5nIHRoZSBkZWZhdWx0IGRvY3VtZW50ICdv
cGVuaWQtY29uZmlndXJhdGlvbuKAmSAmbmJzcDthcyBsb25nIGFzIHdlIGFsbG93IGZvciBwcm90
b2NvbCBzcGVjaWZpYyB2YXJpYXRpb24gc28gdGhhdCBTQ0lNMiBjb3VsZCBkZWZpbmUgYSBmaWxl
IG5hbWUuICZuYnNwOyAmbmJzcDtJZiBwZW9wbGUgd2FudCB3ZSBjb3VsZCBkbyBhIEFQSSAmbmJz
cDt0byBmaWxlIG5hbWUgcmVnaXN0cnkgc28gdGhhdCBwcm90b2NvbA0KIHNwZWNpZmljIG9uZXMg
Y2FuIGJlIGRlZmluZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPldlIGFyZSBhbGwtcmVhZHkgd29ya2luZyBvbiBvcHRpb24gMSB0byBzZWN1
cmUgQVQsIHdlIG5lZWQgYSBzcGVjIGxpa2UgSSBwcm9wb3NlIGluIDIgZm9yIGJlYXJlciB0b2tl
bnMuJm5ic3A7IFdlIGNhbiBhZGQgb25lIHJlcXVlc3QgcGFyYW1ldGVyIGFuZCBhIGJpdCBtb3Jl
IHRva2VuIG1ldGEtZGF0YSB0byB0aGUgdG9rZW4gcmVzcG9uc2UgYW5kIHRoYXQgdGFrZXMgY2Fy
ZSBvZiB0aGUgcHJvYmxlbS4gJm5ic3A7IEhvbmVzdGx5DQogd2UgcHJvYmFibHkgc2hvdWxkIGhh
dmUgc2VwYXJhdGVkIHNjb3BlIGFuZCBkZXN0aW5hdGlvbiBpbiB0aGUgZmlyc3QgcGxhY2UgYW5k
IHJldHVybmVkIGJvdGggZHN0IGFuZCBzY29wZSBpbiB0aGUgcmVzcG9uc2UgYWxsIGFsb25nLCBz
byB0aGlzIGlzIHVwZGF0ZSB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZWlzdGluZyBhcmNo
aXRlY3R1cmUgb2YgT0F1dGggMi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+TGV0cyBrZWVwIHRoZSB0d28gaXNzdWVzIHNlcGFyYXRlLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMTEsIDIwMTYsIGF0IDEyOjA3IEFNLCBBbnRob255
IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdl
dD0iX2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPlRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBBUyBhbmQgUlMgbmVlZCB0byBiZSBzY29wZWQg
dG8g4oCcZG9lcyB0aGlzIFJTIGFjY2VwdCB0b2tlbnMgZnJvbSB0aGlzIEFT4oCdIGFzIGEgbGlz
dCBpcyB0b28gbXVjaCBpbmZvcm1hdGlvbiB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gdGhlIHdyb25n
IHdheTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxhIG5hbWU9IjEyNzI4OTY0MjlfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwO09BdXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9h
Pl0mbmJzcDs8Yj5Pbg0KIEJlaGFsZiBPZiZuYnNwOzwvYj5OYXQgU2FraW11cmE8YnI+DQo8Yj5T
ZW50OjwvYj4mbmJzcDtUaHVyc2RheSwgTWFyY2ggMTAsIDIwMTYgNjoyNSBQTTxicj4NCjxiPlRv
OjwvYj4mbmJzcDtQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA
b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8
YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7b2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4mbmJzcDtSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBP
QXV0aCAyLjAgRGlzY292ZXJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlJpZ2h0LiBTbyB3aGF0IG15IGNvbmRpdGlvbmFsIGFwcHJvdmFscyAoMTEgY29uZGl0aW9u
cyBpbiB0b3RhbCkgc2FpZCB3YXMgdG8gZHJvcCB0aGUgd29yZCAmcXVvdDtkaXNjb3ZlcnkmcXVv
dDsgZnJvbSBldmVyeXdoZXJlLiBUaGlzIGlzIG5vdCBhIGRpc2NvdmVyeSBzcGVjLiBUaGlzIGlz
IGEgY29uZmlndXJhdGlvbiBsb29rdXAgc3BlYyBhcyB5b3UgY29ycmVjdGx5IHBvaW50cyBvdXQu
IFNvLCBJIGFtIHdpdGggeW91IGhlcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkFsc28sIG15IDJuZCBjb25kaXRpaW9uIGlzIGVzc2VudGlhbGx5IHNheWluZyB0byBkcm9wIHNl
Y3Rpb24gMy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIHRoaW5nIHRoYXQg
SSBvdmVybG9va2VkIGFuZCBhbSB3aXRoIHlvdSBpcyB0aGF0IHdlIG5lZWQgdG8gYmUgYWJsZSB0
byBleHByZXNzIHRoZSBBUy1SUyByZWxhdGlvbnNoaXBzLiBJIGhhdmUgYmVlbiBwcmVhY2hpbmcg
dGhpcyBpbiB0aGUgb3RoZXIgdGhyZWFkIGZvciBzbyBtYW55IHRpbWVzIGFzIHlvdSBrbm93IHNv
IEkgdGhvdWdodCBJIHBvaW50ZWQgaXQgb3V0LCBidXQgbWlzc2VkIGFwcGFyZW50bHkNCiBpbiBt
eSBwcmV2aW91cyBjb21tZW50LiBTbywgSSB3b3VsZCBhZGQgbXkgMTJ0aCBjb25kaXRpb246Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEyLiBBIHdheSB0byBleHByZXNzIGEgbGlz
dCBvZiB2YWxpZCBSU3MgZm9yIHRoaXMgQVMgbmVlZHMgdG8gYmUgYWRkZWQgdG8gc2VjdGlvbiAy
LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LCZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wMy0x
MSAyOjA5IEdNVCYjNDM7MDk6MDAgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86
cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0cm9uZ2x5
IG9wcG9zZS4gMiBtYWpvciBpc3N1ZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRoaXMgaXMgbm90IHNlcnZpY2UgZGlzY292ZXJ5IHRoaXMgaXMgY29uZmlndXJhdGlvbiBsb29r
dXAuIFRoZSBjbGllbnQgbXVzdCBoYXZlIGFscmVhZHkgZGlzY292ZXJlZCB0aGUgb2F1dGggaXNz
dWVyIHVyaSBhbmQgdGhlIHJlc291cmNlIHVyaS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhlIG9iamVjdGl2ZSB3YXMgdG8gcHJvdmlkZSBhIG1ldGhvZCB0byBlbnN1cmUgdGhl
IGNsaWVudCBoYXMgYSB2YWxpZCBzZXQgb2YgZW5kcG9pbnRzIHRvIHByZXZlbnQgbWl0bSBvZiBl
bmRwb2ludHMgbGlrZSB0aGUgdG9rZW4gZW5kcG9pbnQgdG8gdGhlIHJlc291cmNlIHNlcnZlci4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRyYWZ0IGRvZXMgbm90IGFkZHJl
c3MgdGhlIGlzc3VlIG9mIGEgY2xpZW50IGJlaW5nIGdpdmVuIGEgYmFkIGVuZHBvaW50IGZvciBh
biBycy4gV2hhdCB3ZSBlbmQgdXAgd2l0aCBpcyBhIHByb21pc2N1b3VzIGF1dGh6IHNlcnZpY2Ug
Z2l2aW5nIG91dCB0b2tlbnMgdG8gYW4gdW53aXR0aW5nIGNsaWVudC4mbmJzcDs8c3BhbiBzdHls
ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KUGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE1hciAxMCwgMjAxNiwgYXQg
MDg6MDYsIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNv
bm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
dmxhZGltaXJAY29ubmVjdDJpZC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+JiM0MzsxIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZXNlPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEwLzAzLzE2IDE3
OjM1LCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwcmU+JiM0MzsxPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48
L3ByZT4NCjxwcmU+T24gVGh1LCBNYXIgMTAsIDIwMTYgYXQgNjowNCBBTSwgUm9sYW5kIEhlZGJl
cmcgPGEgaHJlZj0ibWFpbHRvOnJvbGFuZC5oZWRiZXJnQHVtdS5zZSIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZsdDtyb2xhbmQuaGVkYmVyZ0B1bXUuc2UmZ3Q7
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53cm90ZTo8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkkgc3VwcG9ydCB0aGlzIGRv
Y3VtZW50IGJlaW5nIG1vdmVkIGZvcndhcmQgd2l0aCB0aGVzZSB0d28gY2hhbmdlczo8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIGNoYW5nZSBu
YW1lIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRh
dGHigJ0gYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcm9wb3NlZCBieSBCcmlhbiBhbmQ8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4tIHVzZSB0aGUgVVJJIHBhdGggc3VmZml4IOKAmW9hdXRoLWF1
dGhvcml6YXRpb24tc2VydmVy4oCZIGluc3RlYWQgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7i
gJlvcGVuaWQtY29uZmlndXJhdGlvbuKAmSBhcyBwcm9wb3NlZCBieSBKdXN0aW4uPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4xOCBmZWIgMjAx
NiBrbC4gMTQ6NDAgc2tyZXYgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpo
YW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv
bG9yOnB1cnBsZSI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvc3Bhbj48L2E+PG86cD48L286
cD48L3ByZT4NCjxwcmU+OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPkhpIGFsbCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5UaGlzIGlzIGEgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiB0aGUm
bmJzcDsgT0F1dGggMi4wIERpc2NvdmVyeTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPnNwZWNpZmljYXRpb246PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48YSBocmVmPSJo
dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
YSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5
LTAxJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZi
ZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi
NDclN2MxJmFtcDtzZGF0YT13MyUyYmlpYVdvbjgxTEpDVSUyYjJtQ1BSbUElMmJyRUNCSGdxeVJy
ME9ncWlXU0hVJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAx
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5TaW5jZSB0aGlzIGRvY3VtZW50IHdhcyBvbmx5IGFkb3B0ZWQgcmVjZW50bHkgd2Ug
YXJlIHJ1bm5pbmcgdGhpcyBsYXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+Y2FsbCBmb3IgKioz
IHdlZWtzKiouPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N
CjxwcmU+UGxlYXNlIGhhdmUgeW91ciBjb21tZW50cyBpbiBubyBsYXRlciB0aGFuIE1hcmNoIDEw
dGguPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
Q2lhbzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhhbm5lcyAmYW1wOyBEZXJlazxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+
T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy
ZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1w
O2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDky
ZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm
YW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVX
Z0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9v
OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPuKAlCBSb2xhbmQ8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7igJ1FdmVyeWJvZHkgc2hvdWxk
IGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uJnF1b3Q7PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jmd0O0Zyb20g4oCZT3BlbiBIb3VzZSBmb3IgQnV0dGVyZmxpZXPigJkg
YnkgUnV0aCBLcmF1c3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9B
dXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi
Pk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm
PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw
cyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtk
YXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1
NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFt
cDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUyYnFSOW01V2dB
MmslM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+
PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91
cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0
aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQx
YjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3
JTdjMSZhbXA7c2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJx
UjltNVdnQTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86
cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi
Pk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2Fm
ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRm
Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255
bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdj
NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJG
N3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0i
YWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFp
cm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmbmF0LnNha2ltdXJh
Lm9yZyUyZiZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZl
YWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw
MTFkYjQ3JTdjMSZhbXA7c2RhdGE9NkZWbWRON2FkMFl6b1lLU05GJTJmRE8lMmZmRzJFRjFoYWo1
YU9IaU1pZDZVTUklM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L3NwYW4+PC9hPjxicj4NCkBfbmF0X2VuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo
cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y
ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0
aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3
YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy
ZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1iS3NFVkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJiRkpD
UXJucTlhc3hSbzVIZTglM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo
cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1w
O2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUw
OTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm
YW1wO3NkYXRhPWJLc0VWQlVYYzUyOHlhQU1MbXljWGNMMzMlMmJGSkNRcm5xOWFzeFJvNUhlOCUz
ZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_BN3PR0301MB1234C67C9D564A763AD63B98A6B60BN3PR0301MB1234_--


From nobody Sat Mar 12 08:29:18 2016
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 99BB912D5DC for ; Sat, 12 Mar 2016 08:29:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.11
X-Spam-Level: *
X-Spam-Status: No, score=1.11 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 d0yluKgNV4CF for ; Sat, 12 Mar 2016 08:29:11 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BAD12D5E0 for ; Sat, 12 Mar 2016 08:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gdm64KQS9dGzVRwPRSJRjZY3r2eYv8sYVVLEpftpYOE=; b=YCNZEDujLNZPvPZcvcE6cfivZiv4om8DLLUNB0nbMz0+OGnFDgWFTGBwF/ajFgx6bEcb0JDF85qbl+2m2KTYsykSsy4oI9u3ts4OPOG28ALfqb7BUx9JaDqW8jYyMqWAtaG1xBP80WbqB9GjYrUh11L3oZFgCUgHnLkPAY94N+g=
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by BY1PR0301MB1239.namprd03.prod.outlook.com (10.161.203.23) with Microsoft SMTP Server (TLS) id 15.1.434.16; Sat, 12 Mar 2016 16:28:49 +0000
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0427.020; Sat, 12 Mar 2016 16:28:49 +0000
From: Mike Jones 
To: Anthony Nadalin , Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH0aW6XIA1+zU6W/8nt5o9Vup9Sxh0AgAAqNQCAAAiJgIAAEaoAgACbQYCAAAvegIAAxNAAgAAF5wCAAA9jAIAAdkGAgAADv4CAAQpLsIAAEUSAgAABimA=
Date: Sat, 12 Mar 2016 16:28:48 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.73.146.217]
x-ms-office365-filtering-correlation-id: 8fa83118-a973-4e25-d642-08d34a93642b
x-microsoft-exchange-diagnostics: 1; BY1PR0301MB1239; 5:vK+G4/+rry+A4NRzcflsh9kZdefSAc4eRbIGemy4h5FIB0rigVJKx76MF282zjMo1QmwSS1srGGqzocCm5viXebHEY/Zc42s8nBOqnDvktuUR0DWJKi/LQZZCFQ7DmOuNpf3yhTLlUXliXpqblN6KQ==; 24:7WxsLPCHbs/qWqw4k7PhjwrUwg7dqjKPm0RVoq5EbTmAcTPgVZc2dGVRsvqovznJ/LEZ0XRquAiM6YscIeEd3LWaxc6TKNTD4+glJQHkxV4=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1239;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY1PR0301MB1239; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1239; 
x-forefront-prvs: 0879599414
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(53754006)(377424004)(479174004)(377454003)(74316001)(1511001)(19300405004)(54356999)(50986999)(77096005)(5002640100001)(1220700001)(93886004)(15975445007)(102836003)(76176999)(10290500002)(99286002)(33656002)(10400500002)(122556002)(4326007)(1096002)(3660700001)(3280700002)(5003600100002)(87936001)(3900700001)(66066001)(2906002)(11100500001)(92566002)(5008740100001)(19617315012)(10090500001)(5005710100001)(561944003)(8990500004)(2950100001)(2561002)(2900100001)(2421001)(76576001)(16236675004)(5001770100001)(189998001)(86362001)(19580405001)(790700001)(106116001)(19609705001)(19625215002)(81166005)(6116002)(5004730100002)(586003)(19580395003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1239; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645953392F57012B1826237F5B60SN1PR0301MB1645_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2016 16:28:48.7801 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB1239
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 16:29:17 -0000

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

VGhlIEFTIG1ldGFkYXRhIGZvcm1hdCBpcyBhIG5lY2Vzc2FyeSBwYXJ0IG9mIGRpc2NvdmVyeS4g
IE5vLCBpdCBkb2VzbuKAmXQgYWNjb21wbGlzaCBldmVyeSBwb3NzaWJsZSBhc3BlY3Qgb2YgZGlz
Y292ZXJ5IOKAkyBub3Igd2FzIGl0IGV2ZXIgaW50ZW5kZWQgdG8uICBJ4oCZdmUgY29uc2lzdGVu
dGx5IGVuY291cmFnZWQgUGhpbCBhbmQgb3RoZXJzIHRvIHdyaXRlIGRvd24gYWRkaXRpb25hbCBh
c3BlY3RzIG9mIGRpc2NvdmVyeSBpbiBzcGVjaWZpY2F0aW9ucyB0aGF0IGJ1aWxkIHVwb24gdGhp
cyBvbmUgc28gdGhhdCB0aGUgd29ya2luZyBncm91cCBhbmQgaW1wbGVtZW50ZXJzIGNhbiBldmFs
dWF0ZSB0aGVtLg0KDQpTaW5jZSB3ZeKAmXJlIGNoYXJ0ZXJlZCB0byBkbyBkaXNjb3ZlcnkgYW5k
IHRoaXMgaXMgcGFydCBvZiBkaXNjb3ZlcnksIG5vIHJlY2hhcnRlcmluZyBpcyBuZWVkZWQgZWl0
aGVyIGZvciB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIG9yIGZvciBuZXcgc3BlY2lmaWNhdGlv
bnMgcGVyZm9ybWluZyBhZGRpdGlvbmFsIGRpc2NvdmVyeSB0YXNrcy4NCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K
RnJvbTogQW50aG9ueSBOYWRhbGluDQpTZW50OiBTYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgODoy
MCBBTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IEJyaWFu
IENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IEpvaG4gQnJhZGxleSA8dmU3
anRiQHZlN2p0Yi5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUkU6
IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVy
eQ0KDQpXZSBhZ3JlZWQgdXBvbiBhIGRpc2NvdmVyeSBzcGVjaWZpY2F0aW9uIHRoYXQgdGhlIFdH
IHdvdWxkIHdvcmsgb24sIHdlIGRpZCBub3QgYWdyZWUgdXBvbiB3aGF0IHRoaXMgaGFzIHR1cm5l
ZCBvdXQgdG8gYWN0dWFsbHkgYmUsIHNvIGF0IHRoZSBtaW5pbXVtIHRoZSBjaGFpcnMgc2hvdWxk
IGNhbGwgZm9yIGFkb3B0aW9uIG9mIGEgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGEgc3Bl
Y2lmaWNhdGlvbiBhbmQgd2UgY2FuIGNvbnRpbnVlIHRvIHdvcmsgb24gYSBEaXNjb3Zlcnkgc3Bl
Y2lmaWNhdGlvbg0KDQpGcm9tOiBNaWtlIEpvbmVzDQpTZW50OiBTYXR1cmRheSwgTWFyY2ggMTIs
IDIwMTYgODowNiBBTQ0KVG86IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29t
PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PjsgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVs
bEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+OyBK
b2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+
DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJq
ZWN0OiBSRTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAg
RGlzY292ZXJ5DQoNClRoZSBkcmFmdCBlbmFibGVzIGVhc3kgY29uZmlndXJhdGlvbiBvZiBPQXV0
aCBjbGllbnRzIHdpdGggYW4gQVMuICBGb3IgaW5zdGFuY2UsIHRoZSBNaWNyb3NvZnQg4oCcQURB
TOKAnSBPQXV0aCBjbGllbnQgc29mdHdhcmUgdXNlcyBBUyBtZXRhZGF0YSBpbiB0aGlzIGZvcm1h
dCBhcyBhbiBpbnB1dCBhdCBjbGllbnQgY29uZmlndXJhdGlvbiB0aW1lLg0KDQpBcyBhIHNpZGUg
YmVuZWZpdCwgaGF2aW5nIHRoaXMgc3RhbmRhcmQgQVMgbWV0YWRhdGEgZm9ybWF0IGFuZCByZXR1
cm5pbmcgdGhlIGlzc3VlciBVUkwgcGVyIHRoZSBNaXgtVXAgTWl0aWdhdGlvbiBkcmFmdCB3aWxs
IGFsc28gZW5hYmxlIGNsaWVudHMgdG8gdmFsaWRhdGUgdGhhdCB0aGV5IGFyZSB1c2luZyBhIGNv
bnNpc3RlbnQgc2V0IG9mIEFTIGVuZHBvaW50cyBhbmQgaW5mb3JtYXRpb24uICBCdXQgZXZlbiB3
aXRob3V0IHRoZSBtaXRpZ2F0aW9uIGJlbmVmaXRzLCB0aGUgY2xpZW50IGNvbmZpZ3VyYXRpb24g
YmVuZWZpdCBpcyB0aGUgcHJpbWFyeSByZWFzb24gZm9yIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
LS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBBbnRob255IE5hZGFsaW4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTEsIDIwMTYg
MzoyNSBQTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxt
YWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PjsgSm9obiBCcmFkbGV5IDx2ZTdqdGJA
dmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g
V29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeQ0KDQpEaXNhZ3Jl
ZSwgd2hhdCBwdXJwb3NlIGlzIHRoaXMgYWN0aXZpdHkgc29sdmluZyB0aGVuLCBpdCB3YXMgYmVp
bmcgcHVzaGVkIGFzIHdoYXQgd2FzIG5lZWQgdG8gc29sdmUgdGhlIE1peC11cCwgYnV0IHRoYXQg
aXMgbm90IHRydWUuIFNvIG5vdyB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBjaGFuZ2UgaW4gc2NvcGUg
YW5kIG5vdCBkZWFsaW5nIHdpdGggZGlzY292ZXJ5Lg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDog
RnJpZGF5LCBNYXJjaCAxMSwgMjAxNiAzOjExIFBNDQpUbzogSm9obiBCcmFkbGV5IDx2ZTdqdGJA
dmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g
V29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeQ0KDQpJIHRlbmQg
dG8gYWdyZWUgd2l0aCBKb2huIHRoYXQgYWRkcmVzc2luZyB0aGUgY29uY2VybnMgUGhpbCByYWlz
ZXMgc2hvdWxkIGJlIHBhcnQgb2YgKGV4dGVuc2lvbiB0bykgdGhlIGNvcmUgcHJvdG9jb2wuICBB
bmQgdGhhdCB0aG9zZSBraW5kcyBvZiBjb25jZXJucyBkb24ndCBtYW5pZmVzdCBpbiB0aGUgd2F5
IE9BdXRoIGlzIHR5cGljYWxseSBkZXBsb3llZCBub3cuDQoNClRoZSBob3BlZnVsbHkgc29vbiB0
byBiZSBuYW1lZCAiT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIE1ldGFkYXRhIiBzaG91
bGQga2VlcCBpdCdzIHNjb3BlIHRvIHRoZSBwdWJsaXNoaW5nIG9mIGF1dGhvcml6YXRpb24gc2Vy
dmVyIG1ldGFkYXRhLiBUaGUgYWN0IG9mIGRvaW5nIGRpc2NvdmVyeSBpcyBiZXlvbmQgaXRzIHNj
b3BlIGFuZCBzbyBpcyB0cnlpbmcgdG8gcHJldmVudCBhIGNsaWVudCBmcm9tIHByZXNlbnRpbmcg
YSB0b2tlbiB0byBzb21lcGxhY2UgaXQgc2hvdWxkbid0Lg0KDQpPbiBGcmksIE1hciAxMSwgMjAx
NiBhdCA5OjA4IEFNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdq
dGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KSW5saW5lDQpPbiBNYXIgMTEsIDIwMTYsIGF0IDEyOjEz
IFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1
bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpKb2huDQoNCkluIG1hbnkgY2FzZSBhbGwgdGhlIEFT
IGhhcyB0byBjaGVjayBpcyB0aGUgZG9tYWluIG5hbWUgY29tcG9uZW50IHRvIGNoZWNrIGZvciBt
aXRtLg0KDQpQT1AgYW5kIHRoZSBvdGhlciBzb2xucyBhcmUgZHJhbWF0aWNhbGx5IG1vcmUgY29t
cGxleCB0aGFuIGEgc2ltcGxlIGNoZWNrLg0KDQpJIHdhcyBwcm9wb3NpbmcgZGluZyB0aGF0IGNo
ZWNrIGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IG9yIHRva2VuIGVuZHBvaW50IGFzIHBh
cnQgb2YgQVQgaXNzdWFuY2UuDQoNCkl0IGlzIHVwIHRvIHRoZSBBUyBob3cgbXVjaCBvZiB0aGUg
cGF0aCB0byB2YWxpZGF0ZSBhbmQgb3IgcHV0IGluIHRoZSBhdWQgb3IgZHN0Lg0KDQoNCg0KSSBz
ZWUgaXQgYXMgcGFydCBvZiB0aGUgZGlzY292ZXJ5KGJhZCBuYW1lIGFzaWRlKSBwcm9ibGVtIGJl
Y2F1c2Ugd2UgZGlzY3Vzc2VkIHRoYXQgaWYgYSBjbGllbnQgZmluZHMgYXBwLmV4YW1wbGUuY29t
PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAl
M2ElMmYlMmZhcHAuZXhhbXBsZS5jb20lMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1maVM4ZjYweXBpWGh5TTBxVlRlcWwlMmIl
MmJPekgyd2JtRUNRRTdKNVR0R1BRTSUzZD4gaG93IGRvIHdlIGVuc3VyZSBpdCBnZXRzIGEgY29t
cGxldGUgc2V0IG9mIG9hdXRoIGVuZHBvaW50cyBhcyBhIHZhbGlkIHNldCBvZiBlbmRwb2ludHMt
LXRoYXQgYSBoYWNrZXIgaGFzIG5vdCBpbnNlcnRlZCBvbmUgb2YgdGhlaXIgb3duIGVuZHBvaW50
cy4gVGhlIG1vc3QgaW1wb3J0YW50IGVuZHBvaW50IHRvIGdldCByaWdodCBpcyBlbnN1cmluZyB0
aGUgcmVzb3VyY2Ugc2VydmVyIChhbmQgb3B0aW9uYWxseSB0aGUgcGF0aCkgaXMgdGhlIGNvcnJl
Y3Qgb25lLiBXZSBjYW4ndCByZWFsbHkgZGVmaW5lIHJlc291cmNlIGRpc2NvdmVyeSBidXQgd2Ug
Y2FuIHZhbGlkYXRlIGl0IHRvIHNvbWUgZGVncmVlLg0KDQpJIHRoaW5rIGl0IGlzIHBhcnQgb2Yg
Y29yZSBwcm90b2NvbCBzZWN1cml0eSBhbmQgc2hvdWxkL211c3Qgbm90IHJlcXVpcmUgZGlzY292
ZXJ5Lg0KDQpXaGF0IGlzIGFwcC5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnBy
b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYXBwLmV4YW1wbGUuY29tJmRh
dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZi
ODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2Rh
dGE9akFzWlFlQ2hKJTJiUjFsYnlCb1ZLd2hlSVlpM1BpV0xycSUyYnhETGJxVTZyeGslM2Q+ID8N
Cg0KSWYgaXQgaXMgdGhlIHJlc291cmNlIHRoZW4gdGhlIGNsaWVudCB3b3VsZCBiZSBwcmVjb25m
aWd1cmVkIGZvciBpdOKAmXMgQVMgb3V0IG9mIGJhbmQgb3Igb3B0aW9uYWxseSB3b3VsZCBkbyBk
aXNjb3Zlcnkgb24gdGhlIGlzc3VlciB1cmkgdGhhdCB5b3UgYWRtaXQgbmVlZHMgdG8gYmUgY29u
ZmlndXJlZCBvdXQgb2YgYmFuZCBzb21lIHdheSAobm90ZSBkaXNjb3ZlcnkgaXMgb3B0aW9uYWwp
DQoNCkluIHRoZSBBUyBtZXRhLWRhdGEgZHJhZnQgaXQgd291bGQgZG8gYSBnZXQgb24gYSB3ZWxs
IGtub3duIGZpbGUgdGhhdCB3b3VsZCBoYXZlIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBBUywgYnV0
IG5vdCB0aGUgUlMsIHRob3VnaCBzb21lIEFQSSBtYXkgb3B0aW9uYWxseSBsaXN0IGEgQVBJIGVu
ZHBvaW50IGxpa2UgY29ubmVjdCBoYXMuDQoNClRoZSBjbGllbnQgdGhlbiBtYWtlcyBhIGF1dGhv
cml6YXRpb24gcmVxdWVzdCAoYWZ0ZXIgcmVnaXN0ZXJpbmcgb3V0IG9mIGJhbmQgb3IgZHluYW1p
Y2FsbHkpLg0KQXMgcGFydCBvZiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZvciBpbXBsaWNp
dCBpdCBjb3VsZCBwcm92aWRlIHRoZSBhdWQvZHN0IHRoYXQgaXQgd2FudHMgdGhlIHRva2VuIGZv
ci4NCklmIHRoYXQgaXMgbm90IHNlbnQgdGhlbiB0aGUgYXVkL2RzdCBhcmUgaW1wbGljaXQgaW4g
dGhlIHNjb3Blcy4NCg0KVGhlIGNsaWVudCBnZXRzIGJhY2sgYSBBVCB3aXRoIGEgbGlzdCBvZiBz
Y29wZXMgZ3JhbnRlZCwgYXVkL2RzdCBhbGxvd2VkIGFuZCB0aW1lIHRvIGxpdmUgZm9yIHRoZSB0
b2tlbiAob25lIGV4dHJhIHRoaW5nIHJldHVybmVkKQ0KDQpUaGlzIGRvZXNu4oCZdCByZXF1aXJl
IGFueSBkaXNjb3ZlcnkgKHllcyB0aGVyZSBpcyBhIG9wdGlvbmFsIEFTIG1ldGEtZGF0YSBkaXNj
b3ZlcnkgYnV0IG5vdCByZXF1aXJlZCkNCg0KSSBwcmVmZXIgdG8gZml4IHRoZSBSUyBtYW4gaW4g
dGhlIG1pZGRsZSBpc3N1ZSBhcyBwYXJ0IG9mIHRoZSBwcm90b2NvbCBhbmQgbm90IHBhcnQgb2Yg
ZGlzY292ZXJ5IHRoYXQgc2hvdWxkIHJlbWFpbiBvcHRpb25hbC4NCg0KSSBob25lc3RseSBkb27i
gJl0IHF1aXRlIGtub3cgaG93IHRoZSBjbGllbnQgbGVhcm5zIGFib3V0IHRoaXMgYmFkIFJTIGFu
ZCBzdGFydHMgdGFsa2luZyB0byBpdCwgc28gdGhpcyBtYXkgYmUgYSBzb2x1dGlvbiB0byBhIHBy
b2JsZW0gdGhhdCBkb2VzbuKAmXQgeWV0IGV4aXN0LiAgIFRoZSBvbmUgcGxhY2UgdGhpcyBpcyBw
b3NhYmxlIGlzIGlmIHRoZSByZWdpc3RyYXRpb24gZm9yIHRoZSBjbGllbnQgaXMgY29tcHJvbWlz
ZWQuICBIb3dldmVyIHdlIGFyZSBkaXNjdXNzaW5nIG90aGVyIG1pdGlnYXRpb25zIGZvciB0aGF0
IHRoYXQgYWxzbyBleHBsaWNpdGx5IGRvIG5vdCByZXF1aXJlIGRpc2NvdmVyeS4NCg0KSm9obiBC
Lg0KDQoNCkkgYW0gbm90IHN0dWNrIG9uIHdlYmZpbmdlciBvciB3ZWxsLWtub3duLiBCZWNhdXNl
IHRoaXMgaXMgY29uZmlnIG1heWJlIGl0IHNob3VsZCBiZSBhbiBvYXV0aCBlbmRwb2ludC4NCg0K
UGhpbA0KDQpPbiBNYXIgMTEsIDIwMTYsIGF0IDA2OjUxLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2
ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KSSB0aGluayBQaGls
IGlzIHByb3Bvc2luZyBzb21ldGhpbmcgZGlmZmVyZW50LiAgIFNob3VsZCB0aGUgY2xpZW50IHNl
bmQgYSB0b2tlbiBmcm9tIHRoaXMgQVMgdG8gdGhhdCBSUy4NCg0KSGlzIGdvYWwgaXMgdG8gcHJl
dmVudCBtYW4gaW4gdGhlIG1pZGRsZSBhdHRhY2tzIHdoZXJlIGEgYmFkIFJTIGdldHMgYSBBVCB0
aGF0IGlzIGF1ZGlhbmNlZCB0by9hY2NlcHRlZCBieSBhbm90aGVyIFJTLg0KDQpUaGF0IGlzIHNl
cGFyYXRlIGZyb20gdGhlIHF1ZXN0aW9uIG9mIGlmIGEgUlMgYWNjZXB0cyB0b2tlbnMgZnJvbSBh
IGdvb2QgQVMuICAgQSBiYWQgQVMgd291bGQgYWx3YXlzIHNheSB5ZXMuDQoNCldlIG5lZWQgdG8g
YmUgY2FyZWZ1bCBvZiB3aGF0IGlmIGFueXRoaW5nIHRoZSBSUyBwcm92aWRlcyB0byB0aGUgY2xp
ZW50IGFzIG1ldGEtZGF0YSB3aXRob3V0IHZhbGlkYXRpb24uDQoNCkN1cnJlbnRseSB0aGUgY2xp
ZW50IGNhbiBwcm92aWRlIGEgbGlzdCBvZiBzY29wZXMgcmVxdWlyZWQgdG8gZ2V0IGFjY2Vzcy4g
ICBJIHBlcnNvbmFsbHkgZmVlbCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gYWxzbyBpbmNsdWRlIGlu
IHRoZSB1bmF1dGhlbnRpY2F0ZWQgZXJyb3IgcmVzcG9uc2UgYW4gaW5kaWNhdGlvbiBvZiB3aGF0
IEFQSSB0aGUgcmVzb3VyY2Ugc3VwcG9ydHMuICBTYXkg4oCcc2NpbTLigJ0gYXMgYW4gZXhhbXBs
ZS4gICBJIGRvbuKAmXQgdGhpbmsgYWRkaW5nIHRoYXQgaXMgaG93ZXZlciBhIGhpZ2ggcHJpb3Jp
dHkgYXMgbW9zdCBpZiBhbGwgY2xpZW50cyBrbm93IHdoYXQgQVBJIHRoZXkgZXhwZWN0LiAgIEl0
IG1pZ2h0IGJlIHVzZWZ1bCBpZiBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUgaWYgYSBjbGll
bnQgd2VyZSB0byBiZSBnaXZlbiBhIFJTIFVSSSBpdCBjb3VsZCBjaGVjayB0byBzZWUgaWYgaXQg
aXMgYSBwcm90b2NvbCB0aGF0IGl0IHN1cHBvcnRzIGJlZm9yZSBib3RoZXJpbmcgd2l0aCBPQXV0
aC4gICAgSSBleHBlY3QgdGhhdCBhIGxvdCBvZiBwZW9wbGUgd2lsbCB3YW50IHRoYXQgbGVmdCB0
byB0aGUgQVBJIGRlZmluaXRpb24uICAgSSB0aGluayB3ZSBjYW4gdGFsayBhYm91dCBpdCBidXQg
cmF0ZSB0aGlzIGxvdyBwcmlvcml0eS4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBSUyBnaXZpbmcgb3V0
IGEgbGlzdCBvZiBBUyB0aGF0IGl0IHRydXN0cyBpcyBhIGdlbmVyYWxseSBiYWQgaWRlYS4gIEkg
aG9wZSB0aGF0IGlzIG5vdCBvbiB0aGUgdGFibGUuDQoNCkkgZG9u4oCZdCB0aGluayB0aGF0IHBy
ZXZlbnRpbmcgYSBjbGllbnQgZnJvbSBzZW5kaW5nIGEgdG9rZW4gdG8gdGhlIHdyb25nIFJTIGlz
IHBhcnQgb2YgYSBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5IHByb2JsZW0uDQoNCkkgZG8gaG93ZXZl
ciB0aGluayB0aGF0IGl0IGlzIGltcG9ydGFudC4NCg0KV2UgaGF2ZSBiZWVuIGRpc2N1c3Npbmcg
dGhpcyBhcyBhIHNlcGFyYXRlIHByb2JsZW0gdG8gQVMgbWV0YS1kYXRhIGRpc2NvdmVyeSB3aGVy
ZSB0aGUgZW5kcG9pbnRzIG9mIHRoZSBBUyBhbmQgaXTigJlzIGNvbmZpZ3VyYXRpb24gYXJlIGRp
c2NvdmVyeS4gICBTb3JyeSBmb3IgcGVyaGFwcyBzdGF0aW5nIHRoZSBvYnZpb3VzLCBidXQgdGhl
IFJTIGlzIGV4cGxpY2l0bHkgbm90IHBhcnQgb2YgdGhlIEFTIGluIE9BdXRoIDIuICAgU3RhcnRp
bmcgaW4gV0FQIHRoYXQgd2FzIGEgY29yZSBwcmluY2lwYWwuDQoNClNvIHdlIGhhdmUgYSBudW1i
ZXIgb2Ygb3B0aW9ucyB0byBhZGRyZXNzIHRoZSBSUyB0b2tlbiBsZWFrYWdlIHZpYSBNaVRNIGF0
dGFja3MuDQoNCjEpIFBvUCBib3VuZCB0b2tlbnMuICBJZiB0aGV5IGFyZSBib3VuZCB0byB0aGUg
VExTIGNoYW5uZWwgYnkgbXV0dWFsIFRMUyBvciBUb2tlbiBiaW5kaW5nIHRoZXkgY2Fubm90IGJl
IHJlcGxheWVkLiAgU2lnbmVkIG1lc3NhZ2VzIHdoZXJlIHRoZSBzaWduaW5nIGNvdmVycyB0aGUg
UlMgSG9zdCBhbmQgcGF0aCBjb21wb25lbnRzLCAgYWxzbyB3b3VsZCB3b3JrLg0KDQoyKSBIYXZl
IHRoZSBBUyBhdWRpZW5jZSByZXN0cmljdCB0aGUgcmVzb3VyY2VzIHRoZSBBVCBpcyBnb29kIGF0
LiAoQVQgc2hvdWxkIGJlIGRvaW5nIHRoYXQgbm93KQ0KSW4gdGhlIHRva2VuIHJlc3BvbnNlIGlu
Y2x1ZGUgdGhlIGxpc3Qgb2YgYXVkaWVuY2UvcyB0aGUgdG9rZW4gaXMgcHJlc2VudGFibGUgYXQu
ICBUaGUgY2xpZW50IHdvdWxkIHRocm93IGFuIGVycm9yIGlmIHRoZSBSUyBpdCBpbnRlbmRzIHRv
IHNlbmQgdGhlIHRva2VuIHRvIGlzIG5vdCBvbiB0aGUgbGlzdC4gICBUaGUgUlMgdGhlIHRva2Vu
IGlzIGdvb2QgYXQgbWlnaHQgY2hhbmdlIGJhc2VkIG9uIHNjb3BlcywgY2xpZW50X2lkIGFuZCBy
ZXNvdXJjZSBvd25lci4gICBUaGlzIGlzIHRoZSBwbGFjZSB3aGVyZSBhbGwgb2YgdGhhdCBjb21l
cyB0b2dldGhlci4gICBJbiBzb21lIGNhc2VzIHRoZSBSUyBhbmQgQVMgbWlnaHQgbm90IGhhdmUg
YSBwcmUtZXN0YWJsaXNoZWQgcmVsYXRpb25zaGlwLiAgIFRoZSBjbGllbnQgc2hvdWxkIHNlbmQg
dGhlIFJTIGJhc2UgVVJJIHRvIHRoZSBBUyBhcyBwYXJ0IG9mIHRoZSByZXF1ZXN0LiAgVGhlIEFT
IGNhbiB1c2UgdGhhdCB0byBhdWRpZW5jZSByZXN0cmljdCB0aGUgQVQgYW5kIGlzc3VlIHRoZSBB
VCBvciByZWZ1c2UgdG8gaXNzdWUgdGhlIEFUIGJhc2VkIG9uIHBvbGljeS4NCkl0IGNhbiBhbHNv
IHVzZSB0aGUgYXVkaWVuY2UgaW4gdGhlIHJlcXVlc3QgdG8gZG93biBhdWRpZW5jZSB0aGUgQVQg
aWYgdGhlIGRlZmF1bHQgaXMgdG8gaGF2ZSBtdWx0aXBsZSBhdWRpZW5jZXMuICAgIFdlIG1heSB3
YW50IHRvIHVzZSBhIHRlcm0gb3RoZXIgdGhhbiBhdWRpZW5jZSBmb3IgdGhpcyBsaWtlIHJlc291
cmNlIG9yIGRlc3RpbmF0aW9uLiAgSXQgaXMgYSBhdWRpZW5jZSBidXQgdGhhdCB0ZXJtIG1pZ2h0
IGNvbmZ1c2UgcGVvcGxlIHdpdGggQVQuDQoNCldlIGRpZCB0YWxrIGFib3V0IGJyZWFraW5nIGF1
ZGllbmNlIG91dCBvZiBQT1Aga2V5IGRpc3RyaWJ1dGlvbiwgYW5kIEJyaWFuIENhbXBiZWxsIGRp
ZCBhIGRyYWZ0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0
aC1kc3Q0and0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/
dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtY2FtcGJlbGwt
b2F1dGgtZHN0NGp3dCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRi
OWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJnNkYXRhPVNUciUyYjRrcmQxaHk4aDZlSE9DTGgxUHpRYUtNVWhXbEtWMmkl
MmZDTDBLMVNRJTNkPi4NCg0KVG8gZG8gdGhpcyB3ZSBjb3VsZCB0YWtlIGRzdDRqd3QgYW5kIGFk
ZCBhbm90aGVyIHNwZWMgdGhhdCBhZGRzIGEgbmV3IGRzdCBwYXJhbWV0ZXIgdG8gdGhlIHRva2Vu
IGFuZCBhdXRob3JpemF0aW9uIGVuZHBvaW50cyByZXF1ZXN0cyBUaGF0IHdvdWxkIGJlIGEgc3Bh
Y2Ugc2VwYXJhdGVkIGxpc3Qgb2YgZHN0IHZhbHVlcy4gIGFuZCBpbiB0aGUgcmVzcG9uc2UgZnJv
bSB0aGUgdG9rZW4gZW5kcG9pbnQgd291bGQgYmUgYSBKU09OIGFycmF5IG9mIGRzdCB2YWx1ZXMu
DQoNCjMpIEhhdmUgdGhlIEFTIGFsd2F5cyByZXR1cm4gYWxsIHRoZSBsaXN0IG9mIGFsbCBSUyB0
aGUgdG9rZW4gY2FuIGJlIHVzZWQgYXQgKGJhc2ljYWxseSBOYXQncyBsaW5rIHJlbGF0aW9uc2hp
cCBwcm9wb3NhbCkuICBJdCBuZWVkcyBhIHdheSB0byBoYW5kbGUNCmRvd24gZGVzdGluYXRpb25p
bmcgb2YgQVQgYW5kIHRvIGFsbG93IGZvciB1bi1jb25maWd1cmVkIFJTIHRoYXQgaXQgbWlnaHQg
aXNzdWUgYSB0b2tlbiBmb3IuICBTbyBjb3VsZCBiZSBjb21iaW5lZCB3aXRoIGRzdCBmcm9tIDIu
ICBCYXNpY2FsbHkgcmV0dXJuaW5nIHRoZSBhY2NlcHRhYmxlIGRlc3RpbmF0aW9ucyBhcyBsaW5r
IGhlYWRlcnMgdnMgSlMgaW4gdGhlIHJlc3BvbnNlIGlzIG1vc3RseSBhIHN0eWxlIGlzc3VlIHRo
YXQgb3RoZXIgcGVvcGxlIGNhbiBiaWtlIHNoZWQuDQoNCg0KNCkgVHJ5aW5nIHRvIGFkZCBhbGwg
dGhlIFJTIHRvIHRoZSBBUyBkaXNjb3ZlcnkgZG9jdW1lbnQuICBUaGlzIHNlZW1zIGltcHJhY3Rp
Y2FsIGFzIHRoZXJlIHdvdWxkIGJlIG11bHRpcGxlIHByb3RvY29scyBhbmQgZG9lc27igJl0IGFk
ZHJlc3MgdW4tY29uZmlndXJlZCBSUy4NCg0KNSkgU29tZSBuZXcgQVMgZW5kcG9pbnQgdGhhdCB0
aGUgY2xpZW50IGNvdWxkIGludHJvc3BlY3QgdGhlIFJTIFVSSSBhbmQgZ2V0IGJhY2sgbWV0YWRh
dGEgYWJvdXQgaWYgdGhlIGNsaWVudCBzaG91bGQgc2VuZCB0b2tlbnMgdGhlcmUuDQogICAgQSBj
b3VwbGUgb2YgcHJvYmxlbXMgd2l0aCB0aGlzLiAgVGhlIGZpcnN0IGlzIHRoYXQgaXQgd291bGQg
bm90IHN1cHBvcnQgdW4tY29uZmlndXJlZCBSUyB1bmxlc3MgeW91IGFkZCBkc3QgdG8gdGhlIHRv
a2VuIGFuZCBhdXRob3JpemF0aW9uIGVuZHBvaW50cy4gICBUaGUgb3RoZXIgaXMgdGhhdCB0aGUg
aW50cm9zcGVjdGlvbiBlbmRwb2ludCBkb2VzbuKAmXQgaGF2ZSB0aGUgY29udGV4dCBvZiB0aGUg
Uk8gYW5kIGNsaWVudF9pZCB1bmxlc3MgeW91IGFsc28gcGFzcyB0aGUgY29kZS9SVCBhbmQgY2xp
ZW50X2lkLCBhbmQgcHJvYmFibHkgY2xpZW50IGNyZWRlbnRpYWxzLiAgICBCYXNpY2FsbHkgdGhp
cyBpcyB0cnlpbmcgdG8gaW50cm9zcGVjdCB0aGUgQVQgdG8gZGV0ZXJtaW5lIHRoZSBhdWRpYW5j
ZS9kc3QuICAgQnkgdGhlIHRpbWUgeW91IGJ1aWxkIGEgbmV3IGludHJvc3BlY3Rpb24gZW5kcG9p
bnQgc2VjdXJlbHkgaXQgaXMgZ29pbmcgdG8gbG9vayBsaWtlIHRoZSB0b2tlbiBlbmRwb2ludCB3
aXRoIGEgYml0IG1vcmUgbWV0YSBkYXRhIGFib3V0IHRoZSB0b2tlbiBiZXlvbmQgZXhwaXJ5IGFu
ZCBzY29wZXMuDQoNCg0KSSB0aGluayB3ZSBzaG91bGQgZ28gYSBoZWFkIHdpdGggdGhlIHJlbmFt
ZWQgIk9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRhdGHigJ0N
CkkgYW0gYWxzbyBmaW5lIHdpdGggbWFraW5nIHRoZSBkZWZhdWx0IGRvY3VtZW50ICdvcGVuaWQt
Y29uZmlndXJhdGlvbuKAmSAgYXMgbG9uZyBhcyB3ZSBhbGxvdyBmb3IgcHJvdG9jb2wgc3BlY2lm
aWMgdmFyaWF0aW9uIHNvIHRoYXQgU0NJTTIgY291bGQgZGVmaW5lIGEgZmlsZSBuYW1lLiAgICBJ
ZiBwZW9wbGUgd2FudCB3ZSBjb3VsZCBkbyBhIEFQSSAgdG8gZmlsZSBuYW1lIHJlZ2lzdHJ5IHNv
IHRoYXQgcHJvdG9jb2wgc3BlY2lmaWMgb25lcyBjYW4gYmUgZGVmaW5lZC4NCg0KV2UgYXJlIGFs
bC1yZWFkeSB3b3JraW5nIG9uIG9wdGlvbiAxIHRvIHNlY3VyZSBBVCwgd2UgbmVlZCBhIHNwZWMg
bGlrZSBJIHByb3Bvc2UgaW4gMiBmb3IgYmVhcmVyIHRva2Vucy4gIFdlIGNhbiBhZGQgb25lIHJl
cXVlc3QgcGFyYW1ldGVyIGFuZCBhIGJpdCBtb3JlIHRva2VuIG1ldGEtZGF0YSB0byB0aGUgdG9r
ZW4gcmVzcG9uc2UgYW5kIHRoYXQgdGFrZXMgY2FyZSBvZiB0aGUgcHJvYmxlbS4gICBIb25lc3Rs
eSB3ZSBwcm9iYWJseSBzaG91bGQgaGF2ZSBzZXBhcmF0ZWQgc2NvcGUgYW5kIGRlc3RpbmF0aW9u
IGluIHRoZSBmaXJzdCBwbGFjZSBhbmQgcmV0dXJuZWQgYm90aCBkc3QgYW5kIHNjb3BlIGluIHRo
ZSByZXNwb25zZSBhbGwgYWxvbmcsIHNvIHRoaXMgaXMgdXBkYXRlIHRoYXQgaXMgY29uc2lzdGVu
dCB3aXRoIHRoZSBlaXN0aW5nIGFyY2hpdGVjdHVyZSBvZiBPQXV0aCAyLg0KDQpMZXRzIGtlZXAg
dGhlIHR3byBpc3N1ZXMgc2VwYXJhdGUuDQoNCkpvaG4gQi4NCg0KDQoNCg0KT24gTWFyIDExLCAy
MDE2LCBhdCAxMjowNyBBTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208
bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGUgcmVsYXRpb25zaGlw
IGJldHdlZW4gQVMgYW5kIFJTIG5lZWQgdG8gYmUgc2NvcGVkIHRvIOKAnGRvZXMgdGhpcyBSUyBh
Y2NlcHQgdG9rZW5zIGZyb20gdGhpcyBBU+KAnSBhcyBhIGxpc3QgaXMgdG9vIG11Y2ggaW5mb3Jt
YXRpb24gdGhhdCBjb3VsZCBiZSB1c2VkIGluIHRoZSB3cm9uZyB3YXkNCg0KRnJvbTogT0F1dGgg
W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmF0IFNha2ltdXJh
DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTAsIDIwMTYgNjoyNSBQTQ0KVG86IFBoaWwgSHVudCAo
SURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4N
CkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1Ympl
Y3Q6IFJlOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIE9BdXRoIDIuMCBE
aXNjb3ZlcnkNCg0KUGhpbCwNCg0KUmlnaHQuIFNvIHdoYXQgbXkgY29uZGl0aW9uYWwgYXBwcm92
YWxzICgxMSBjb25kaXRpb25zIGluIHRvdGFsKSBzYWlkIHdhcyB0byBkcm9wIHRoZSB3b3JkICJk
aXNjb3ZlcnkiIGZyb20gZXZlcnl3aGVyZS4gVGhpcyBpcyBub3QgYSBkaXNjb3Zlcnkgc3BlYy4g
VGhpcyBpcyBhIGNvbmZpZ3VyYXRpb24gbG9va3VwIHNwZWMgYXMgeW91IGNvcnJlY3RseSBwb2lu
dHMgb3V0LiBTbywgSSBhbSB3aXRoIHlvdSBoZXJlLg0KDQpBbHNvLCBteSAybmQgY29uZGl0aWlv
biBpcyBlc3NlbnRpYWxseSBzYXlpbmcgdG8gZHJvcCBzZWN0aW9uIDMuDQoNCk9uZSB0aGluZyB0
aGF0IEkgb3Zlcmxvb2tlZCBhbmQgYW0gd2l0aCB5b3UgaXMgdGhhdCB3ZSBuZWVkIHRvIGJlIGFi
bGUgdG8gZXhwcmVzcyB0aGUgQVMtUlMgcmVsYXRpb25zaGlwcy4gSSBoYXZlIGJlZW4gcHJlYWNo
aW5nIHRoaXMgaW4gdGhlIG90aGVyIHRocmVhZCBmb3Igc28gbWFueSB0aW1lcyBhcyB5b3Uga25v
dyBzbyBJIHRob3VnaHQgSSBwb2ludGVkIGl0IG91dCwgYnV0IG1pc3NlZCBhcHBhcmVudGx5IGlu
IG15IHByZXZpb3VzIGNvbW1lbnQuIFNvLCBJIHdvdWxkIGFkZCBteSAxMnRoIGNvbmRpdGlvbjoN
Cg0KMTIuIEEgd2F5IHRvIGV4cHJlc3MgYSBsaXN0IG9mIHZhbGlkIFJTcyBmb3IgdGhpcyBBUyBu
ZWVkcyB0byBiZSBhZGRlZCB0byBzZWN0aW9uIDIuDQoNCkJlc3QsDQoNCk5hdA0KDQoyMDE2LTAz
LTExIDI6MDkgR01UKzA5OjAwIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj46DQpJIHN0cm9uZ2x5IG9wcG9zZS4gMiBtYWpv
ciBpc3N1ZXMuDQoNClRoaXMgaXMgbm90IHNlcnZpY2UgZGlzY292ZXJ5IHRoaXMgaXMgY29uZmln
dXJhdGlvbiBsb29rdXAuIFRoZSBjbGllbnQgbXVzdCBoYXZlIGFscmVhZHkgZGlzY292ZXJlZCB0
aGUgb2F1dGggaXNzdWVyIHVyaSBhbmQgdGhlIHJlc291cmNlIHVyaS4NCg0KVGhlIG9iamVjdGl2
ZSB3YXMgdG8gcHJvdmlkZSBhIG1ldGhvZCB0byBlbnN1cmUgdGhlIGNsaWVudCBoYXMgYSB2YWxp
ZCBzZXQgb2YgZW5kcG9pbnRzIHRvIHByZXZlbnQgbWl0bSBvZiBlbmRwb2ludHMgbGlrZSB0aGUg
dG9rZW4gZW5kcG9pbnQgdG8gdGhlIHJlc291cmNlIHNlcnZlci4NCg0KVGhlIGRyYWZ0IGRvZXMg
bm90IGFkZHJlc3MgdGhlIGlzc3VlIG9mIGEgY2xpZW50IGJlaW5nIGdpdmVuIGEgYmFkIGVuZHBv
aW50IGZvciBhbiBycy4gV2hhdCB3ZSBlbmQgdXAgd2l0aCBpcyBhIHByb21pc2N1b3VzIGF1dGh6
IHNlcnZpY2UgZ2l2aW5nIG91dCB0b2tlbnMgdG8gYW4gdW53aXR0aW5nIGNsaWVudC4NCg0KUGhp
bA0KDQpPbiBNYXIgMTAsIDIwMTYsIGF0IDA4OjA2LCBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRp
bWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+IHdyb3Rl
Og0KKzEgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlc2UNCk9uIDEwLzAzLzE2IDE3OjM1LCBCcmlh
biBDYW1wYmVsbCB3cm90ZToNCg0KKzENCg0KDQoNCk9uIFRodSwgTWFyIDEwLCAyMDE2IGF0IDY6
MDQgQU0sIFJvbGFuZCBIZWRiZXJnIDxyb2xhbmQuaGVkYmVyZ0B1bXUuc2U+PG1haWx0bzpyb2xh
bmQuaGVkYmVyZ0B1bXUuc2U+DQoNCndyb3RlOg0KDQoNCg0KSSBzdXBwb3J0IHRoaXMgZG9jdW1l
bnQgYmVpbmcgbW92ZWQgZm9yd2FyZCB3aXRoIHRoZXNlIHR3byBjaGFuZ2VzOg0KDQoNCg0KLSBj
aGFuZ2UgbmFtZSB0byDigJxPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgRGlzY292ZXJ5
IE1ldGFkYXRh4oCdIGFzDQoNCnByb3Bvc2VkIGJ5IEJyaWFuIGFuZA0KDQotIHVzZSB0aGUgVVJJ
IHBhdGggc3VmZml4IOKAmW9hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCZIGluc3RlYWQgb2YN
Cg0K4oCZb3BlbmlkLWNvbmZpZ3VyYXRpb27igJkgYXMgcHJvcG9zZWQgYnkgSnVzdGluLg0KDQoN
Cg0KMTggZmViIDIwMTYga2wuIDE0OjQwIHNrcmV2IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMu
dHNjaG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pg0KDQo6
DQoNCg0KDQpIaSBhbGwsDQoNCg0KDQpUaGlzIGlzIGEgTGFzdCBDYWxsIGZvciBjb21tZW50cyBv
biB0aGUgIE9BdXRoIDIuMCBEaXNjb3ZlcnkNCg0Kc3BlY2lmaWNhdGlvbjoNCg0KaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxPGh0dHBzOi8v
bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm
dG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEmZGF0
YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZh
NTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0
YT13MyUyYmlpYVdvbjgxTEpDVSUyYjJtQ1BSbUElMmJyRUNCSGdxeVJyME9ncWlXU0hVJTNkPg0K
DQoNCg0KU2luY2UgdGhpcyBkb2N1bWVudCB3YXMgb25seSBhZG9wdGVkIHJlY2VudGx5IHdlIGFy
ZSBydW5uaW5nIHRoaXMgbGFzdA0KDQpjYWxsIGZvciAqKjMgd2Vla3MqKi4NCg0KDQoNClBsZWFz
ZSBoYXZlIHlvdXIgY29tbWVudHMgaW4gbm8gbGF0ZXIgdGhhbiBNYXJjaCAxMHRoLg0KDQoNCg0K
Q2lhbw0KDQpIYW5uZXMgJiBEZXJlaw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5m
byUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFl
NmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmc2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJx
UjltNVdnQTJrJTNkPg0KDQrigJQgUm9sYW5kDQoNCg0KDQrigJ1FdmVyeWJvZHkgc2hvdWxkIGJl
IHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFtIGFuZCBsaXN0ZW4uIg0KDQo+RnJvbSDigJlPcGVu
IEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEtyYXVzcw0KDQoNCg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxp
bmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVs
aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v
cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw
bWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4
YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJi
ekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZD4NCg0KDQoNCg0KDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcg
bGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj
cm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4
NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekpp
WHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZD4NCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5m
byUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFl
NmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmc2RhdGE9dE5DaWttWERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJx
UjltNVdnQTJrJTNkPg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBP
cGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGh0dHBzOi8vbmEwMS5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZuYXQuc2Fr
aW11cmEub3JnJTJmJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2
ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk
MDExZGI0NyU3YzEmc2RhdGE9NkZWbWRON2FkMFl6b1lLU05GJTJmRE8lMmZmRzJFRjFoYWo1YU9I
aU1pZDZVTUklM2Q+DQpAX25hdF9lbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o
dHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRh
dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZi
ODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2Rh
dGE9YktzRVZCVVhjNTI4eWFBTUxteWNYY0wzMyUyYkZKQ1FybnE5YXN4Um81SGU4JTNkPg0KDQoN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo
IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2Fm
ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRm
Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl
NDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9YktzRVZCVVhjNTI4eWFBTUxt
eWNYY0wzMyUyYkZKQ1FybnE5YXN4Um81SGU4JTNkPg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMw
MDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgQVMg
bWV0YWRhdGEgZm9ybWF0IGlzIGEgbmVjZXNzYXJ5IHBhcnQgb2YgZGlzY292ZXJ5LiZuYnNwOyBO
bywgaXQgZG9lc27igJl0IGFjY29tcGxpc2ggZXZlcnkgcG9zc2libGUgYXNwZWN0IG9mIGRpc2Nv
dmVyeSDigJMgbm9yIHdhcyBpdCBldmVyIGludGVuZGVkIHRvLiZuYnNwOyBJ4oCZdmUgY29uc2lz
dGVudGx5DQogZW5jb3VyYWdlZCBQaGlsIGFuZCBvdGhlcnMgdG8gd3JpdGUgZG93biBhZGRpdGlv
bmFsIGFzcGVjdHMgb2YgZGlzY292ZXJ5IGluIHNwZWNpZmljYXRpb25zIHRoYXQgYnVpbGQgdXBv
biB0aGlzIG9uZSBzbyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGFuZCBpbXBsZW1lbnRlcnMgY2Fu
IGV2YWx1YXRlIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw
Ij5TaW5jZSB3ZeKAmXJlIGNoYXJ0ZXJlZCB0byBkbyBkaXNjb3ZlcnkgYW5kIHRoaXMgaXMgcGFy
dCBvZiBkaXNjb3ZlcnksIG5vIHJlY2hhcnRlcmluZyBpcyBuZWVkZWQgZWl0aGVyIGZvciB0aGUg
Y3VycmVudCBzcGVjaWZpY2F0aW9uIG9yIGZvciBuZXcgc3BlY2lmaWNhdGlvbnMNCiBwZXJmb3Jt
aW5nIGFkZGl0aW9uYWwgZGlzY292ZXJ5IHRhc2tzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbnRob255IE5hZGFsaW4NCjxi
cj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgODoyMCBBTTxicj4NCjxi
PlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozsg
QnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsgSm9obiBC
cmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZs
dDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10g
V29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2Ug
YWdyZWVkIHVwb24gYSBkaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbiB0aGF0IHRoZSBXRyB3b3VsZCB3
b3JrIG9uLCB3ZSBkaWQgbm90IGFncmVlIHVwb24gd2hhdCB0aGlzIGhhcyB0dXJuZWQgb3V0IHRv
IGFjdHVhbGx5IGJlLCBzbyBhdCB0aGUgbWluaW11bSB0aGUgY2hhaXJzIHNob3VsZCBjYWxsDQog
Zm9yIGFkb3B0aW9uIG9mIGEgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGEgc3BlY2lmaWNh
dGlvbiBhbmQgd2UgY2FuIGNvbnRpbnVlIHRvIHdvcmsgb24gYSBEaXNjb3Zlcnkgc3BlY2lmaWNh
dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1pa2UgSm9uZXMNCjxicj4NCjxiPlNl
bnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgODowNiBBTTxicj4NCjxiPlRvOjwvYj4g
QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29t
Ij50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhy
ZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVu
dGl0eS5jb208L2E+Jmd0OzsgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRi
QHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9h
dXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9h
PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBM
YXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUg
ZHJhZnQgZW5hYmxlcyBlYXN5IGNvbmZpZ3VyYXRpb24gb2YgT0F1dGggY2xpZW50cyB3aXRoIGFu
IEFTLiZuYnNwOyBGb3IgaW5zdGFuY2UsIHRoZSBNaWNyb3NvZnQg4oCcQURBTOKAnSBPQXV0aCBj
bGllbnQgc29mdHdhcmUgdXNlcyBBUyBtZXRhZGF0YSBpbiB0aGlzIGZvcm1hdCBhcw0KIGFuIGlu
cHV0IGF0IGNsaWVudCBjb25maWd1cmF0aW9uIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDAyMDYwIj5BcyBhIHNpZGUgYmVuZWZpdCwgaGF2aW5nIHRoaXMgc3RhbmRh
cmQgQVMgbWV0YWRhdGEgZm9ybWF0IGFuZCByZXR1cm5pbmcgdGhlIGlzc3VlciBVUkwgcGVyIHRo
ZSBNaXgtVXAgTWl0aWdhdGlvbiBkcmFmdCB3aWxsIGFsc28gZW5hYmxlIGNsaWVudHMgdG8gdmFs
aWRhdGUgdGhhdA0KIHRoZXkgYXJlIHVzaW5nIGEgY29uc2lzdGVudCBzZXQgb2YgQVMgZW5kcG9p
bnRzIGFuZCBpbmZvcm1hdGlvbi4mbmJzcDsgQnV0IGV2ZW4gd2l0aG91dCB0aGUgbWl0aWdhdGlv
biBiZW5lZml0cywgdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIGJlbmVmaXQgaXMgdGhlIHByaW1h
cnkgcmVhc29uIGZvciB0aGUgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+QW50aG9ueSBOYWRhbGluPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMTEsIDIw
MTYgMzoyNSBQTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h
aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j
b208L2E+Jmd0OzsgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0
Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZs
dDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENh
bGwgb24gT0F1dGggMi4wIERpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGlzYWdyZWUsIHdoYXQgcHVycG9zZSBp
cyB0aGlzIGFjdGl2aXR5IHNvbHZpbmcgdGhlbiwgaXQgd2FzIGJlaW5nIHB1c2hlZCBhcyB3aGF0
IHdhcyBuZWVkIHRvIHNvbHZlIHRoZSBNaXgtdXAsIGJ1dCB0aGF0IGlzIG5vdCB0cnVlLiBTbyBu
b3cgeW91IGFyZSBzdWdnZXN0aW5nIGEgY2hhbmdlIGluDQogc2NvcGUgYW5kIG5vdCBkZWFsaW5n
IHdpdGggZGlzY292ZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn
Ij5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
PkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMTEsIDIwMTYg
MzoxMSBQTTxicj4NCjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86
dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8
L2I+IG9hdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYu
b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gV29ya2luZyBH
cm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB0ZW5kIHRv
IGFncmVlIHdpdGggSm9obiB0aGF0IGFkZHJlc3NpbmcgdGhlIGNvbmNlcm5zIFBoaWwgcmFpc2Vz
IHNob3VsZCBiZSBwYXJ0IG9mIChleHRlbnNpb24gdG8pIHRoZSBjb3JlIHByb3RvY29sLiZuYnNw
OyBBbmQgdGhhdCB0aG9zZSBraW5kcyBvZiBjb25jZXJucyBkb24ndCBtYW5pZmVzdCBpbiB0aGUg
d2F5IE9BdXRoIGlzIHR5cGljYWxseSBkZXBsb3llZA0KIG5vdy4gPGJyPg0KPGJyPg0KVGhlIGhv
cGVmdWxseSBzb29uIHRvIGJlIG5hbWVkICZxdW90O09BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNl
cnZlciBNZXRhZGF0YSZxdW90OyBzaG91bGQga2VlcCBpdCdzIHNjb3BlIHRvIHRoZSBwdWJsaXNo
aW5nIG9mIGF1dGhvcml6YXRpb24gc2VydmVyIG1ldGFkYXRhLiBUaGUgYWN0IG9mIGRvaW5nIGRp
c2NvdmVyeSBpcyBiZXlvbmQgaXRzIHNjb3BlIGFuZCBzbyBpcyB0cnlpbmcgdG8gcHJldmVudCBh
IGNsaWVudCBmcm9tIHByZXNlbnRpbmcgYSB0b2tlbiB0bw0KIHNvbWVwbGFjZSBpdCBzaG91bGRu
J3QuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJp
LCBNYXIgMTEsIDIwMTYgYXQgOTowOCBBTSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWls
dG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5saW5l
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
TWFyIDExLCAyMDE2LCBhdCAxMjoxMyBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJt
YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3Jh
Y2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gbWFueSBjYXNlIGFsbCB0aGUgQVMgaGFzIHRvIGNoZWNr
IGlzIHRoZSBkb21haW4gbmFtZSBjb21wb25lbnQgdG8gY2hlY2sgZm9yIG1pdG0uJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBPUCBh
bmQgdGhlIG90aGVyIHNvbG5zIGFyZSBkcmFtYXRpY2FsbHkgbW9yZSBjb21wbGV4IHRoYW4gYSBz
aW1wbGUgY2hlY2suJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHByb3Bvc2luZyBk
aW5nIHRoYXQgY2hlY2sgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb3IgdG9rZW4gZW5k
cG9pbnQgYXMgcGFydCBvZiBBVCBpc3N1YW5jZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgdXAgdG8gdGhlIEFTIGhvdyBt
dWNoIG9mIHRoZSBwYXRoIHRvIHZhbGlkYXRlIGFuZCBvciBwdXQgaW4gdGhlIGF1ZCBvciBkc3Qu
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIGl0IGFzIHBhcnQgb2YgdGhlIGRp
c2NvdmVyeShiYWQgbmFtZSBhc2lkZSkgcHJvYmxlbSBiZWNhdXNlIHdlIGRpc2N1c3NlZCB0aGF0
IGlmIGEgY2xpZW50IGZpbmRzDQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl
Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYXBwLmV4YW1wbGUuY29tJTJmJmFt
cDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1
MDk2Yjg0MDhkMzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx
JmFtcDtzZGF0YT1maVM4ZjYweXBpWGh5TTBxVlRlcWwlMmIlMmJPekgyd2JtRUNRRTdKNVR0R1BR
TSUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KYXBwLmV4YW1wbGUuY29tPC9hPiBob3cgZG8gd2UgZW5z
dXJlIGl0IGdldHMgYSBjb21wbGV0ZSBzZXQgb2Ygb2F1dGggZW5kcG9pbnRzIGFzIGEgdmFsaWQg
c2V0IG9mIGVuZHBvaW50cy0tdGhhdCBhIGhhY2tlciBoYXMgbm90IGluc2VydGVkIG9uZSBvZiB0
aGVpciBvd24gZW5kcG9pbnRzLiBUaGUgbW9zdCBpbXBvcnRhbnQgZW5kcG9pbnQgdG8gZ2V0IHJp
Z2h0IGlzIGVuc3VyaW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgKGFuZCBvcHRpb25hbGx5IHRoZQ0K
IHBhdGgpIGlzIHRoZSBjb3JyZWN0IG9uZS4gV2UgY2FuJ3QgcmVhbGx5IGRlZmluZSByZXNvdXJj
ZSBkaXNjb3ZlcnkgYnV0IHdlIGNhbiB2YWxpZGF0ZSBpdCB0byBzb21lIGRlZ3JlZS4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgaXMgcGFydCBvZiBjb3JlIHBy
b3RvY29sIHNlY3VyaXR5IGFuZCBzaG91bGQvbXVzdCBub3QgcmVxdWlyZSBkaXNjb3ZlcnkuJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PldoYXQgaXMgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv
b2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5leGFtcGxlLmNvbSZhbXA7ZGF0YT0wMSU3YzAx
JTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAz
MWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9akFz
WlFlQ2hKJTJiUjFsYnlCb1ZLd2hlSVlpM1BpV0xycSUyYnhETGJxVTZyeGslM2QiIHRhcmdldD0i
X2JsYW5rIj4NCmFwcC5leGFtcGxlLmNvbTwvYT4gPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBpdCBpcyB0aGUgcmVzb3VyY2Ug
dGhlbiB0aGUgY2xpZW50IHdvdWxkIGJlIHByZWNvbmZpZ3VyZWQgZm9yIGl04oCZcyBBUyBvdXQg
b2YgYmFuZCBvciBvcHRpb25hbGx5IHdvdWxkIGRvIGRpc2NvdmVyeSBvbiB0aGUgaXNzdWVyIHVy
aSB0aGF0IHlvdSBhZG1pdCBuZWVkcyB0byBiZSBjb25maWd1cmVkIG91dCBvZiBiYW5kIHNvbWUg
d2F5IChub3RlIGRpc2NvdmVyeSBpcyBvcHRpb25hbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIEFTIG1ldGEtZGF0YSBkcmFmdCBp
dCB3b3VsZCBkbyBhIGdldCBvbiBhIHdlbGwga25vd24gZmlsZSB0aGF0IHdvdWxkIGhhdmUgY29u
ZmlndXJhdGlvbiBmb3IgdGhlIEFTLCBidXQgbm90IHRoZSBSUywgdGhvdWdoIHNvbWUgQVBJIG1h
eSBvcHRpb25hbGx5IGxpc3QgYSBBUEkgZW5kcG9pbnQgbGlrZSBjb25uZWN0IGhhcy4gJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo
ZSBjbGllbnQgdGhlbiBtYWtlcyBhIGF1dGhvcml6YXRpb24gcmVxdWVzdCAoYWZ0ZXIgcmVnaXN0
ZXJpbmcgb3V0IG9mIGJhbmQgb3IgZHluYW1pY2FsbHkpLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHBhcnQgb2YgdGhlIGF1dGhv
cml6YXRpb24gcmVxdWVzdCBmb3IgaW1wbGljaXQgaXQgY291bGQgcHJvdmlkZSB0aGUgYXVkL2Rz
dCB0aGF0IGl0IHdhbnRzIHRoZSB0b2tlbiBmb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGF0IGlzIG5vdCBzZW50IHRoZW4gdGhlIGF1
ZC9kc3QgYXJlIGltcGxpY2l0IGluIHRoZSBzY29wZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjbGllbnQgZ2V0cyBiYWNrIGEgQVQg
d2l0aCBhIGxpc3Qgb2Ygc2NvcGVzIGdyYW50ZWQsIGF1ZC9kc3QgYWxsb3dlZCBhbmQgdGltZSB0
byBsaXZlIGZvciB0aGUgdG9rZW4gKG9uZSBleHRyYSB0aGluZyByZXR1cm5lZCk8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2VzbuKA
mXQgcmVxdWlyZSBhbnkgZGlzY292ZXJ5ICh5ZXMgdGhlcmUgaXMgYSBvcHRpb25hbCBBUyBtZXRh
LWRhdGEgZGlzY292ZXJ5IGJ1dCBub3QgcmVxdWlyZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcHJlZmVyIHRvIGZpeCB0aGUgUlMgbWFu
IGluIHRoZSBtaWRkbGUgaXNzdWUgYXMgcGFydCBvZiB0aGUgcHJvdG9jb2wgYW5kIG5vdCBwYXJ0
IG9mIGRpc2NvdmVyeSB0aGF0IHNob3VsZCByZW1haW4gb3B0aW9uYWwuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaG9uZXN0bHkgZG9u4oCZ
dCBxdWl0ZSBrbm93IGhvdyB0aGUgY2xpZW50IGxlYXJucyBhYm91dCB0aGlzIGJhZCBSUyBhbmQg
c3RhcnRzIHRhbGtpbmcgdG8gaXQsIHNvIHRoaXMgbWF5IGJlIGEgc29sdXRpb24gdG8gYSBwcm9i
bGVtIHRoYXQgZG9lc27igJl0IHlldCBleGlzdC4gJm5ic3A7IFRoZSBvbmUgcGxhY2UgdGhpcyBp
cyBwb3NhYmxlIGlzIGlmIHRoZSByZWdpc3RyYXRpb24gZm9yIHRoZSBjbGllbnQgaXMgY29tcHJv
bWlzZWQuJm5ic3A7DQogSG93ZXZlciB3ZSBhcmUgZGlzY3Vzc2luZyBvdGhlciBtaXRpZ2F0aW9u
cyBmb3IgdGhhdCB0aGF0IGFsc28gZXhwbGljaXRseSBkbyBub3QgcmVxdWlyZSBkaXNjb3Zlcnku
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpv
aG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90
IHN0dWNrIG9uIHdlYmZpbmdlciBvciB3ZWxsLWtub3duLiBCZWNhdXNlIHRoaXMgaXMgY29uZmln
IG1heWJlIGl0IHNob3VsZCBiZSBhbiBvYXV0aCBlbmRwb2ludC4mbmJzcDs8YnI+DQo8YnI+DQpQ
aGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE1hciAxMSwgMjAxNiwgYXQgMDY6
NTEsIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0
YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBQaGls
IGlzIHByb3Bvc2luZyBzb21ldGhpbmcgZGlmZmVyZW50LiAmbmJzcDsgU2hvdWxkIHRoZSBjbGll
bnQgc2VuZCBhIHRva2VuIGZyb20gdGhpcyBBUyB0byB0aGF0IFJTLiAmbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpcyBnb2FsIGlzIHRvIHByZXZl
bnQgbWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrcyB3aGVyZSBhIGJhZCBSUyBnZXRzIGEgQVQgdGhh
dCBpcyBhdWRpYW5jZWQgdG8vYWNjZXB0ZWQgYnkgYW5vdGhlciBSUy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBzZXBhcmF0ZSBm
cm9tIHRoZSBxdWVzdGlvbiBvZiBpZiBhIFJTIGFjY2VwdHMgdG9rZW5zIGZyb20gYSBnb29kIEFT
LiAmbmJzcDsgQSBiYWQgQVMgd291bGQgYWx3YXlzIHNheSB5ZXMuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIG5lZWQgdG8gYmUgY2FyZWZ1
bCBvZiB3aGF0IGlmIGFueXRoaW5nIHRoZSBSUyBwcm92aWRlcyB0byB0aGUgY2xpZW50IGFzIG1l
dGEtZGF0YSB3aXRob3V0IHZhbGlkYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN1cnJlbnRseSB0aGUgY2xpZW50IGNhbiBwcm92aWRl
IGEgbGlzdCBvZiBzY29wZXMgcmVxdWlyZWQgdG8gZ2V0IGFjY2Vzcy4gJm5ic3A7IEkgcGVyc29u
YWxseSBmZWVsIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBhbHNvIGluY2x1ZGUgaW4gdGhlIHVuYXV0
aGVudGljYXRlZCBlcnJvciByZXNwb25zZSBhbiBpbmRpY2F0aW9uIG9mIHdoYXQgQVBJIHRoZSBy
ZXNvdXJjZSBzdXBwb3J0cy4mbmJzcDsgU2F5IOKAnHNjaW0y4oCdIGFzIGFuIGV4YW1wbGUuDQog
Jm5ic3A7IEkgZG9u4oCZdCB0aGluayBhZGRpbmcgdGhhdCBpcyBob3dldmVyIGEgaGlnaCBwcmlv
cml0eSBhcyBtb3N0IGlmIGFsbCBjbGllbnRzIGtub3cgd2hhdCBBUEkgdGhleSBleHBlY3QuICZu
YnNwOyBJdCBtaWdodCBiZSB1c2VmdWwgaWYgYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlIGlm
IGEgY2xpZW50IHdlcmUgdG8gYmUgZ2l2ZW4gYSBSUyBVUkkgaXQgY291bGQgY2hlY2sgdG8gc2Vl
IGlmIGl0IGlzIGEgcHJvdG9jb2wgdGhhdCBpdCBzdXBwb3J0cyBiZWZvcmUNCiBib3RoZXJpbmcg
d2l0aCBPQXV0aC4gJm5ic3A7ICZuYnNwO0kgZXhwZWN0IHRoYXQgYSBsb3Qgb2YgcGVvcGxlIHdp
bGwgd2FudCB0aGF0IGxlZnQgdG8gdGhlIEFQSSBkZWZpbml0aW9uLiAmbmJzcDsgSSB0aGluayB3
ZSBjYW4gdGFsayBhYm91dCBpdCBidXQgcmF0ZSB0aGlzIGxvdyBwcmlvcml0eS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0
IHRoZSBSUyBnaXZpbmcgb3V0IGEgbGlzdCBvZiBBUyB0aGF0IGl0IHRydXN0cyBpcyBhIGdlbmVy
YWxseSBiYWQgaWRlYS4mbmJzcDsgSSBob3BlIHRoYXQgaXMgbm90IG9uIHRoZSB0YWJsZS48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27i
gJl0IHRoaW5rIHRoYXQgcHJldmVudGluZyBhIGNsaWVudCBmcm9tIHNlbmRpbmcgYSB0b2tlbiB0
byB0aGUgd3JvbmcgUlMgaXMgcGFydCBvZiBhIEFTIG1ldGEtZGF0YSBkaXNjb3ZlcnkgcHJvYmxl
bS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSBkbyBob3dldmVyIHRoaW5rIHRoYXQgaXQgaXMgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGJlZW4gZGlzY3Vz
c2luZyB0aGlzIGFzIGEgc2VwYXJhdGUgcHJvYmxlbSB0byBBUyBtZXRhLWRhdGEgZGlzY292ZXJ5
IHdoZXJlIHRoZSBlbmRwb2ludHMgb2YgdGhlIEFTIGFuZCBpdOKAmXMgY29uZmlndXJhdGlvbiBh
cmUgZGlzY292ZXJ5LiAmbmJzcDsgU29ycnkgZm9yIHBlcmhhcHMgc3RhdGluZyB0aGUgb2J2aW91
cywgYnV0IHRoZSBSUyBpcyBleHBsaWNpdGx5IG5vdCBwYXJ0IG9mIHRoZSBBUyBpbiBPQXV0aA0K
IDIuICZuYnNwOyBTdGFydGluZyBpbiBXQVAgdGhhdCB3YXMgYSBjb3JlIHByaW5jaXBhbC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gd2Ug
aGF2ZSBhIG51bWJlciBvZiBvcHRpb25zIHRvIGFkZHJlc3MgdGhlIFJTIHRva2VuIGxlYWthZ2Ug
dmlhIE1pVE0gYXR0YWNrcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+MSkgUG9QIGJvdW5kIHRva2Vucy4mbmJzcDsgSWYgdGhleSBhcmUgYm91
bmQgdG8gdGhlIFRMUyBjaGFubmVsIGJ5IG11dHVhbCBUTFMgb3IgVG9rZW4gYmluZGluZyB0aGV5
IGNhbm5vdCBiZSByZXBsYXllZC4mbmJzcDsgU2lnbmVkIG1lc3NhZ2VzIHdoZXJlIHRoZSBzaWdu
aW5nIGNvdmVycyB0aGUgUlMgSG9zdCBhbmQgcGF0aCBjb21wb25lbnRzLCAmbmJzcDthbHNvIHdv
dWxkIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjIpIEhhdmUgdGhlIEFTIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSByZXNvdXJjZXMgdGhl
IEFUIGlzIGdvb2QgYXQuIChBVCBzaG91bGQgYmUgZG9pbmcgdGhhdCBub3cpJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgdG9r
ZW4gcmVzcG9uc2UgaW5jbHVkZSB0aGUgbGlzdCBvZiBhdWRpZW5jZS9zIHRoZSB0b2tlbiBpcyBw
cmVzZW50YWJsZSBhdC4mbmJzcDsgVGhlIGNsaWVudCB3b3VsZCB0aHJvdyBhbiBlcnJvciBpZiB0
aGUgUlMgaXQgaW50ZW5kcyB0byBzZW5kIHRoZSB0b2tlbiB0byBpcyBub3Qgb24gdGhlIGxpc3Qu
ICZuYnNwOyBUaGUgUlMgdGhlIHRva2VuIGlzIGdvb2QgYXQgbWlnaHQgY2hhbmdlIGJhc2VkIG9u
IHNjb3BlcywNCiBjbGllbnRfaWQgYW5kIHJlc291cmNlIG93bmVyLiAmbmJzcDsgVGhpcyBpcyB0
aGUgcGxhY2Ugd2hlcmUgYWxsIG9mIHRoYXQgY29tZXMgdG9nZXRoZXIuICZuYnNwOyBJbiBzb21l
IGNhc2VzIHRoZSBSUyBhbmQgQVMgbWlnaHQgbm90IGhhdmUgYSBwcmUtZXN0YWJsaXNoZWQgcmVs
YXRpb25zaGlwLiAmbmJzcDsgVGhlIGNsaWVudCBzaG91bGQgc2VuZCB0aGUgUlMgYmFzZSBVUkkg
dG8gdGhlIEFTIGFzIHBhcnQgb2YgdGhlIHJlcXVlc3QuJm5ic3A7IFRoZSBBUyBjYW4gdXNlIHRo
YXQNCiB0byBhdWRpZW5jZSByZXN0cmljdCB0aGUgQVQgYW5kIGlzc3VlIHRoZSBBVCBvciByZWZ1
c2UgdG8gaXNzdWUgdGhlIEFUIGJhc2VkIG9uIHBvbGljeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGNhbiBhbHNvIHVzZSB0aGUgYXVkaWVu
Y2UgaW4gdGhlIHJlcXVlc3QgdG8gZG93biBhdWRpZW5jZSB0aGUgQVQgaWYgdGhlIGRlZmF1bHQg
aXMgdG8gaGF2ZSBtdWx0aXBsZSBhdWRpZW5jZXMuICZuYnNwOyAmbmJzcDtXZSBtYXkgd2FudCB0
byB1c2UgYSB0ZXJtIG90aGVyIHRoYW4gYXVkaWVuY2UgZm9yIHRoaXMgbGlrZSByZXNvdXJjZSBv
ciBkZXN0aW5hdGlvbi4mbmJzcDsgSXQgaXMgYSBhdWRpZW5jZSBidXQgdGhhdCB0ZXJtIG1pZ2h0
DQogY29uZnVzZSBwZW9wbGUgd2l0aCBBVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgZGlkIHRhbGsgYWJvdXQgYnJlYWtpbmcgYXVkaWVu
Y2Ugb3V0IG9mIFBPUCBrZXkgZGlzdHJpYnV0aW9uLCBhbmQgQnJpYW4gQ2FtcGJlbGwgZGlkIGEg
ZHJhZnQmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0
bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0
LWNhbXBiZWxsLW9hdXRoLWRzdDRqd3QmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPVNUciUyYjRrcmQxaHk4aDZlSE9D
TGgxUHpRYUtNVWhXbEtWMmklMmZDTDBLMVNRJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLWRzdDRqd3Q8L2E+Lg0KICZu
YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UbyBkbyB0aGlzIHdlIGNvdWxkIHRha2UgZHN0NGp3dCBhbmQgYWRkIGFub3RoZXIg
c3BlYyB0aGF0IGFkZHMgYSBuZXcgZHN0IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gYW5kIGF1dGhv
cml6YXRpb24gZW5kcG9pbnRzIHJlcXVlc3RzIFRoYXQgd291bGQgYmUgYSBzcGFjZSBzZXBhcmF0
ZWQgbGlzdCBvZiBkc3QgdmFsdWVzLiAmbmJzcDthbmQgaW4gdGhlIHJlc3BvbnNlIGZyb20gdGhl
IHRva2VuIGVuZHBvaW50IHdvdWxkDQogYmUgYSBKU09OIGFycmF5IG9mIGRzdCB2YWx1ZXMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIEhh
dmUgdGhlIEFTIGFsd2F5cyByZXR1cm4gYWxsIHRoZSBsaXN0IG9mIGFsbCBSUyB0aGUgdG9rZW4g
Y2FuIGJlIHVzZWQgYXQgKGJhc2ljYWxseSBOYXQncyBsaW5rIHJlbGF0aW9uc2hpcCBwcm9wb3Nh
bCkuJm5ic3A7IEl0IG5lZWRzIGEgd2F5IHRvIGhhbmRsZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZG93biBkZXN0aW5hdGlvbmluZyBv
ZiBBVCBhbmQgdG8gYWxsb3cgZm9yIHVuLWNvbmZpZ3VyZWQgUlMgdGhhdCBpdCBtaWdodCBpc3N1
ZSBhIHRva2VuIGZvci4mbmJzcDsgU28gY291bGQgYmUgY29tYmluZWQgd2l0aCBkc3QgZnJvbSAy
LiZuYnNwOyBCYXNpY2FsbHkgcmV0dXJuaW5nIHRoZSBhY2NlcHRhYmxlIGRlc3RpbmF0aW9ucyBh
cyBsaW5rIGhlYWRlcnMgdnMgSlMgaW4gdGhlIHJlc3BvbnNlIGlzIG1vc3RseSBhIHN0eWxlDQog
aXNzdWUgdGhhdCBvdGhlciBwZW9wbGUgY2FuIGJpa2Ugc2hlZC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSBUcnlpbmcgdG8gYWRkIGFs
bCB0aGUgUlMgdG8gdGhlIEFTIGRpc2NvdmVyeSBkb2N1bWVudC4mbmJzcDsgVGhpcyBzZWVtcyBp
bXByYWN0aWNhbCBhcyB0aGVyZSB3b3VsZCBiZSBtdWx0aXBsZSBwcm90b2NvbHMgYW5kIGRvZXNu
4oCZdCBhZGRyZXNzIHVuLWNvbmZpZ3VyZWQgUlMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUpIFNvbWUgbmV3IEFTIGVuZHBvaW50IHRoYXQg
dGhlIGNsaWVudCBjb3VsZCBpbnRyb3NwZWN0IHRoZSBSUyBVUkkgYW5kIGdldCBiYWNrIG1ldGFk
YXRhIGFib3V0IGlmIHRoZSBjbGllbnQgc2hvdWxkIHNlbmQgdG9rZW5zIHRoZXJlLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw
OyBBIGNvdXBsZSBvZiBwcm9ibGVtcyB3aXRoIHRoaXMuJm5ic3A7IFRoZSBmaXJzdCBpcyB0aGF0
IGl0IHdvdWxkIG5vdCBzdXBwb3J0IHVuLWNvbmZpZ3VyZWQgUlMgdW5sZXNzIHlvdSBhZGQgZHN0
IHRvIHRoZSB0b2tlbiBhbmQgYXV0aG9yaXphdGlvbiBlbmRwb2ludHMuICZuYnNwOyBUaGUgb3Ro
ZXIgaXMgdGhhdCB0aGUgaW50cm9zcGVjdGlvbiBlbmRwb2ludCBkb2VzbuKAmXQgaGF2ZSB0aGUg
Y29udGV4dCBvZiB0aGUgUk8NCiBhbmQgY2xpZW50X2lkIHVubGVzcyB5b3UgYWxzbyBwYXNzIHRo
ZSBjb2RlL1JUIGFuZCBjbGllbnRfaWQsIGFuZCBwcm9iYWJseSBjbGllbnQgY3JlZGVudGlhbHMu
ICZuYnNwOyAmbmJzcDtCYXNpY2FsbHkgdGhpcyBpcyB0cnlpbmcgdG8gaW50cm9zcGVjdCB0aGUg
QVQgdG8gZGV0ZXJtaW5lIHRoZSBhdWRpYW5jZS9kc3QuICZuYnNwOyBCeSB0aGUgdGltZSB5b3Ug
YnVpbGQgYSBuZXcgaW50cm9zcGVjdGlvbiBlbmRwb2ludCBzZWN1cmVseSBpdCBpcyBnb2luZyB0
byBsb29rDQogbGlrZSB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCBhIGJpdCBtb3JlIG1ldGEgZGF0
YSBhYm91dCB0aGUgdG9rZW4gYmV5b25kIGV4cGlyeSBhbmQgc2NvcGVzLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2Ugc2hv
dWxkIGdvIGEgaGVhZCB3aXRoIHRoZSByZW5hbWVkICZxdW90O09BdXRoIDIuMCBBdXRob3JpemF0
aW9uIFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRhdGHigJ0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYWxzbyBmaW5lIHdpdGggbWFr
aW5nIHRoZSBkZWZhdWx0IGRvY3VtZW50ICdvcGVuaWQtY29uZmlndXJhdGlvbuKAmSAmbmJzcDth
cyBsb25nIGFzIHdlIGFsbG93IGZvciBwcm90b2NvbCBzcGVjaWZpYyB2YXJpYXRpb24gc28gdGhh
dCBTQ0lNMiBjb3VsZCBkZWZpbmUgYSBmaWxlIG5hbWUuICZuYnNwOyAmbmJzcDtJZiBwZW9wbGUg
d2FudCB3ZSBjb3VsZCBkbyBhIEFQSSAmbmJzcDt0byBmaWxlIG5hbWUgcmVnaXN0cnkgc28gdGhh
dCBwcm90b2NvbA0KIHNwZWNpZmljIG9uZXMgY2FuIGJlIGRlZmluZWQuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBhbGwtcmVhZHkg
d29ya2luZyBvbiBvcHRpb24gMSB0byBzZWN1cmUgQVQsIHdlIG5lZWQgYSBzcGVjIGxpa2UgSSBw
cm9wb3NlIGluIDIgZm9yIGJlYXJlciB0b2tlbnMuJm5ic3A7IFdlIGNhbiBhZGQgb25lIHJlcXVl
c3QgcGFyYW1ldGVyIGFuZCBhIGJpdCBtb3JlIHRva2VuIG1ldGEtZGF0YSB0byB0aGUgdG9rZW4g
cmVzcG9uc2UgYW5kIHRoYXQgdGFrZXMgY2FyZSBvZiB0aGUgcHJvYmxlbS4gJm5ic3A7IEhvbmVz
dGx5DQogd2UgcHJvYmFibHkgc2hvdWxkIGhhdmUgc2VwYXJhdGVkIHNjb3BlIGFuZCBkZXN0aW5h
dGlvbiBpbiB0aGUgZmlyc3QgcGxhY2UgYW5kIHJldHVybmVkIGJvdGggZHN0IGFuZCBzY29wZSBp
biB0aGUgcmVzcG9uc2UgYWxsIGFsb25nLCBzbyB0aGlzIGlzIHVwZGF0ZSB0aGF0IGlzIGNvbnNp
c3RlbnQgd2l0aCB0aGUgZWlzdGluZyBhcmNoaXRlY3R1cmUgb2YgT0F1dGggMi48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0cyBrZWVwIHRo
ZSB0d28gaXNzdWVzIHNlcGFyYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMTEs
IDIwMTYsIGF0IDEyOjA3IEFNLCBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0
b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBB
UyBhbmQgUlMgbmVlZCB0byBiZSBzY29wZWQgdG8g4oCcZG9lcyB0aGlzIFJTIGFjY2VwdCB0b2tl
bnMgZnJvbSB0aGlzIEFT4oCdIGFzIGEgbGlzdCBpcyB0b28gbXVjaCBpbmZvcm1hdGlvbiB0aGF0
IGNvdWxkIGJlIHVzZWQgaW4gdGhlIHdyb25nIHdheTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9IjEyNzI4OTY0MjlfX01h
aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO09BdXRoIFs8YSBo
cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0
bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0mbmJzcDs8Yj5Pbg0KIEJlaGFsZiBPZiZuYnNw
OzwvYj5OYXQgU2FraW11cmE8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDtUaHVyc2RheSwgTWFyY2gg
MTAsIDIwMTYgNjoyNSBQTTxicj4NCjxiPlRvOjwvYj4mbmJzcDtQaGlsIEh1bnQgKElETSkgJmx0
OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBo
aWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7b2F1dGggJmx0
OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGll
dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSZTogW09BVVRILVdHXSBX
b3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UGhpbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJpZ2h0LiBTbyB3aGF0IG15IGNvbmRpdGlv
bmFsIGFwcHJvdmFscyAoMTEgY29uZGl0aW9ucyBpbiB0b3RhbCkgc2FpZCB3YXMgdG8gZHJvcCB0
aGUgd29yZCAmcXVvdDtkaXNjb3ZlcnkmcXVvdDsgZnJvbSBldmVyeXdoZXJlLiBUaGlzIGlzIG5v
dCBhIGRpc2NvdmVyeSBzcGVjLiBUaGlzIGlzIGEgY29uZmlndXJhdGlvbiBsb29rdXAgc3BlYyBh
cyB5b3UgY29ycmVjdGx5IHBvaW50cyBvdXQuIFNvLCBJIGFtIHdpdGggeW91IGhlcmUuJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIG15IDJuZCBjb25kaXRpaW9uIGlzIGVz
c2VudGlhbGx5IHNheWluZyB0byBkcm9wIHNlY3Rpb24gMy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T25lIHRoaW5nIHRoYXQgSSBvdmVybG9va2VkIGFuZCBhbSB3aXRoIHlvdSBp
cyB0aGF0IHdlIG5lZWQgdG8gYmUgYWJsZSB0byBleHByZXNzIHRoZSBBUy1SUyByZWxhdGlvbnNo
aXBzLiBJIGhhdmUgYmVlbiBwcmVhY2hpbmcgdGhpcyBpbiB0aGUgb3RoZXIgdGhyZWFkIGZvciBz
byBtYW55IHRpbWVzIGFzIHlvdSBrbm93IHNvIEkgdGhvdWdodCBJIHBvaW50ZWQgaXQgb3V0LCBi
dXQgbWlzc2VkIGFwcGFyZW50bHkNCiBpbiBteSBwcmV2aW91cyBjb21tZW50LiBTbywgSSB3b3Vs
ZCBhZGQgbXkgMTJ0aCBjb25kaXRpb246Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjEyLiBBIHdheSB0byBleHByZXNzIGEgbGlzdCBvZiB2YWxpZCBSU3MgZm9yIHRoaXMgQVMgbmVl
ZHMgdG8gYmUgYWRkZWQgdG8gc2VjdGlvbiAyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5CZXN0LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+MjAxNi0wMy0xMSAyOjA5IEdNVCYjNDM7MDk6MDAgUGhpbCBIdW50
IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwv
c3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y
aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5JIHN0cm9uZ2x5IG9wcG9zZS4gMiBtYWpvciBpc3N1ZXMuJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgbm90IHNlcnZpY2UgZGlzY292ZXJ5
IHRoaXMgaXMgY29uZmlndXJhdGlvbiBsb29rdXAuIFRoZSBjbGllbnQgbXVzdCBoYXZlIGFscmVh
ZHkgZGlzY292ZXJlZCB0aGUgb2F1dGggaXNzdWVyIHVyaSBhbmQgdGhlIHJlc291cmNlIHVyaS4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG9iamVjdGl2ZSB3YXMgdG8gcHJv
dmlkZSBhIG1ldGhvZCB0byBlbnN1cmUgdGhlIGNsaWVudCBoYXMgYSB2YWxpZCBzZXQgb2YgZW5k
cG9pbnRzIHRvIHByZXZlbnQgbWl0bSBvZiBlbmRwb2ludHMgbGlrZSB0aGUgdG9rZW4gZW5kcG9p
bnQgdG8gdGhlIHJlc291cmNlIHNlcnZlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGhlIGRyYWZ0IGRvZXMgbm90IGFkZHJlc3MgdGhlIGlzc3VlIG9mIGEgY2xpZW50IGJlaW5n
IGdpdmVuIGEgYmFkIGVuZHBvaW50IGZvciBhbiBycy4gV2hhdCB3ZSBlbmQgdXAgd2l0aCBpcyBh
IHByb21pc2N1b3VzIGF1dGh6IHNlcnZpY2UgZ2l2aW5nIG91dCB0b2tlbnMgdG8gYW4gdW53aXR0
aW5nIGNsaWVudC4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0K
UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
Pjxicj4NCk9uIE1hciAxMCwgMjAxNiwgYXQgMDg6MDYsIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWlyQGNvbm5lY3QyaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dmxhZGltaXJAY29ubmVjdDJpZC5jb208L3NwYW4+
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+JiM0MzsxIHRvIG1vdmUg
Zm9yd2FyZCB3aXRoIHRoZXNlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIDEwLzAzLzE2IDE3OjM1LCBCcmlhbiBDYW1wYmVsbCB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+JiM0MzsxPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+T24gVGh1LCBNYXIgMTAsIDIw
MTYgYXQgNjowNCBBTSwgUm9sYW5kIEhlZGJlcmcgPGEgaHJlZj0ibWFpbHRvOnJvbGFuZC5oZWRi
ZXJnQHVtdS5zZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiZs
dDtyb2xhbmQuaGVkYmVyZ0B1bXUuc2UmZ3Q7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT53cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cHJlPkkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IGJlaW5nIG1vdmVkIGZvcndhcmQgd2l0
aCB0aGVzZSB0d28gY2hhbmdlczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4tIGNoYW5nZSBuYW1lIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0
aW9uIFNlcnZlciBEaXNjb3ZlcnkgTWV0YWRhdGHigJ0gYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5wcm9wb3NlZCBieSBCcmlhbiBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIHVzZSB0aGUg
VVJJIHBhdGggc3VmZml4IOKAmW9hdXRoLWF1dGhvcml6YXRpb24tc2VydmVy4oCZIGluc3RlYWQg
b2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT7igJlvcGVuaWQtY29uZmlndXJhdGlvbuKAmSBhcyBw
cm9wb3NlZCBieSBKdXN0aW4uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286
cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHByZT4xOCBmZWIgMjAxNiBrbC4gMTQ6NDAgc2tyZXYgSGFubmVzIFRzY2hv
ZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJn
ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGFubmVzLnRzY2hvZmVuaWdA
Z214Lm5ldDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+OjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhpIGFsbCw8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGlzIGEgTGFz
dCBDYWxsIGZvciBjb21tZW50cyBvbiB0aGUmbmJzcDsgT0F1dGggMi4wIERpc2NvdmVyeTxvOnA+
PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPnNwZWNpZmljYXRpb246PG86cD48L286
cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUy
ZmRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFk
JTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJm
OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT13MyUyYmlpYVdvbjgx
TEpDVSUyYjJtQ1BSbUElMmJyRUNCSGdxeVJyME9ncWlXU0hVJTNkIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TaW5jZSB0aGlzIGRvY3VtZW50IHdh
cyBvbmx5IGFkb3B0ZWQgcmVjZW50bHkgd2UgYXJlIHJ1bm5pbmcgdGhpcyBsYXN0PG86cD48L286
cD48L3ByZT4NCjxwcmU+Y2FsbCBmb3IgKiozIHdlZWtzKiouPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIGhhdmUgeW91ciBjb21tZW50
cyBpbiBubyBsYXRlciB0aGFuIE1hcmNoIDEwdGguPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2lhbzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhh
bm5lcyAmYW1wOyBEZXJlazxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48
L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFp
bG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJi
ekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJl
PuKAlCBSb2xhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT7igJ1FdmVyeWJvZHkgc2hvdWxkIGJlIHF1aWV0IG5lYXIgYSBsaXR0bGUgc3RyZWFt
IGFuZCBsaXN0ZW4uJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0O0Zyb20g4oCZT3Bl
biBIb3VzZSBmb3IgQnV0dGVyZmxpZXPigJkgYnkgUnV0aCBLcmF1c3M8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl
Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxt
YW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9z
b2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYx
NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpK
aVh3UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48
L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9dE5DaWttWERCRjd1Ymsl
MmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg
bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9h
dXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZi
ZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi
NDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUy
YnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8
YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwJTNhJTJmJTJmbmF0LnNha2ltdXJhLm9yZyUyZiZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9u
eW5hZCU0MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3
YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9NkZWbWRON2Fk
MFl6b1lLU05GJTJmRE8lMmZmRzJFRjFoYWo1YU9IaU1pZDZVTUklM2QiIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L3Nw
YW4+PC9hPjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25h
MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3
dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDEl
N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMx
ZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1iS3NF
VkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJiRkpDUXJucTlhc3hSbzVIZTglM2QiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B
dXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFp
bG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWJLc0VWQlVYYzUyOHlhQU1MbXlj
WGNMMzMlMmJGSkNRcm5xOWFzeFJvNUhlOCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_SN1PR0301MB1645953392F57012B1826237F5B60SN1PR0301MB1645_--


From nobody Sat Mar 12 08:32:44 2016
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 A23EB12D732 for ; Sat, 12 Mar 2016 08:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.108
X-Spam-Level: 
X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 8bsJU2A4uhA2 for ; Sat, 12 Mar 2016 08:32:40 -0800 (PST)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB4412D7C9 for ; Sat, 12 Mar 2016 08:32:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id 64107B4137 for ; Sat, 12 Mar 2016 16:32:17 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1457800337; x=1458664338; bh=aDNo7XArJC 2ZJ+yaICwdwVGNlqL/N1i6NfiD7OJGsJI=; b=NtInKLxV2sNO3I+RI3NpycU+rU yVoo8z8obHxrcPqb4e4KQE6ABtRq3EoC9vNaAVq/ZH9rFMtB2arkMubBaAJPge6F obngafwKeqKVm98KNoXK2xOrxxeEu66/T+WOxB4bRXAjDIqVb3r+pWvAUO0MuIS9 EzoFoOvZ4V9G6YkLs=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtE-M-rU4cyZ for ; Sat, 12 Mar 2016 16:32:17 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 2C21BB40E6 for ; Sat, 12 Mar 2016 16:32:17 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Sat, 12 Mar 2016 10:32:17 -0600
From: Mike Schwartz 
To: oauth@ietf.org
Organization: Gluu
In-Reply-To: 
References: 
Message-ID: 
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 16:32:42 -0000

Kawasaki-san,

This is a really good question: how to know the issuer of a bearer 
token. Is there a header that could be added to specify the issuer, or 
other important metadata?

- Mike


-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org


From nobody Sat Mar 12 09:01:40 2016
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 2608712D7BA for ; Sat, 12 Mar 2016 09:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.109
X-Spam-Level: *
X-Spam-Status: No, score=1.109 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 ONv-P-dSyLmy for ; Sat, 12 Mar 2016 09:01:33 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951C712D5BF for ; Sat, 12 Mar 2016 09:01:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=egNfrunLs8GLwARuSsAf8ARhEVWURkCzKTjitcq7X4Y=; b=hq0pWsDfvMOKxMJzHP+Hc2fjJK9cJNote7qfFvNCO/R1vVlbWrwmXkaXeGFcsZZqB2tCf7fMMk4A8CT9IjVoWQ3+aKH5rhi0vFjVFZHY/cRw7tOxtA9ARsvEY7QayH2b8N2qoc3wR1Xq5QzF1sSyF4tptbz7M6hyxH3LyBbsHj0=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BLUPR0301MB1635.namprd03.prod.outlook.com (10.162.214.141) with Microsoft SMTP Server (TLS) id 15.1.434.16; Sat, 12 Mar 2016 17:01:29 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0427.020; Sat, 12 Mar 2016 17:01:29 +0000
From: Anthony Nadalin 
To: Mike Jones , Brian Campbell , John Bradley 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Thread-Index: AQHRalH06DIAQfC9O0686lpsTuUfK59Sxh0AgAAqNQCAAAiJgIAAEaoAgACbQYCAAAsN0IAAxaEAgAAF5wCAAA9jAIAAdkGAgAACUgCAARk2gIAAAk+AgAAECACAAAeQMA==
Date: Sat, 12 Mar 2016 17:01:29 +0000
Message-ID: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.46.126.7]
x-ms-office365-filtering-correlation-id: 5c3cfdd6-a294-433d-3ac3-08d34a97f4c8
x-microsoft-exchange-diagnostics: 1; BLUPR0301MB1635; 5:slM98bQhIOUuswdvvLz2HDh+9Mmw15AQMfsSx6eTZPqJ3Pbra1d7xXnPtLqX0GD8FLhY7XV580fRLPrXHyo+t2msXLkTlwRDfKsXv2vUFwGRlWHk4CPe2cn3ksIsrK5urQ+mHDhBx9mTLbc+kfSJpw==; 24:upcZPEcLqM53gxJWu3nkwlPS5IneiT/CvrclRr8nOxv1oH1pWvF0hDpQdbx0Zed/y/QKqGexKZZm3tjiNyDaQkZ4cT0Die6h9DHczBvsZFM=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0301MB1635;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR0301MB1635; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0301MB1635; 
x-forefront-prvs: 0879599414
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(53754006)(377454003)(479174004)(377424004)(15975445007)(16236675004)(33656002)(2421001)(93886004)(10290500002)(10400500002)(5005710100001)(2950100001)(2900100001)(10090500001)(19617315012)(122556002)(1511001)(87936001)(66066001)(5004730100002)(77096005)(5003600100002)(5002640100001)(8990500004)(189998001)(11100500001)(5001770100001)(50986999)(81166005)(19609705001)(3900700001)(19580395003)(19580405001)(2906002)(5008740100001)(2561002)(54356999)(76176999)(4326007)(92566002)(586003)(106116001)(3660700001)(6116002)(3280700002)(102836003)(3846002)(99286002)(19625215002)(561944003)(76576001)(74316001)(86362001)(19300405004)(1220700001)(1096002)(790700001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB1635; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234636F63100E32FD4E6FE7A6B60BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2016 17:01:29.4151 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB1635
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 17:01:36 -0000

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

VGhpcyBpcyBub3QgZGlzY292ZXJ5LCBpdHMgc2ltcGx5IG1ldGFkYXRhLCBpdOKAmXMgdW5jbGVh
ciBpZiB0aGlzIGlzIGFsbCB0aGUgbWV0YWRhdGEgdGhhdCBpcyBuZWVkZWQgIGJlY2F1c2UgZGlz
Y292ZXJ5IGhhcyBub3QgYmVlbiBmdWxseSB0aG91Z2h0IG91dCBhcyBhcHBhcmVudCBmcm9tIGFs
bCB0aGUgZXhjaGFuZ2VzIHRoYXQgaGF2ZSBiZWVuIGdvaW5nIG9uLCBJIGRvbuKAmXQgdW5kZXJz
dGFuZCB0aGUgcnVzaCB0byBnZXQgdGhpcyBkb2N1bWVudCBvdXQgd2hlbiB3ZSBhbHJlYWR5IGtu
b3cgaXTigJlzIGluY29tcGxldGUNCg0KVGhlcmUgYXJlIHN0aWxsIGRvY3VtZW50cyBmcm9tIE5h
dCwgYW5kIEkgYmVsaWV2ZSB0aGVyZSB3aWxsIGJlIG9uZSBmcm9tIFBoaWwgYW5kIG1heWJlIG90
aGVycy4NCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogU2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2
IDg6MjkgQU0NClRvOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT47IEJy
aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IEpvaG4gQnJhZGxleSA8
dmU3anRiQHZlN2p0Yi5jb20+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDog
UkU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIERpc2Nv
dmVyeQ0KDQpUaGUgQVMgbWV0YWRhdGEgZm9ybWF0IGlzIGEgbmVjZXNzYXJ5IHBhcnQgb2YgZGlz
Y292ZXJ5LiAgTm8sIGl0IGRvZXNu4oCZdCBhY2NvbXBsaXNoIGV2ZXJ5IHBvc3NpYmxlIGFzcGVj
dCBvZiBkaXNjb3Zlcnkg4oCTIG5vciB3YXMgaXQgZXZlciBpbnRlbmRlZCB0by4gIEnigJl2ZSBj
b25zaXN0ZW50bHkgZW5jb3VyYWdlZCBQaGlsIGFuZCBvdGhlcnMgdG8gd3JpdGUgZG93biBhZGRp
dGlvbmFsIGFzcGVjdHMgb2YgZGlzY292ZXJ5IGluIHNwZWNpZmljYXRpb25zIHRoYXQgYnVpbGQg
dXBvbiB0aGlzIG9uZSBzbyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGFuZCBpbXBsZW1lbnRlcnMg
Y2FuIGV2YWx1YXRlIHRoZW0uDQoNClNpbmNlIHdl4oCZcmUgY2hhcnRlcmVkIHRvIGRvIGRpc2Nv
dmVyeSBhbmQgdGhpcyBpcyBwYXJ0IG9mIGRpc2NvdmVyeSwgbm8gcmVjaGFydGVyaW5nIGlzIG5l
ZWRlZCBlaXRoZXIgZm9yIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gb3IgZm9yIG5ldyBzcGVj
aWZpY2F0aW9ucyBwZXJmb3JtaW5nIGFkZGl0aW9uYWwgZGlzY292ZXJ5IHRhc2tzLg0KDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0g
TWlrZQ0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4NClNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAxMiwg
MjAxNiA4OjIwIEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjsgQnJpYW4gQ2FtcGJlbGwgPGJj
YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv
bT4+OyBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRi
LmNvbT4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+
DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0
aCAyLjAgRGlzY292ZXJ5DQoNCldlIGFncmVlZCB1cG9uIGEgZGlzY292ZXJ5IHNwZWNpZmljYXRp
b24gdGhhdCB0aGUgV0cgd291bGQgd29yayBvbiwgd2UgZGlkIG5vdCBhZ3JlZSB1cG9uIHdoYXQg
dGhpcyBoYXMgdHVybmVkIG91dCB0byBhY3R1YWxseSBiZSwgc28gYXQgdGhlIG1pbmltdW0gdGhl
IGNoYWlycyBzaG91bGQgY2FsbCBmb3IgYWRvcHRpb24gb2YgYSBBdXRob3JpemF0aW9uIFNlcnZl
ciBNZXRhZGF0YSBzcGVjaWZpY2F0aW9uIGFuZCB3ZSBjYW4gY29udGludWUgdG8gd29yayBvbiBh
IERpc2NvdmVyeSBzcGVjaWZpY2F0aW9uDQoNCkZyb206IE1pa2UgSm9uZXMNClNlbnQ6IFNhdHVy
ZGF5LCBNYXJjaCAxMiwgMjAxNiA4OjA2IEFNDQpUbzogQW50aG9ueSBOYWRhbGluIDx0b255bmFk
QG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+OyBCcmlhbiBDYW1w
YmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl
bnRpdHkuY29tPj47IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0
YkB2ZTdqdGIuY29tPj4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll
dGYub3JnPj4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxs
IG9uIE9BdXRoIDIuMCBEaXNjb3ZlcnkNCg0KVGhlIGRyYWZ0IGVuYWJsZXMgZWFzeSBjb25maWd1
cmF0aW9uIG9mIE9BdXRoIGNsaWVudHMgd2l0aCBhbiBBUy4gIEZvciBpbnN0YW5jZSwgdGhlIE1p
Y3Jvc29mdCDigJxBREFM4oCdIE9BdXRoIGNsaWVudCBzb2Z0d2FyZSB1c2VzIEFTIG1ldGFkYXRh
IGluIHRoaXMgZm9ybWF0IGFzIGFuIGlucHV0IGF0IGNsaWVudCBjb25maWd1cmF0aW9uIHRpbWUu
DQoNCkFzIGEgc2lkZSBiZW5lZml0LCBoYXZpbmcgdGhpcyBzdGFuZGFyZCBBUyBtZXRhZGF0YSBm
b3JtYXQgYW5kIHJldHVybmluZyB0aGUgaXNzdWVyIFVSTCBwZXIgdGhlIE1peC1VcCBNaXRpZ2F0
aW9uIGRyYWZ0IHdpbGwgYWxzbyBlbmFibGUgY2xpZW50cyB0byB2YWxpZGF0ZSB0aGF0IHRoZXkg
YXJlIHVzaW5nIGEgY29uc2lzdGVudCBzZXQgb2YgQVMgZW5kcG9pbnRzIGFuZCBpbmZvcm1hdGlv
bi4gIEJ1dCBldmVuIHdpdGhvdXQgdGhlIG1pdGlnYXRpb24gYmVuZWZpdHMsIHRoZSBjbGllbnQg
Y29uZmlndXJhdGlvbiBiZW5lZml0IGlzIHRoZSBwcmltYXJ5IHJlYXNvbiBmb3IgdGhlIHNwZWNp
ZmljYXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFudGhvbnkgTmFkYWxpbg0KU2VudDogRnJpZGF5LCBN
YXJjaCAxMSwgMjAxNiAzOjI1IFBNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5n
aWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+OyBKb2huIEJy
YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpDYzog
b2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292
ZXJ5DQoNCkRpc2FncmVlLCB3aGF0IHB1cnBvc2UgaXMgdGhpcyBhY3Rpdml0eSBzb2x2aW5nIHRo
ZW4sIGl0IHdhcyBiZWluZyBwdXNoZWQgYXMgd2hhdCB3YXMgbmVlZCB0byBzb2x2ZSB0aGUgTWl4
LXVwLCBidXQgdGhhdCBpcyBub3QgdHJ1ZS4gU28gbm93IHlvdSBhcmUgc3VnZ2VzdGluZyBhIGNo
YW5nZSBpbiBzY29wZSBhbmQgbm90IGRlYWxpbmcgd2l0aCBkaXNjb3ZlcnkuDQoNCkZyb206IE9B
dXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENh
bXBiZWxsDQpTZW50OiBGcmlkYXksIE1hcmNoIDExLCAyMDE2IDM6MTEgUE0NClRvOiBKb2huIEJy
YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpDYzog
b2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292
ZXJ5DQoNCkkgdGVuZCB0byBhZ3JlZSB3aXRoIEpvaG4gdGhhdCBhZGRyZXNzaW5nIHRoZSBjb25j
ZXJucyBQaGlsIHJhaXNlcyBzaG91bGQgYmUgcGFydCBvZiAoZXh0ZW5zaW9uIHRvKSB0aGUgY29y
ZSBwcm90b2NvbC4gIEFuZCB0aGF0IHRob3NlIGtpbmRzIG9mIGNvbmNlcm5zIGRvbid0IG1hbmlm
ZXN0IGluIHRoZSB3YXkgT0F1dGggaXMgdHlwaWNhbGx5IGRlcGxveWVkIG5vdy4NCg0KVGhlIGhv
cGVmdWxseSBzb29uIHRvIGJlIG5hbWVkICJPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg
TWV0YWRhdGEiIHNob3VsZCBrZWVwIGl0J3Mgc2NvcGUgdG8gdGhlIHB1Ymxpc2hpbmcgb2YgYXV0
aG9yaXphdGlvbiBzZXJ2ZXIgbWV0YWRhdGEuIFRoZSBhY3Qgb2YgZG9pbmcgZGlzY292ZXJ5IGlz
IGJleW9uZCBpdHMgc2NvcGUgYW5kIHNvIGlzIHRyeWluZyB0byBwcmV2ZW50IGEgY2xpZW50IGZy
b20gcHJlc2VudGluZyBhIHRva2VuIHRvIHNvbWVwbGFjZSBpdCBzaG91bGRuJ3QuDQoNCk9uIEZy
aSwgTWFyIDExLCAyMDE2IGF0IDk6MDggQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5j
b208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpJbmxpbmUNCk9uIE1hciAxMSwg
MjAxNiwgYXQgMTI6MTMgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208
bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkpvaG4NCg0KSW4gbWFueSBj
YXNlIGFsbCB0aGUgQVMgaGFzIHRvIGNoZWNrIGlzIHRoZSBkb21haW4gbmFtZSBjb21wb25lbnQg
dG8gY2hlY2sgZm9yIG1pdG0uDQoNClBPUCBhbmQgdGhlIG90aGVyIHNvbG5zIGFyZSBkcmFtYXRp
Y2FsbHkgbW9yZSBjb21wbGV4IHRoYW4gYSBzaW1wbGUgY2hlY2suDQoNCkkgd2FzIHByb3Bvc2lu
ZyBkaW5nIHRoYXQgY2hlY2sgYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb3IgdG9rZW4g
ZW5kcG9pbnQgYXMgcGFydCBvZiBBVCBpc3N1YW5jZS4NCg0KSXQgaXMgdXAgdG8gdGhlIEFTIGhv
dyBtdWNoIG9mIHRoZSBwYXRoIHRvIHZhbGlkYXRlIGFuZCBvciBwdXQgaW4gdGhlIGF1ZCBvciBk
c3QuDQoNCg0KDQpJIHNlZSBpdCBhcyBwYXJ0IG9mIHRoZSBkaXNjb3ZlcnkoYmFkIG5hbWUgYXNp
ZGUpIHByb2JsZW0gYmVjYXVzZSB3ZSBkaXNjdXNzZWQgdGhhdCBpZiBhIGNsaWVudCBmaW5kcyBh
cHAuZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su
Y29tLz91cmw9aHR0cCUzYSUyZiUyZmFwcC5leGFtcGxlLmNvbSUyZiZkYXRhPTAxJTdjMDElN2N0
b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhkMzRhMDMxZTU3
JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWZpUzhmNjB5cGlY
aHlNMHFWVGVxbCUyYiUyYk96SDJ3Ym1FQ1FFN0o1VHRHUFFNJTNkPiBob3cgZG8gd2UgZW5zdXJl
IGl0IGdldHMgYSBjb21wbGV0ZSBzZXQgb2Ygb2F1dGggZW5kcG9pbnRzIGFzIGEgdmFsaWQgc2V0
IG9mIGVuZHBvaW50cy0tdGhhdCBhIGhhY2tlciBoYXMgbm90IGluc2VydGVkIG9uZSBvZiB0aGVp
ciBvd24gZW5kcG9pbnRzLiBUaGUgbW9zdCBpbXBvcnRhbnQgZW5kcG9pbnQgdG8gZ2V0IHJpZ2h0
IGlzIGVuc3VyaW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIgKGFuZCBvcHRpb25hbGx5IHRoZSBwYXRo
KSBpcyB0aGUgY29ycmVjdCBvbmUuIFdlIGNhbid0IHJlYWxseSBkZWZpbmUgcmVzb3VyY2UgZGlz
Y292ZXJ5IGJ1dCB3ZSBjYW4gdmFsaWRhdGUgaXQgdG8gc29tZSBkZWdyZWUuDQoNCkkgdGhpbmsg
aXQgaXMgcGFydCBvZiBjb3JlIHByb3RvY29sIHNlY3VyaXR5IGFuZCBzaG91bGQvbXVzdCBub3Qg
cmVxdWlyZSBkaXNjb3ZlcnkuDQoNCldoYXQgaXMgYXBwLmV4YW1wbGUuY29tPGh0dHBzOi8vbmEw
MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZhcHAu
ZXhhbXBsZS5jb20mZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0Yjli
YWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw
MTFkYjQ3JTdjMSZzZGF0YT1qQXNaUWVDaEolMmJSMWxieUJvVkt3aGVJWWkzUGlXTHJxJTJieERM
YnFVNnJ4ayUzZD4gPw0KDQpJZiBpdCBpcyB0aGUgcmVzb3VyY2UgdGhlbiB0aGUgY2xpZW50IHdv
dWxkIGJlIHByZWNvbmZpZ3VyZWQgZm9yIGl04oCZcyBBUyBvdXQgb2YgYmFuZCBvciBvcHRpb25h
bGx5IHdvdWxkIGRvIGRpc2NvdmVyeSBvbiB0aGUgaXNzdWVyIHVyaSB0aGF0IHlvdSBhZG1pdCBu
ZWVkcyB0byBiZSBjb25maWd1cmVkIG91dCBvZiBiYW5kIHNvbWUgd2F5IChub3RlIGRpc2NvdmVy
eSBpcyBvcHRpb25hbCkNCg0KSW4gdGhlIEFTIG1ldGEtZGF0YSBkcmFmdCBpdCB3b3VsZCBkbyBh
IGdldCBvbiBhIHdlbGwga25vd24gZmlsZSB0aGF0IHdvdWxkIGhhdmUgY29uZmlndXJhdGlvbiBm
b3IgdGhlIEFTLCBidXQgbm90IHRoZSBSUywgdGhvdWdoIHNvbWUgQVBJIG1heSBvcHRpb25hbGx5
IGxpc3QgYSBBUEkgZW5kcG9pbnQgbGlrZSBjb25uZWN0IGhhcy4NCg0KVGhlIGNsaWVudCB0aGVu
IG1ha2VzIGEgYXV0aG9yaXphdGlvbiByZXF1ZXN0IChhZnRlciByZWdpc3RlcmluZyBvdXQgb2Yg
YmFuZCBvciBkeW5hbWljYWxseSkuDQpBcyBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHJlcXVl
c3QgZm9yIGltcGxpY2l0IGl0IGNvdWxkIHByb3ZpZGUgdGhlIGF1ZC9kc3QgdGhhdCBpdCB3YW50
cyB0aGUgdG9rZW4gZm9yLg0KSWYgdGhhdCBpcyBub3Qgc2VudCB0aGVuIHRoZSBhdWQvZHN0IGFy
ZSBpbXBsaWNpdCBpbiB0aGUgc2NvcGVzLg0KDQpUaGUgY2xpZW50IGdldHMgYmFjayBhIEFUIHdp
dGggYSBsaXN0IG9mIHNjb3BlcyBncmFudGVkLCBhdWQvZHN0IGFsbG93ZWQgYW5kIHRpbWUgdG8g
bGl2ZSBmb3IgdGhlIHRva2VuIChvbmUgZXh0cmEgdGhpbmcgcmV0dXJuZWQpDQoNClRoaXMgZG9l
c27igJl0IHJlcXVpcmUgYW55IGRpc2NvdmVyeSAoeWVzIHRoZXJlIGlzIGEgb3B0aW9uYWwgQVMg
bWV0YS1kYXRhIGRpc2NvdmVyeSBidXQgbm90IHJlcXVpcmVkKQ0KDQpJIHByZWZlciB0byBmaXgg
dGhlIFJTIG1hbiBpbiB0aGUgbWlkZGxlIGlzc3VlIGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIGFu
ZCBub3QgcGFydCBvZiBkaXNjb3ZlcnkgdGhhdCBzaG91bGQgcmVtYWluIG9wdGlvbmFsLg0KDQpJ
IGhvbmVzdGx5IGRvbuKAmXQgcXVpdGUga25vdyBob3cgdGhlIGNsaWVudCBsZWFybnMgYWJvdXQg
dGhpcyBiYWQgUlMgYW5kIHN0YXJ0cyB0YWxraW5nIHRvIGl0LCBzbyB0aGlzIG1heSBiZSBhIHNv
bHV0aW9uIHRvIGEgcHJvYmxlbSB0aGF0IGRvZXNu4oCZdCB5ZXQgZXhpc3QuICAgVGhlIG9uZSBw
bGFjZSB0aGlzIGlzIHBvc2FibGUgaXMgaWYgdGhlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIGNsaWVu
dCBpcyBjb21wcm9taXNlZC4gIEhvd2V2ZXIgd2UgYXJlIGRpc2N1c3Npbmcgb3RoZXIgbWl0aWdh
dGlvbnMgZm9yIHRoYXQgdGhhdCBhbHNvIGV4cGxpY2l0bHkgZG8gbm90IHJlcXVpcmUgZGlzY292
ZXJ5Lg0KDQpKb2huIEIuDQoNCg0KSSBhbSBub3Qgc3R1Y2sgb24gd2ViZmluZ2VyIG9yIHdlbGwt
a25vd24uIEJlY2F1c2UgdGhpcyBpcyBjb25maWcgbWF5YmUgaXQgc2hvdWxkIGJlIGFuIG9hdXRo
IGVuZHBvaW50Lg0KDQpQaGlsDQoNCk9uIE1hciAxMSwgMjAxNiwgYXQgMDY6NTEsIEpvaG4gQnJh
ZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6
DQpJIHRoaW5rIFBoaWwgaXMgcHJvcG9zaW5nIHNvbWV0aGluZyBkaWZmZXJlbnQuICAgU2hvdWxk
IHRoZSBjbGllbnQgc2VuZCBhIHRva2VuIGZyb20gdGhpcyBBUyB0byB0aGF0IFJTLg0KDQpIaXMg
Z29hbCBpcyB0byBwcmV2ZW50IG1hbiBpbiB0aGUgbWlkZGxlIGF0dGFja3Mgd2hlcmUgYSBiYWQg
UlMgZ2V0cyBhIEFUIHRoYXQgaXMgYXVkaWFuY2VkIHRvL2FjY2VwdGVkIGJ5IGFub3RoZXIgUlMu
DQoNClRoYXQgaXMgc2VwYXJhdGUgZnJvbSB0aGUgcXVlc3Rpb24gb2YgaWYgYSBSUyBhY2NlcHRz
IHRva2VucyBmcm9tIGEgZ29vZCBBUy4gICBBIGJhZCBBUyB3b3VsZCBhbHdheXMgc2F5IHllcy4N
Cg0KV2UgbmVlZCB0byBiZSBjYXJlZnVsIG9mIHdoYXQgaWYgYW55dGhpbmcgdGhlIFJTIHByb3Zp
ZGVzIHRvIHRoZSBjbGllbnQgYXMgbWV0YS1kYXRhIHdpdGhvdXQgdmFsaWRhdGlvbi4NCg0KQ3Vy
cmVudGx5IHRoZSBjbGllbnQgY2FuIHByb3ZpZGUgYSBsaXN0IG9mIHNjb3BlcyByZXF1aXJlZCB0
byBnZXQgYWNjZXNzLiAgIEkgcGVyc29uYWxseSBmZWVsIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBh
bHNvIGluY2x1ZGUgaW4gdGhlIHVuYXV0aGVudGljYXRlZCBlcnJvciByZXNwb25zZSBhbiBpbmRp
Y2F0aW9uIG9mIHdoYXQgQVBJIHRoZSByZXNvdXJjZSBzdXBwb3J0cy4gIFNheSDigJxzY2ltMuKA
nSBhcyBhbiBleGFtcGxlLiAgIEkgZG9u4oCZdCB0aGluayBhZGRpbmcgdGhhdCBpcyBob3dldmVy
IGEgaGlnaCBwcmlvcml0eSBhcyBtb3N0IGlmIGFsbCBjbGllbnRzIGtub3cgd2hhdCBBUEkgdGhl
eSBleHBlY3QuICAgSXQgbWlnaHQgYmUgdXNlZnVsIGlmIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1
dHVyZSBpZiBhIGNsaWVudCB3ZXJlIHRvIGJlIGdpdmVuIGEgUlMgVVJJIGl0IGNvdWxkIGNoZWNr
IHRvIHNlZSBpZiBpdCBpcyBhIHByb3RvY29sIHRoYXQgaXQgc3VwcG9ydHMgYmVmb3JlIGJvdGhl
cmluZyB3aXRoIE9BdXRoLiAgICBJIGV4cGVjdCB0aGF0IGEgbG90IG9mIHBlb3BsZSB3aWxsIHdh
bnQgdGhhdCBsZWZ0IHRvIHRoZSBBUEkgZGVmaW5pdGlvbi4gICBJIHRoaW5rIHdlIGNhbiB0YWxr
IGFib3V0IGl0IGJ1dCByYXRlIHRoaXMgbG93IHByaW9yaXR5Lg0KDQpJIGFncmVlIHRoYXQgdGhl
IFJTIGdpdmluZyBvdXQgYSBsaXN0IG9mIEFTIHRoYXQgaXQgdHJ1c3RzIGlzIGEgZ2VuZXJhbGx5
IGJhZCBpZGVhLiAgSSBob3BlIHRoYXQgaXMgbm90IG9uIHRoZSB0YWJsZS4NCg0KSSBkb27igJl0
IHRoaW5rIHRoYXQgcHJldmVudGluZyBhIGNsaWVudCBmcm9tIHNlbmRpbmcgYSB0b2tlbiB0byB0
aGUgd3JvbmcgUlMgaXMgcGFydCBvZiBhIEFTIG1ldGEtZGF0YSBkaXNjb3ZlcnkgcHJvYmxlbS4N
Cg0KSSBkbyBob3dldmVyIHRoaW5rIHRoYXQgaXQgaXMgaW1wb3J0YW50Lg0KDQpXZSBoYXZlIGJl
ZW4gZGlzY3Vzc2luZyB0aGlzIGFzIGEgc2VwYXJhdGUgcHJvYmxlbSB0byBBUyBtZXRhLWRhdGEg
ZGlzY292ZXJ5IHdoZXJlIHRoZSBlbmRwb2ludHMgb2YgdGhlIEFTIGFuZCBpdOKAmXMgY29uZmln
dXJhdGlvbiBhcmUgZGlzY292ZXJ5LiAgIFNvcnJ5IGZvciBwZXJoYXBzIHN0YXRpbmcgdGhlIG9i
dmlvdXMsIGJ1dCB0aGUgUlMgaXMgZXhwbGljaXRseSBub3QgcGFydCBvZiB0aGUgQVMgaW4gT0F1
dGggMi4gICBTdGFydGluZyBpbiBXQVAgdGhhdCB3YXMgYSBjb3JlIHByaW5jaXBhbC4NCg0KU28g
d2UgaGF2ZSBhIG51bWJlciBvZiBvcHRpb25zIHRvIGFkZHJlc3MgdGhlIFJTIHRva2VuIGxlYWth
Z2UgdmlhIE1pVE0gYXR0YWNrcy4NCg0KMSkgUG9QIGJvdW5kIHRva2Vucy4gIElmIHRoZXkgYXJl
IGJvdW5kIHRvIHRoZSBUTFMgY2hhbm5lbCBieSBtdXR1YWwgVExTIG9yIFRva2VuIGJpbmRpbmcg
dGhleSBjYW5ub3QgYmUgcmVwbGF5ZWQuICBTaWduZWQgbWVzc2FnZXMgd2hlcmUgdGhlIHNpZ25p
bmcgY292ZXJzIHRoZSBSUyBIb3N0IGFuZCBwYXRoIGNvbXBvbmVudHMsICBhbHNvIHdvdWxkIHdv
cmsuDQoNCjIpIEhhdmUgdGhlIEFTIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSByZXNvdXJjZXMgdGhl
IEFUIGlzIGdvb2QgYXQuIChBVCBzaG91bGQgYmUgZG9pbmcgdGhhdCBub3cpDQpJbiB0aGUgdG9r
ZW4gcmVzcG9uc2UgaW5jbHVkZSB0aGUgbGlzdCBvZiBhdWRpZW5jZS9zIHRoZSB0b2tlbiBpcyBw
cmVzZW50YWJsZSBhdC4gIFRoZSBjbGllbnQgd291bGQgdGhyb3cgYW4gZXJyb3IgaWYgdGhlIFJT
IGl0IGludGVuZHMgdG8gc2VuZCB0aGUgdG9rZW4gdG8gaXMgbm90IG9uIHRoZSBsaXN0LiAgIFRo
ZSBSUyB0aGUgdG9rZW4gaXMgZ29vZCBhdCBtaWdodCBjaGFuZ2UgYmFzZWQgb24gc2NvcGVzLCBj
bGllbnRfaWQgYW5kIHJlc291cmNlIG93bmVyLiAgIFRoaXMgaXMgdGhlIHBsYWNlIHdoZXJlIGFs
bCBvZiB0aGF0IGNvbWVzIHRvZ2V0aGVyLiAgIEluIHNvbWUgY2FzZXMgdGhlIFJTIGFuZCBBUyBt
aWdodCBub3QgaGF2ZSBhIHByZS1lc3RhYmxpc2hlZCByZWxhdGlvbnNoaXAuICAgVGhlIGNsaWVu
dCBzaG91bGQgc2VuZCB0aGUgUlMgYmFzZSBVUkkgdG8gdGhlIEFTIGFzIHBhcnQgb2YgdGhlIHJl
cXVlc3QuICBUaGUgQVMgY2FuIHVzZSB0aGF0IHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSBBVCBh
bmQgaXNzdWUgdGhlIEFUIG9yIHJlZnVzZSB0byBpc3N1ZSB0aGUgQVQgYmFzZWQgb24gcG9saWN5
Lg0KSXQgY2FuIGFsc28gdXNlIHRoZSBhdWRpZW5jZSBpbiB0aGUgcmVxdWVzdCB0byBkb3duIGF1
ZGllbmNlIHRoZSBBVCBpZiB0aGUgZGVmYXVsdCBpcyB0byBoYXZlIG11bHRpcGxlIGF1ZGllbmNl
cy4gICAgV2UgbWF5IHdhbnQgdG8gdXNlIGEgdGVybSBvdGhlciB0aGFuIGF1ZGllbmNlIGZvciB0
aGlzIGxpa2UgcmVzb3VyY2Ugb3IgZGVzdGluYXRpb24uICBJdCBpcyBhIGF1ZGllbmNlIGJ1dCB0
aGF0IHRlcm0gbWlnaHQgY29uZnVzZSBwZW9wbGUgd2l0aCBBVC4NCg0KV2UgZGlkIHRhbGsgYWJv
dXQgYnJlYWtpbmcgYXVkaWVuY2Ugb3V0IG9mIFBPUCBrZXkgZGlzdHJpYnV0aW9uLCBhbmQgQnJp
YW4gQ2FtcGJlbGwgZGlkIGEgZHJhZnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWNhbXBiZWxsLW9hdXRoLWRzdDRqd3Q8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZk
cmFmdC1jYW1wYmVsbC1vYXV0aC1kc3Q0and0JmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9U1RyJTJiNGtyZDFoeThoNmVIT0NMaDFQ
elFhS01VaFdsS1YyaSUyZkNMMEsxU1ElM2Q+Lg0KDQpUbyBkbyB0aGlzIHdlIGNvdWxkIHRha2Ug
ZHN0NGp3dCBhbmQgYWRkIGFub3RoZXIgc3BlYyB0aGF0IGFkZHMgYSBuZXcgZHN0IHBhcmFtZXRl
ciB0byB0aGUgdG9rZW4gYW5kIGF1dGhvcml6YXRpb24gZW5kcG9pbnRzIHJlcXVlc3RzIFRoYXQg
d291bGQgYmUgYSBzcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBkc3QgdmFsdWVzLiAgYW5kIGluIHRo
ZSByZXNwb25zZSBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCB3b3VsZCBiZSBhIEpTT04gYXJyYXkg
b2YgZHN0IHZhbHVlcy4NCg0KMykgSGF2ZSB0aGUgQVMgYWx3YXlzIHJldHVybiBhbGwgdGhlIGxp
c3Qgb2YgYWxsIFJTIHRoZSB0b2tlbiBjYW4gYmUgdXNlZCBhdCAoYmFzaWNhbGx5IE5hdCdzIGxp
bmsgcmVsYXRpb25zaGlwIHByb3Bvc2FsKS4gIEl0IG5lZWRzIGEgd2F5IHRvIGhhbmRsZQ0KZG93
biBkZXN0aW5hdGlvbmluZyBvZiBBVCBhbmQgdG8gYWxsb3cgZm9yIHVuLWNvbmZpZ3VyZWQgUlMg
dGhhdCBpdCBtaWdodCBpc3N1ZSBhIHRva2VuIGZvci4gIFNvIGNvdWxkIGJlIGNvbWJpbmVkIHdp
dGggZHN0IGZyb20gMi4gIEJhc2ljYWxseSByZXR1cm5pbmcgdGhlIGFjY2VwdGFibGUgZGVzdGlu
YXRpb25zIGFzIGxpbmsgaGVhZGVycyB2cyBKUyBpbiB0aGUgcmVzcG9uc2UgaXMgbW9zdGx5IGEg
c3R5bGUgaXNzdWUgdGhhdCBvdGhlciBwZW9wbGUgY2FuIGJpa2Ugc2hlZC4NCg0KDQo0KSBUcnlp
bmcgdG8gYWRkIGFsbCB0aGUgUlMgdG8gdGhlIEFTIGRpc2NvdmVyeSBkb2N1bWVudC4gIFRoaXMg
c2VlbXMgaW1wcmFjdGljYWwgYXMgdGhlcmUgd291bGQgYmUgbXVsdGlwbGUgcHJvdG9jb2xzIGFu
ZCBkb2VzbuKAmXQgYWRkcmVzcyB1bi1jb25maWd1cmVkIFJTLg0KDQo1KSBTb21lIG5ldyBBUyBl
bmRwb2ludCB0aGF0IHRoZSBjbGllbnQgY291bGQgaW50cm9zcGVjdCB0aGUgUlMgVVJJIGFuZCBn
ZXQgYmFjayBtZXRhZGF0YSBhYm91dCBpZiB0aGUgY2xpZW50IHNob3VsZCBzZW5kIHRva2VucyB0
aGVyZS4NCiAgICBBIGNvdXBsZSBvZiBwcm9ibGVtcyB3aXRoIHRoaXMuICBUaGUgZmlyc3QgaXMg
dGhhdCBpdCB3b3VsZCBub3Qgc3VwcG9ydCB1bi1jb25maWd1cmVkIFJTIHVubGVzcyB5b3UgYWRk
IGRzdCB0byB0aGUgdG9rZW4gYW5kIGF1dGhvcml6YXRpb24gZW5kcG9pbnRzLiAgIFRoZSBvdGhl
ciBpcyB0aGF0IHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGRvZXNu4oCZdCBoYXZlIHRoZSBj
b250ZXh0IG9mIHRoZSBSTyBhbmQgY2xpZW50X2lkIHVubGVzcyB5b3UgYWxzbyBwYXNzIHRoZSBj
b2RlL1JUIGFuZCBjbGllbnRfaWQsIGFuZCBwcm9iYWJseSBjbGllbnQgY3JlZGVudGlhbHMuICAg
IEJhc2ljYWxseSB0aGlzIGlzIHRyeWluZyB0byBpbnRyb3NwZWN0IHRoZSBBVCB0byBkZXRlcm1p
bmUgdGhlIGF1ZGlhbmNlL2RzdC4gICBCeSB0aGUgdGltZSB5b3UgYnVpbGQgYSBuZXcgaW50cm9z
cGVjdGlvbiBlbmRwb2ludCBzZWN1cmVseSBpdCBpcyBnb2luZyB0byBsb29rIGxpa2UgdGhlIHRv
a2VuIGVuZHBvaW50IHdpdGggYSBiaXQgbW9yZSBtZXRhIGRhdGEgYWJvdXQgdGhlIHRva2VuIGJl
eW9uZCBleHBpcnkgYW5kIHNjb3Blcy4NCg0KDQpJIHRoaW5rIHdlIHNob3VsZCBnbyBhIGhlYWQg
d2l0aCB0aGUgcmVuYW1lZCAiT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVyIERpc2NvdmVy
eSBNZXRhZGF0YeKAnQ0KSSBhbSBhbHNvIGZpbmUgd2l0aCBtYWtpbmcgdGhlIGRlZmF1bHQgZG9j
dW1lbnQgJ29wZW5pZC1jb25maWd1cmF0aW9u4oCZICBhcyBsb25nIGFzIHdlIGFsbG93IGZvciBw
cm90b2NvbCBzcGVjaWZpYyB2YXJpYXRpb24gc28gdGhhdCBTQ0lNMiBjb3VsZCBkZWZpbmUgYSBm
aWxlIG5hbWUuICAgIElmIHBlb3BsZSB3YW50IHdlIGNvdWxkIGRvIGEgQVBJICB0byBmaWxlIG5h
bWUgcmVnaXN0cnkgc28gdGhhdCBwcm90b2NvbCBzcGVjaWZpYyBvbmVzIGNhbiBiZSBkZWZpbmVk
Lg0KDQpXZSBhcmUgYWxsLXJlYWR5IHdvcmtpbmcgb24gb3B0aW9uIDEgdG8gc2VjdXJlIEFULCB3
ZSBuZWVkIGEgc3BlYyBsaWtlIEkgcHJvcG9zZSBpbiAyIGZvciBiZWFyZXIgdG9rZW5zLiAgV2Ug
Y2FuIGFkZCBvbmUgcmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGEgYml0IG1vcmUgdG9rZW4gbWV0YS1k
YXRhIHRvIHRoZSB0b2tlbiByZXNwb25zZSBhbmQgdGhhdCB0YWtlcyBjYXJlIG9mIHRoZSBwcm9i
bGVtLiAgIEhvbmVzdGx5IHdlIHByb2JhYmx5IHNob3VsZCBoYXZlIHNlcGFyYXRlZCBzY29wZSBh
bmQgZGVzdGluYXRpb24gaW4gdGhlIGZpcnN0IHBsYWNlIGFuZCByZXR1cm5lZCBib3RoIGRzdCBh
bmQgc2NvcGUgaW4gdGhlIHJlc3BvbnNlIGFsbCBhbG9uZywgc28gdGhpcyBpcyB1cGRhdGUgdGhh
dCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGVpc3RpbmcgYXJjaGl0ZWN0dXJlIG9mIE9BdXRoIDIu
DQoNCkxldHMga2VlcCB0aGUgdHdvIGlzc3VlcyBzZXBhcmF0ZS4NCg0KSm9obiBCLg0KDQoNCg0K
DQpPbiBNYXIgMTEsIDIwMTYsIGF0IDEyOjA3IEFNLCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRA
bWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNClRo
ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBBUyBhbmQgUlMgbmVlZCB0byBiZSBzY29wZWQgdG8g4oCc
ZG9lcyB0aGlzIFJTIGFjY2VwdCB0b2tlbnMgZnJvbSB0aGlzIEFT4oCdIGFzIGEgbGlzdCBpcyB0
b28gbXVjaCBpbmZvcm1hdGlvbiB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gdGhlIHdyb25nIHdheQ0K
DQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBOYXQgU2FraW11cmENClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxMCwgMjAxNiA2OjI1IFBNDQpU
bzogUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50
QG9yYWNsZS5jb20+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0
Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gV29ya2luZyBHcm91cCBMYXN0IENhbGwg
b24gT0F1dGggMi4wIERpc2NvdmVyeQ0KDQpQaGlsLA0KDQpSaWdodC4gU28gd2hhdCBteSBjb25k
aXRpb25hbCBhcHByb3ZhbHMgKDExIGNvbmRpdGlvbnMgaW4gdG90YWwpIHNhaWQgd2FzIHRvIGRy
b3AgdGhlIHdvcmQgImRpc2NvdmVyeSIgZnJvbSBldmVyeXdoZXJlLiBUaGlzIGlzIG5vdCBhIGRp
c2NvdmVyeSBzcGVjLiBUaGlzIGlzIGEgY29uZmlndXJhdGlvbiBsb29rdXAgc3BlYyBhcyB5b3Ug
Y29ycmVjdGx5IHBvaW50cyBvdXQuIFNvLCBJIGFtIHdpdGggeW91IGhlcmUuDQoNCkFsc28sIG15
IDJuZCBjb25kaXRpaW9uIGlzIGVzc2VudGlhbGx5IHNheWluZyB0byBkcm9wIHNlY3Rpb24gMy4N
Cg0KT25lIHRoaW5nIHRoYXQgSSBvdmVybG9va2VkIGFuZCBhbSB3aXRoIHlvdSBpcyB0aGF0IHdl
IG5lZWQgdG8gYmUgYWJsZSB0byBleHByZXNzIHRoZSBBUy1SUyByZWxhdGlvbnNoaXBzLiBJIGhh
dmUgYmVlbiBwcmVhY2hpbmcgdGhpcyBpbiB0aGUgb3RoZXIgdGhyZWFkIGZvciBzbyBtYW55IHRp
bWVzIGFzIHlvdSBrbm93IHNvIEkgdGhvdWdodCBJIHBvaW50ZWQgaXQgb3V0LCBidXQgbWlzc2Vk
IGFwcGFyZW50bHkgaW4gbXkgcHJldmlvdXMgY29tbWVudC4gU28sIEkgd291bGQgYWRkIG15IDEy
dGggY29uZGl0aW9uOg0KDQoxMi4gQSB3YXkgdG8gZXhwcmVzcyBhIGxpc3Qgb2YgdmFsaWQgUlNz
IGZvciB0aGlzIEFTIG5lZWRzIHRvIGJlIGFkZGVkIHRvIHNlY3Rpb24gMi4NCg0KQmVzdCwNCg0K
TmF0DQoNCjIwMTYtMDMtMTEgMjowOSBHTVQrMDk6MDAgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1
bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjoNCkkgc3Ryb25nbHkg
b3Bwb3NlLiAyIG1ham9yIGlzc3Vlcy4NCg0KVGhpcyBpcyBub3Qgc2VydmljZSBkaXNjb3Zlcnkg
dGhpcyBpcyBjb25maWd1cmF0aW9uIGxvb2t1cC4gVGhlIGNsaWVudCBtdXN0IGhhdmUgYWxyZWFk
eSBkaXNjb3ZlcmVkIHRoZSBvYXV0aCBpc3N1ZXIgdXJpIGFuZCB0aGUgcmVzb3VyY2UgdXJpLg0K
DQpUaGUgb2JqZWN0aXZlIHdhcyB0byBwcm92aWRlIGEgbWV0aG9kIHRvIGVuc3VyZSB0aGUgY2xp
ZW50IGhhcyBhIHZhbGlkIHNldCBvZiBlbmRwb2ludHMgdG8gcHJldmVudCBtaXRtIG9mIGVuZHBv
aW50cyBsaWtlIHRoZSB0b2tlbiBlbmRwb2ludCB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLg0KDQpU
aGUgZHJhZnQgZG9lcyBub3QgYWRkcmVzcyB0aGUgaXNzdWUgb2YgYSBjbGllbnQgYmVpbmcgZ2l2
ZW4gYSBiYWQgZW5kcG9pbnQgZm9yIGFuIHJzLiBXaGF0IHdlIGVuZCB1cCB3aXRoIGlzIGEgcHJv
bWlzY3VvdXMgYXV0aHogc2VydmljZSBnaXZpbmcgb3V0IHRva2VucyB0byBhbiB1bndpdHRpbmcg
Y2xpZW50Lg0KDQpQaGlsDQoNCk9uIE1hciAxMCwgMjAxNiwgYXQgMDg6MDYsIFZsYWRpbWlyIER6
aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb208bWFpbHRvOnZsYWRpbWlyQGNvbm5lY3Qy
aWQuY29tPj4gd3JvdGU6DQorMSB0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGVzZQ0KT24gMTAvMDMv
MTYgMTc6MzUsIEJyaWFuIENhbXBiZWxsIHdyb3RlOg0KDQorMQ0KDQoNCg0KT24gVGh1LCBNYXIg
MTAsIDIwMTYgYXQgNjowNCBBTSwgUm9sYW5kIEhlZGJlcmcgPHJvbGFuZC5oZWRiZXJnQHVtdS5z
ZT48bWFpbHRvOnJvbGFuZC5oZWRiZXJnQHVtdS5zZT4NCg0Kd3JvdGU6DQoNCg0KDQpJIHN1cHBv
cnQgdGhpcyBkb2N1bWVudCBiZWluZyBtb3ZlZCBmb3J3YXJkIHdpdGggdGhlc2UgdHdvIGNoYW5n
ZXM6DQoNCg0KDQotIGNoYW5nZSBuYW1lIHRvIOKAnE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFNl
cnZlciBEaXNjb3ZlcnkgTWV0YWRhdGHigJ0gYXMNCg0KcHJvcG9zZWQgYnkgQnJpYW4gYW5kDQoN
Ci0gdXNlIHRoZSBVUkkgcGF0aCBzdWZmaXgg4oCZb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXLi
gJkgaW5zdGVhZCBvZg0KDQrigJlvcGVuaWQtY29uZmlndXJhdGlvbuKAmSBhcyBwcm9wb3NlZCBi
eSBKdXN0aW4uDQoNCg0KDQoxOCBmZWIgMjAxNiBrbC4gMTQ6NDAgc2tyZXYgSGFubmVzIFRzY2hv
ZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2Zlbmln
QGdteC5uZXQ+DQoNCjoNCg0KDQoNCkhpIGFsbCwNCg0KDQoNClRoaXMgaXMgYSBMYXN0IENhbGwg
Zm9yIGNvbW1lbnRzIG9uIHRoZSAgT0F1dGggMi4wIERpc2NvdmVyeQ0KDQpzcGVjaWZpY2F0aW9u
Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zl
cnktMDE8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9
aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLW9hdXRoLWRp
c2NvdmVyeS0wMSZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVh
ZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx
MWRiNDclN2MxJnNkYXRhPXczJTJiaWlhV29uODFMSkNVJTJiMm1DUFJtQSUyYnJFQ0JIZ3F5UnIw
T2dxaVdTSFUlM2Q+DQoNCg0KDQpTaW5jZSB0aGlzIGRvY3VtZW50IHdhcyBvbmx5IGFkb3B0ZWQg
cmVjZW50bHkgd2UgYXJlIHJ1bm5pbmcgdGhpcyBsYXN0DQoNCmNhbGwgZm9yICoqMyB3ZWVrcyoq
Lg0KDQoNCg0KUGxlYXNlIGhhdmUgeW91ciBjb21tZW50cyBpbiBubyBsYXRlciB0aGFuIE1hcmNo
IDEwdGguDQoNCg0KDQpDaWFvDQoNCkhhbm5lcyAmIERlcmVrDQoNCg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QN
Cg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFp
bG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29m
dC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQx
YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIw
TEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoNCuKAlCBSb2xhbmQNCg0KDQoNCuKAnUV2ZXJ5
Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBhIGxpdHRsZSBzdHJlYW0gYW5kIGxpc3Rlbi4iDQoN
Cj5Gcm9tIOKAmU9wZW4gSG91c2UgZm9yIEJ1dHRlcmZsaWVz4oCZIGJ5IFJ1dGggS3JhdXNzDQoN
Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cg0KT0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRw
czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy
ZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2Mw
MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1
NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5DaWtt
WERCRjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQoNCg0K
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
T0F1dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y
Zz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczov
L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUy
Znd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3
Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVj
NzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dE5DaWttWERC
Rjd1YmslMmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkPg0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs
aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFp
bG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29m
dC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZmMTQx
YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT10TkNpa21YREJGN3ViayUyYiUyYnpKaVh3UEIw
TEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2Q+DQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0
KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz
YSUyZiUyZm5hdC5zYWtpbXVyYS5vcmclMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv
c29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4OGJmODZm
MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT02RlZtZE43YWQwWXpvWUtTTkYlMmZETyUy
ZmZHMkVGMWhhajVhT0hpTWlkNlVNSSUzZD4NCkBfbmF0X2VuDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp
ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp
bmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0Yjli
YWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw
MTFkYjQ3JTdjMSZzZGF0YT1iS3NFVkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJiRkpDUXJucTlhc3hS
bzVIZTglM2Q+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0
dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh
JTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3
YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0
YTAzMWU1NyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1iS3NF
VkJVWGM1Mjh5YUFNTG15Y1hjTDMzJTJiRkpDUXJucTlhc3hSbzVIZTglM2Q+DQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1h
bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v
cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6
MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn
aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm
XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi
Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94
bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg
dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIG5vdCBkaXNjb3ZlcnksIGl0cyBzaW1w
bHkgbWV0YWRhdGEsIGl04oCZcyB1bmNsZWFyIGlmIHQ8YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui
PmhpcyBpcyBhbGwgdGhlIG1ldGFkYXRhIHRoYXQgaXMgbmVlZGVkJm5ic3A7IGJlY2F1c2UgZGlz
Y292ZXJ5IGhhcyBub3QgYmVlbiBmdWxseSB0aG91Z2h0DQogb3V0IGFzIGFwcGFyZW50IGZyb20g
YWxsIHRoZSBleGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gZ29pbmcgb24sIEkgZG9u4oCZdCB1bmRl
cnN0YW5kIHRoZSBydXNoIHRvIGdldCB0aGlzIGRvY3VtZW50IG91dCB3aGVuIHdlIGFscmVhZHkg
a25vdyBpdOKAmXMgaW5jb21wbGV0ZQ0KPG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGVyZSBhcmUgc3Rp
bGwgZG9jdW1lbnRzIGZyb20gTmF0LCBhbmQgSSBiZWxpZXZlIHRoZXJlIHdpbGwgYmUgb25lIGZy
b20gUGhpbCBhbmQgbWF5YmUgb3RoZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1p
a2UgSm9uZXMNCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMTIsIDIwMTYgODoy
OSBBTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluICZsdDt0b255bmFkQG1pY3Jvc29m
dC5jb20mZ3Q7OyBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20m
Z3Q7OyBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0Ozxicj4NCjxiPkNjOjwv
Yj4gb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog
W09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBBUyBtZXRhZGF0YSBmb3JtYXQgaXMgYSBuZWNlc3Nh
cnkgcGFydCBvZiBkaXNjb3ZlcnkuJm5ic3A7IE5vLCBpdCBkb2VzbuKAmXQgYWNjb21wbGlzaCBl
dmVyeSBwb3NzaWJsZSBhc3BlY3Qgb2YgZGlzY292ZXJ5IOKAkyBub3Igd2FzIGl0IGV2ZXIgaW50
ZW5kZWQgdG8uJm5ic3A7IEnigJl2ZSBjb25zaXN0ZW50bHkNCiBlbmNvdXJhZ2VkIFBoaWwgYW5k
IG90aGVycyB0byB3cml0ZSBkb3duIGFkZGl0aW9uYWwgYXNwZWN0cyBvZiBkaXNjb3ZlcnkgaW4g
c3BlY2lmaWNhdGlvbnMgdGhhdCBidWlsZCB1cG9uIHRoaXMgb25lIHNvIHRoYXQgdGhlIHdvcmtp
bmcgZ3JvdXAgYW5kIGltcGxlbWVudGVycyBjYW4gZXZhbHVhdGUgdGhlbS48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlNpbmNlIHdl4oCZcmUgY2hhcnRlcmVkIHRv
IGRvIGRpc2NvdmVyeSBhbmQgdGhpcyBpcyBwYXJ0IG9mIGRpc2NvdmVyeSwgbm8gcmVjaGFydGVy
aW5nIGlzIG5lZWRlZCBlaXRoZXIgZm9yIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gb3IgZm9y
IG5ldyBzcGVjaWZpY2F0aW9ucw0KIHBlcmZvcm1pbmcgYWRkaXRpb25hbCBkaXNjb3ZlcnkgdGFz
a3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW50aG9ueSBOYWRhbGlu
DQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1hcmNoIDEyLCAyMDE2IDg6MjAgQU08YnI+
DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBCcmlh
biBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t
Ij5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7OyBKb2huIEJyYWRsZXkgJmx0Ozxh
IGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0
Ozxicj4NCjxiPkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y
ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRI
LVdHXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5XZSBhZ3JlZWQgdXBvbiBhIGRpc2NvdmVyeSBzcGVjaWZpY2F0aW9uIHRoYXQgdGhlIFdHIHdv
dWxkIHdvcmsgb24sIHdlIGRpZCBub3QgYWdyZWUgdXBvbiB3aGF0IHRoaXMgaGFzIHR1cm5lZCBv
dXQgdG8gYWN0dWFsbHkgYmUsIHNvIGF0IHRoZSBtaW5pbXVtIHRoZSBjaGFpcnMgc2hvdWxkIGNh
bGwNCiBmb3IgYWRvcHRpb24gb2YgYSBBdXRob3JpemF0aW9uIFNlcnZlciBNZXRhZGF0YSBzcGVj
aWZpY2F0aW9uIGFuZCB3ZSBjYW4gY29udGludWUgdG8gd29yayBvbiBhIERpc2NvdmVyeSBzcGVj
aWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWlrZSBKb25lcw0KPGJyPg0K
PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXJjaCAxMiwgMjAxNiA4OjA2IEFNPGJyPg0KPGI+VG86
PC9iPiBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29m
dC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBCcmlhbiBDYW1wYmVsbCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGlu
Z2lkZW50aXR5LmNvbTwvYT4mZ3Q7OyBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2
ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv
Yj4gb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5v
cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBXb3JraW5nIEdy
b3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
PlRoZSBkcmFmdCBlbmFibGVzIGVhc3kgY29uZmlndXJhdGlvbiBvZiBPQXV0aCBjbGllbnRzIHdp
dGggYW4gQVMuJm5ic3A7IEZvciBpbnN0YW5jZSwgdGhlIE1pY3Jvc29mdCDigJxBREFM4oCdIE9B
dXRoIGNsaWVudCBzb2Z0d2FyZSB1c2VzIEFTIG1ldGFkYXRhIGluIHRoaXMgZm9ybWF0IGFzDQog
YW4gaW5wdXQgYXQgY2xpZW50IGNvbmZpZ3VyYXRpb24gdGltZS48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkFzIGEgc2lkZSBiZW5lZml0LCBoYXZpbmcgdGhpcyBz
dGFuZGFyZCBBUyBtZXRhZGF0YSBmb3JtYXQgYW5kIHJldHVybmluZyB0aGUgaXNzdWVyIFVSTCBw
ZXIgdGhlIE1peC1VcCBNaXRpZ2F0aW9uIGRyYWZ0IHdpbGwgYWxzbyBlbmFibGUgY2xpZW50cyB0
byB2YWxpZGF0ZSB0aGF0DQogdGhleSBhcmUgdXNpbmcgYSBjb25zaXN0ZW50IHNldCBvZiBBUyBl
bmRwb2ludHMgYW5kIGluZm9ybWF0aW9uLiZuYnNwOyBCdXQgZXZlbiB3aXRob3V0IHRoZSBtaXRp
Z2F0aW9uIGJlbmVmaXRzLCB0aGUgY2xpZW50IGNvbmZpZ3VyYXRpb24gYmVuZWZpdCBpcyB0aGUg
cHJpbWFyeSByZWFzb24gZm9yIHRoZSBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZyI+bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm
IE9mIDwvYj5BbnRob255IE5hZGFsaW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAx
MSwgMjAxNiAzOjI1IFBNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIj5iY2FtcGJlbGxAcGluZ2lkZW50
aXR5LmNvbTwvYT4mZ3Q7OyBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJA
dmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1
dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBXb3JraW5nIEdyb3VwIExh
c3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EaXNhZ3JlZSwgd2hhdCBwdXJw
b3NlIGlzIHRoaXMgYWN0aXZpdHkgc29sdmluZyB0aGVuLCBpdCB3YXMgYmVpbmcgcHVzaGVkIGFz
IHdoYXQgd2FzIG5lZWQgdG8gc29sdmUgdGhlIE1peC11cCwgYnV0IHRoYXQgaXMgbm90IHRydWUu
IFNvIG5vdyB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBjaGFuZ2UgaW4NCiBzY29wZSBhbmQgbm90IGRl
YWxpbmcgd2l0aCBkaXNjb3ZlcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP
ZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAxMSwg
MjAxNiAzOjExIFBNPGJyPg0KPGI+VG86PC9iPiBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1h
aWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCjxi
PkNjOjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA
aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBXb3Jr
aW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBPQXV0aCAyLjAgRGlzY292ZXJ5PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHRl
bmQgdG8gYWdyZWUgd2l0aCBKb2huIHRoYXQgYWRkcmVzc2luZyB0aGUgY29uY2VybnMgUGhpbCBy
YWlzZXMgc2hvdWxkIGJlIHBhcnQgb2YgKGV4dGVuc2lvbiB0bykgdGhlIGNvcmUgcHJvdG9jb2wu
Jm5ic3A7IEFuZCB0aGF0IHRob3NlIGtpbmRzIG9mIGNvbmNlcm5zIGRvbid0IG1hbmlmZXN0IGlu
IHRoZSB3YXkgT0F1dGggaXMgdHlwaWNhbGx5IGRlcGxveWVkDQogbm93LiA8YnI+DQo8YnI+DQpU
aGUgaG9wZWZ1bGx5IHNvb24gdG8gYmUgbmFtZWQgJnF1b3Q7T0F1dGggMi4wIEF1dGhvcml6YXRp
b24gU2VydmVyIE1ldGFkYXRhJnF1b3Q7IHNob3VsZCBrZWVwIGl0J3Mgc2NvcGUgdG8gdGhlIHB1
Ymxpc2hpbmcgb2YgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWV0YWRhdGEuIFRoZSBhY3Qgb2YgZG9p
bmcgZGlzY292ZXJ5IGlzIGJleW9uZCBpdHMgc2NvcGUgYW5kIHNvIGlzIHRyeWluZyB0byBwcmV2
ZW50IGEgY2xpZW50IGZyb20gcHJlc2VudGluZyBhIHRva2VuIHRvDQogc29tZXBsYWNlIGl0IHNo
b3VsZG4ndC4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
biBGcmksIE1hciAxMSwgMjAxNiBhdCA5OjA4IEFNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9
Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIu
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0
OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
bmxpbmU8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBNYXIgMTEsIDIwMTYsIGF0IDEyOjEzIFBNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhy
ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVu
dEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9objxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBtYW55IGNhc2UgYWxsIHRoZSBBUyBoYXMgdG8g
Y2hlY2sgaXMgdGhlIGRvbWFpbiBuYW1lIGNvbXBvbmVudCB0byBjaGVjayBmb3IgbWl0bS4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UE9QIGFuZCB0aGUgb3RoZXIgc29sbnMgYXJlIGRyYW1hdGljYWxseSBtb3JlIGNvbXBsZXggdGhh
biBhIHNpbXBsZSBjaGVjay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgcHJvcG9z
aW5nIGRpbmcgdGhhdCBjaGVjayBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBvciB0b2tl
biBlbmRwb2ludCBhcyBwYXJ0IG9mIEFUIGlzc3VhbmNlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyB1cCB0byB0aGUgQVMg
aG93IG11Y2ggb2YgdGhlIHBhdGggdG8gdmFsaWRhdGUgYW5kIG9yIHB1dCBpbiB0aGUgYXVkIG9y
IGRzdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUgaXQgYXMgcGFydCBvZiB0
aGUgZGlzY292ZXJ5KGJhZCBuYW1lIGFzaWRlKSBwcm9ibGVtIGJlY2F1c2Ugd2UgZGlzY3Vzc2Vk
IHRoYXQgaWYgYSBjbGllbnQgZmluZHMNCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZhcHAuZXhhbXBsZS5jb20l
MmYmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRk
YTdhNDUwOTZiODQwOGQzNGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0
NyU3YzEmYW1wO3NkYXRhPWZpUzhmNjB5cGlYaHlNMHFWVGVxbCUyYiUyYk96SDJ3Ym1FQ1FFN0o1
VHRHUFFNJTNkIiB0YXJnZXQ9Il9ibGFuayI+DQphcHAuZXhhbXBsZS5jb208L2E+IGhvdyBkbyB3
ZSBlbnN1cmUgaXQgZ2V0cyBhIGNvbXBsZXRlIHNldCBvZiBvYXV0aCBlbmRwb2ludHMgYXMgYSB2
YWxpZCBzZXQgb2YgZW5kcG9pbnRzLS10aGF0IGEgaGFja2VyIGhhcyBub3QgaW5zZXJ0ZWQgb25l
IG9mIHRoZWlyIG93biBlbmRwb2ludHMuIFRoZSBtb3N0IGltcG9ydGFudCBlbmRwb2ludCB0byBn
ZXQgcmlnaHQgaXMgZW5zdXJpbmcgdGhlIHJlc291cmNlIHNlcnZlciAoYW5kIG9wdGlvbmFsbHkg
dGhlDQogcGF0aCkgaXMgdGhlIGNvcnJlY3Qgb25lLiBXZSBjYW4ndCByZWFsbHkgZGVmaW5lIHJl
c291cmNlIGRpc2NvdmVyeSBidXQgd2UgY2FuIHZhbGlkYXRlIGl0IHRvIHNvbWUgZGVncmVlLiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBpcyBwYXJ0IG9mIGNv
cmUgcHJvdG9jb2wgc2VjdXJpdHkgYW5kIHNob3VsZC9tdXN0IG5vdCByZXF1aXJlIGRpc2NvdmVy
eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+V2hhdCBpcyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u
b3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYXBwLmV4YW1wbGUuY29tJmFtcDtkYXRhPTAx
JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzRiOWJhZTVkZGE3YTQ1MDk2Yjg0MDhk
MzRhMDMxZTU3JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0
YT1qQXNaUWVDaEolMmJSMWxieUJvVkt3aGVJWWkzUGlXTHJxJTJieERMYnFVNnJ4ayUzZCIgdGFy
Z2V0PSJfYmxhbmsiPg0KYXBwLmV4YW1wbGUuY29tPC9hPiA/Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGl0IGlzIHRoZSByZXNv
dXJjZSB0aGVuIHRoZSBjbGllbnQgd291bGQgYmUgcHJlY29uZmlndXJlZCBmb3IgaXTigJlzIEFT
IG91dCBvZiBiYW5kIG9yIG9wdGlvbmFsbHkgd291bGQgZG8gZGlzY292ZXJ5IG9uIHRoZSBpc3N1
ZXIgdXJpIHRoYXQgeW91IGFkbWl0IG5lZWRzIHRvIGJlIGNvbmZpZ3VyZWQgb3V0IG9mIGJhbmQg
c29tZSB3YXkgKG5vdGUgZGlzY292ZXJ5IGlzIG9wdGlvbmFsKTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgQVMgbWV0YS1kYXRhIGRy
YWZ0IGl0IHdvdWxkIGRvIGEgZ2V0IG9uIGEgd2VsbCBrbm93biBmaWxlIHRoYXQgd291bGQgaGF2
ZSBjb25maWd1cmF0aW9uIGZvciB0aGUgQVMsIGJ1dCBub3QgdGhlIFJTLCB0aG91Z2ggc29tZSBB
UEkgbWF5IG9wdGlvbmFsbHkgbGlzdCBhIEFQSSBlbmRwb2ludCBsaWtlIGNvbm5lY3QgaGFzLiAm
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGhlIGNsaWVudCB0aGVuIG1ha2VzIGEgYXV0aG9yaXphdGlvbiByZXF1ZXN0IChhZnRlciBy
ZWdpc3RlcmluZyBvdXQgb2YgYmFuZCBvciBkeW5hbWljYWxseSkuICZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgcGFydCBvZiB0aGUg
YXV0aG9yaXphdGlvbiByZXF1ZXN0IGZvciBpbXBsaWNpdCBpdCBjb3VsZCBwcm92aWRlIHRoZSBh
dWQvZHN0IHRoYXQgaXQgd2FudHMgdGhlIHRva2VuIGZvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoYXQgaXMgbm90IHNlbnQgdGhlbiB0
aGUgYXVkL2RzdCBhcmUgaW1wbGljaXQgaW4gdGhlIHNjb3Blcy48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNsaWVudCBnZXRzIGJhY2sg
YSBBVCB3aXRoIGEgbGlzdCBvZiBzY29wZXMgZ3JhbnRlZCwgYXVkL2RzdCBhbGxvd2VkIGFuZCB0
aW1lIHRvIGxpdmUgZm9yIHRoZSB0b2tlbiAob25lIGV4dHJhIHRoaW5nIHJldHVybmVkKTxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRv
ZXNu4oCZdCByZXF1aXJlIGFueSBkaXNjb3ZlcnkgKHllcyB0aGVyZSBpcyBhIG9wdGlvbmFsIEFT
IG1ldGEtZGF0YSBkaXNjb3ZlcnkgYnV0IG5vdCByZXF1aXJlZCk8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBwcmVmZXIgdG8gZml4IHRoZSBS
UyBtYW4gaW4gdGhlIG1pZGRsZSBpc3N1ZSBhcyBwYXJ0IG9mIHRoZSBwcm90b2NvbCBhbmQgbm90
IHBhcnQgb2YgZGlzY292ZXJ5IHRoYXQgc2hvdWxkIHJlbWFpbiBvcHRpb25hbC48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBob25lc3RseSBk
b27igJl0IHF1aXRlIGtub3cgaG93IHRoZSBjbGllbnQgbGVhcm5zIGFib3V0IHRoaXMgYmFkIFJT
IGFuZCBzdGFydHMgdGFsa2luZyB0byBpdCwgc28gdGhpcyBtYXkgYmUgYSBzb2x1dGlvbiB0byBh
IHByb2JsZW0gdGhhdCBkb2VzbuKAmXQgeWV0IGV4aXN0LiAmbmJzcDsgVGhlIG9uZSBwbGFjZSB0
aGlzIGlzIHBvc2FibGUgaXMgaWYgdGhlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIGNsaWVudCBpcyBj
b21wcm9taXNlZC4mbmJzcDsNCiBIb3dldmVyIHdlIGFyZSBkaXNjdXNzaW5nIG90aGVyIG1pdGln
YXRpb25zIGZvciB0aGF0IHRoYXQgYWxzbyBleHBsaWNpdGx5IGRvIG5vdCByZXF1aXJlIGRpc2Nv
dmVyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBh
bSBub3Qgc3R1Y2sgb24gd2ViZmluZ2VyIG9yIHdlbGwta25vd24uIEJlY2F1c2UgdGhpcyBpcyBj
b25maWcgbWF5YmUgaXQgc2hvdWxkIGJlIGFuIG9hdXRoIGVuZHBvaW50LiZuYnNwOzxicj4NCjxi
cj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWFyIDExLCAyMDE2LCBh
dCAwNjo1MSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5j
b20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r
IFBoaWwgaXMgcHJvcG9zaW5nIHNvbWV0aGluZyBkaWZmZXJlbnQuICZuYnNwOyBTaG91bGQgdGhl
IGNsaWVudCBzZW5kIGEgdG9rZW4gZnJvbSB0aGlzIEFTIHRvIHRoYXQgUlMuICZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGlzIGdvYWwgaXMgdG8g
cHJldmVudCBtYW4gaW4gdGhlIG1pZGRsZSBhdHRhY2tzIHdoZXJlIGEgYmFkIFJTIGdldHMgYSBB
VCB0aGF0IGlzIGF1ZGlhbmNlZCB0by9hY2NlcHRlZCBieSBhbm90aGVyIFJTLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIHNlcGFy
YXRlIGZyb20gdGhlIHF1ZXN0aW9uIG9mIGlmIGEgUlMgYWNjZXB0cyB0b2tlbnMgZnJvbSBhIGdv
b2QgQVMuICZuYnNwOyBBIGJhZCBBUyB3b3VsZCBhbHdheXMgc2F5IHllcy48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgbmVlZCB0byBiZSBj
YXJlZnVsIG9mIHdoYXQgaWYgYW55dGhpbmcgdGhlIFJTIHByb3ZpZGVzIHRvIHRoZSBjbGllbnQg
YXMgbWV0YS1kYXRhIHdpdGhvdXQgdmFsaWRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3VycmVudGx5IHRoZSBjbGllbnQgY2FuIHBy
b3ZpZGUgYSBsaXN0IG9mIHNjb3BlcyByZXF1aXJlZCB0byBnZXQgYWNjZXNzLiAmbmJzcDsgSSBw
ZXJzb25hbGx5IGZlZWwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGFsc28gaW5jbHVkZSBpbiB0aGUg
dW5hdXRoZW50aWNhdGVkIGVycm9yIHJlc3BvbnNlIGFuIGluZGljYXRpb24gb2Ygd2hhdCBBUEkg
dGhlIHJlc291cmNlIHN1cHBvcnRzLiZuYnNwOyBTYXkg4oCcc2NpbTLigJ0gYXMgYW4gZXhhbXBs
ZS4NCiAmbmJzcDsgSSBkb27igJl0IHRoaW5rIGFkZGluZyB0aGF0IGlzIGhvd2V2ZXIgYSBoaWdo
IHByaW9yaXR5IGFzIG1vc3QgaWYgYWxsIGNsaWVudHMga25vdyB3aGF0IEFQSSB0aGV5IGV4cGVj
dC4gJm5ic3A7IEl0IG1pZ2h0IGJlIHVzZWZ1bCBpZiBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1
cmUgaWYgYSBjbGllbnQgd2VyZSB0byBiZSBnaXZlbiBhIFJTIFVSSSBpdCBjb3VsZCBjaGVjayB0
byBzZWUgaWYgaXQgaXMgYSBwcm90b2NvbCB0aGF0IGl0IHN1cHBvcnRzIGJlZm9yZQ0KIGJvdGhl
cmluZyB3aXRoIE9BdXRoLiAmbmJzcDsgJm5ic3A7SSBleHBlY3QgdGhhdCBhIGxvdCBvZiBwZW9w
bGUgd2lsbCB3YW50IHRoYXQgbGVmdCB0byB0aGUgQVBJIGRlZmluaXRpb24uICZuYnNwOyBJIHRo
aW5rIHdlIGNhbiB0YWxrIGFib3V0IGl0IGJ1dCByYXRlIHRoaXMgbG93IHByaW9yaXR5LjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVl
IHRoYXQgdGhlIFJTIGdpdmluZyBvdXQgYSBsaXN0IG9mIEFTIHRoYXQgaXQgdHJ1c3RzIGlzIGEg
Z2VuZXJhbGx5IGJhZCBpZGVhLiZuYnNwOyBJIGhvcGUgdGhhdCBpcyBub3Qgb24gdGhlIHRhYmxl
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IGRvbuKAmXQgdGhpbmsgdGhhdCBwcmV2ZW50aW5nIGEgY2xpZW50IGZyb20gc2VuZGluZyBhIHRv
a2VuIHRvIHRoZSB3cm9uZyBSUyBpcyBwYXJ0IG9mIGEgQVMgbWV0YS1kYXRhIGRpc2NvdmVyeSBw
cm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIGRvIGhvd2V2ZXIgdGhpbmsgdGhhdCBpdCBpcyBpbXBvcnRhbnQuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhdmUgYmVlbiBk
aXNjdXNzaW5nIHRoaXMgYXMgYSBzZXBhcmF0ZSBwcm9ibGVtIHRvIEFTIG1ldGEtZGF0YSBkaXNj
b3Zlcnkgd2hlcmUgdGhlIGVuZHBvaW50cyBvZiB0aGUgQVMgYW5kIGl04oCZcyBjb25maWd1cmF0
aW9uIGFyZSBkaXNjb3ZlcnkuICZuYnNwOyBTb3JyeSBmb3IgcGVyaGFwcyBzdGF0aW5nIHRoZSBv
YnZpb3VzLCBidXQgdGhlIFJTIGlzIGV4cGxpY2l0bHkgbm90IHBhcnQgb2YgdGhlIEFTIGluIE9B
dXRoDQogMi4gJm5ic3A7IFN0YXJ0aW5nIGluIFdBUCB0aGF0IHdhcyBhIGNvcmUgcHJpbmNpcGFs
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T
byB3ZSBoYXZlIGEgbnVtYmVyIG9mIG9wdGlvbnMgdG8gYWRkcmVzcyB0aGUgUlMgdG9rZW4gbGVh
a2FnZSB2aWEgTWlUTSBhdHRhY2tzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBQb1AgYm91bmQgdG9rZW5zLiZuYnNwOyBJZiB0aGV5IGFy
ZSBib3VuZCB0byB0aGUgVExTIGNoYW5uZWwgYnkgbXV0dWFsIFRMUyBvciBUb2tlbiBiaW5kaW5n
IHRoZXkgY2Fubm90IGJlIHJlcGxheWVkLiZuYnNwOyBTaWduZWQgbWVzc2FnZXMgd2hlcmUgdGhl
IHNpZ25pbmcgY292ZXJzIHRoZSBSUyBIb3N0IGFuZCBwYXRoIGNvbXBvbmVudHMsICZuYnNwO2Fs
c28gd291bGQgd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+MikgSGF2ZSB0aGUgQVMgYXVkaWVuY2UgcmVzdHJpY3QgdGhlIHJlc291cmNl
cyB0aGUgQVQgaXMgZ29vZCBhdC4gKEFUIHNob3VsZCBiZSBkb2luZyB0aGF0IG5vdykmbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRo
ZSB0b2tlbiByZXNwb25zZSBpbmNsdWRlIHRoZSBsaXN0IG9mIGF1ZGllbmNlL3MgdGhlIHRva2Vu
IGlzIHByZXNlbnRhYmxlIGF0LiZuYnNwOyBUaGUgY2xpZW50IHdvdWxkIHRocm93IGFuIGVycm9y
IGlmIHRoZSBSUyBpdCBpbnRlbmRzIHRvIHNlbmQgdGhlIHRva2VuIHRvIGlzIG5vdCBvbiB0aGUg
bGlzdC4gJm5ic3A7IFRoZSBSUyB0aGUgdG9rZW4gaXMgZ29vZCBhdCBtaWdodCBjaGFuZ2UgYmFz
ZWQgb24gc2NvcGVzLA0KIGNsaWVudF9pZCBhbmQgcmVzb3VyY2Ugb3duZXIuICZuYnNwOyBUaGlz
IGlzIHRoZSBwbGFjZSB3aGVyZSBhbGwgb2YgdGhhdCBjb21lcyB0b2dldGhlci4gJm5ic3A7IElu
IHNvbWUgY2FzZXMgdGhlIFJTIGFuZCBBUyBtaWdodCBub3QgaGF2ZSBhIHByZS1lc3RhYmxpc2hl
ZCByZWxhdGlvbnNoaXAuICZuYnNwOyBUaGUgY2xpZW50IHNob3VsZCBzZW5kIHRoZSBSUyBiYXNl
IFVSSSB0byB0aGUgQVMgYXMgcGFydCBvZiB0aGUgcmVxdWVzdC4mbmJzcDsgVGhlIEFTIGNhbiB1
c2UgdGhhdA0KIHRvIGF1ZGllbmNlIHJlc3RyaWN0IHRoZSBBVCBhbmQgaXNzdWUgdGhlIEFUIG9y
IHJlZnVzZSB0byBpc3N1ZSB0aGUgQVQgYmFzZWQgb24gcG9saWN5LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgY2FuIGFsc28gdXNlIHRoZSBh
dWRpZW5jZSBpbiB0aGUgcmVxdWVzdCB0byBkb3duIGF1ZGllbmNlIHRoZSBBVCBpZiB0aGUgZGVm
YXVsdCBpcyB0byBoYXZlIG11bHRpcGxlIGF1ZGllbmNlcy4gJm5ic3A7ICZuYnNwO1dlIG1heSB3
YW50IHRvIHVzZSBhIHRlcm0gb3RoZXIgdGhhbiBhdWRpZW5jZSBmb3IgdGhpcyBsaWtlIHJlc291
cmNlIG9yIGRlc3RpbmF0aW9uLiZuYnNwOyBJdCBpcyBhIGF1ZGllbmNlIGJ1dCB0aGF0IHRlcm0g
bWlnaHQNCiBjb25mdXNlIHBlb3BsZSB3aXRoIEFULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBkaWQgdGFsayBhYm91dCBicmVha2luZyBh
dWRpZW5jZSBvdXQgb2YgUE9QIGtleSBkaXN0cmlidXRpb24sIGFuZCBCcmlhbiBDYW1wYmVsbCBk
aWQgYSBkcmFmdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJm
ZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9U1RyJTJiNGtyZDFoeTho
NmVIT0NMaDFQelFhS01VaFdsS1YyaSUyZkNMMEsxU1ElM2QiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtZHN0NGp3dDwvYT4u
DQogJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRvIGRvIHRoaXMgd2UgY291bGQgdGFrZSBkc3Q0and0IGFuZCBhZGQgYW5v
dGhlciBzcGVjIHRoYXQgYWRkcyBhIG5ldyBkc3QgcGFyYW1ldGVyIHRvIHRoZSB0b2tlbiBhbmQg
YXV0aG9yaXphdGlvbiBlbmRwb2ludHMgcmVxdWVzdHMgVGhhdCB3b3VsZCBiZSBhIHNwYWNlIHNl
cGFyYXRlZCBsaXN0IG9mIGRzdCB2YWx1ZXMuICZuYnNwO2FuZCBpbiB0aGUgcmVzcG9uc2UgZnJv
bSB0aGUgdG9rZW4gZW5kcG9pbnQgd291bGQNCiBiZSBhIEpTT04gYXJyYXkgb2YgZHN0IHZhbHVl
cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
MykgSGF2ZSB0aGUgQVMgYWx3YXlzIHJldHVybiBhbGwgdGhlIGxpc3Qgb2YgYWxsIFJTIHRoZSB0
b2tlbiBjYW4gYmUgdXNlZCBhdCAoYmFzaWNhbGx5IE5hdCdzIGxpbmsgcmVsYXRpb25zaGlwIHBy
b3Bvc2FsKS4mbmJzcDsgSXQgbmVlZHMgYSB3YXkgdG8gaGFuZGxlJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kb3duIGRlc3RpbmF0aW9u
aW5nIG9mIEFUIGFuZCB0byBhbGxvdyBmb3IgdW4tY29uZmlndXJlZCBSUyB0aGF0IGl0IG1pZ2h0
IGlzc3VlIGEgdG9rZW4gZm9yLiZuYnNwOyBTbyBjb3VsZCBiZSBjb21iaW5lZCB3aXRoIGRzdCBm
cm9tIDIuJm5ic3A7IEJhc2ljYWxseSByZXR1cm5pbmcgdGhlIGFjY2VwdGFibGUgZGVzdGluYXRp
b25zIGFzIGxpbmsgaGVhZGVycyB2cyBKUyBpbiB0aGUgcmVzcG9uc2UgaXMgbW9zdGx5IGEgc3R5
bGUNCiBpc3N1ZSB0aGF0IG90aGVyIHBlb3BsZSBjYW4gYmlrZSBzaGVkLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQpIFRyeWluZyB0byBh
ZGQgYWxsIHRoZSBSUyB0byB0aGUgQVMgZGlzY292ZXJ5IGRvY3VtZW50LiZuYnNwOyBUaGlzIHNl
ZW1zIGltcHJhY3RpY2FsIGFzIHRoZXJlIHdvdWxkIGJlIG11bHRpcGxlIHByb3RvY29scyBhbmQg
ZG9lc27igJl0IGFkZHJlc3MgdW4tY29uZmlndXJlZCBSUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NSkgU29tZSBuZXcgQVMgZW5kcG9pbnQg
dGhhdCB0aGUgY2xpZW50IGNvdWxkIGludHJvc3BlY3QgdGhlIFJTIFVSSSBhbmQgZ2V0IGJhY2sg
bWV0YWRhdGEgYWJvdXQgaWYgdGhlIGNsaWVudCBzaG91bGQgc2VuZCB0b2tlbnMgdGhlcmUuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg
Jm5ic3A7IEEgY291cGxlIG9mIHByb2JsZW1zIHdpdGggdGhpcy4mbmJzcDsgVGhlIGZpcnN0IGlz
IHRoYXQgaXQgd291bGQgbm90IHN1cHBvcnQgdW4tY29uZmlndXJlZCBSUyB1bmxlc3MgeW91IGFk
ZCBkc3QgdG8gdGhlIHRva2VuIGFuZCBhdXRob3JpemF0aW9uIGVuZHBvaW50cy4gJm5ic3A7IFRo
ZSBvdGhlciBpcyB0aGF0IHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IGRvZXNu4oCZdCBoYXZl
IHRoZSBjb250ZXh0IG9mIHRoZSBSTw0KIGFuZCBjbGllbnRfaWQgdW5sZXNzIHlvdSBhbHNvIHBh
c3MgdGhlIGNvZGUvUlQgYW5kIGNsaWVudF9pZCwgYW5kIHByb2JhYmx5IGNsaWVudCBjcmVkZW50
aWFscy4gJm5ic3A7ICZuYnNwO0Jhc2ljYWxseSB0aGlzIGlzIHRyeWluZyB0byBpbnRyb3NwZWN0
IHRoZSBBVCB0byBkZXRlcm1pbmUgdGhlIGF1ZGlhbmNlL2RzdC4gJm5ic3A7IEJ5IHRoZSB0aW1l
IHlvdSBidWlsZCBhIG5ldyBpbnRyb3NwZWN0aW9uIGVuZHBvaW50IHNlY3VyZWx5IGl0IGlzIGdv
aW5nIHRvIGxvb2sNCiBsaWtlIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIGEgYml0IG1vcmUgbWV0
YSBkYXRhIGFib3V0IHRoZSB0b2tlbiBiZXlvbmQgZXhwaXJ5IGFuZCBzY29wZXMuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB3
ZSBzaG91bGQgZ28gYSBoZWFkIHdpdGggdGhlIHJlbmFtZWQgJnF1b3Q7T0F1dGggMi4wIEF1dGhv
cml6YXRpb24gU2VydmVyIERpc2NvdmVyeSBNZXRhZGF0YeKAnSZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBhbHNvIGZpbmUgd2l0
aCBtYWtpbmcgdGhlIGRlZmF1bHQgZG9jdW1lbnQgJ29wZW5pZC1jb25maWd1cmF0aW9u4oCZICZu
YnNwO2FzIGxvbmcgYXMgd2UgYWxsb3cgZm9yIHByb3RvY29sIHNwZWNpZmljIHZhcmlhdGlvbiBz
byB0aGF0IFNDSU0yIGNvdWxkIGRlZmluZSBhIGZpbGUgbmFtZS4gJm5ic3A7ICZuYnNwO0lmIHBl
b3BsZSB3YW50IHdlIGNvdWxkIGRvIGEgQVBJICZuYnNwO3RvIGZpbGUgbmFtZSByZWdpc3RyeSBz
byB0aGF0IHByb3RvY29sDQogc3BlY2lmaWMgb25lcyBjYW4gYmUgZGVmaW5lZC48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJlIGFsbC1y
ZWFkeSB3b3JraW5nIG9uIG9wdGlvbiAxIHRvIHNlY3VyZSBBVCwgd2UgbmVlZCBhIHNwZWMgbGlr
ZSBJIHByb3Bvc2UgaW4gMiBmb3IgYmVhcmVyIHRva2Vucy4mbmJzcDsgV2UgY2FuIGFkZCBvbmUg
cmVxdWVzdCBwYXJhbWV0ZXIgYW5kIGEgYml0IG1vcmUgdG9rZW4gbWV0YS1kYXRhIHRvIHRoZSB0
b2tlbiByZXNwb25zZSBhbmQgdGhhdCB0YWtlcyBjYXJlIG9mIHRoZSBwcm9ibGVtLiAmbmJzcDsg
SG9uZXN0bHkNCiB3ZSBwcm9iYWJseSBzaG91bGQgaGF2ZSBzZXBhcmF0ZWQgc2NvcGUgYW5kIGRl
c3RpbmF0aW9uIGluIHRoZSBmaXJzdCBwbGFjZSBhbmQgcmV0dXJuZWQgYm90aCBkc3QgYW5kIHNj
b3BlIGluIHRoZSByZXNwb25zZSBhbGwgYWxvbmcsIHNvIHRoaXMgaXMgdXBkYXRlIHRoYXQgaXMg
Y29uc2lzdGVudCB3aXRoIHRoZSBlaXN0aW5nIGFyY2hpdGVjdHVyZSBvZiBPQXV0aCAyLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXRzIGtl
ZXAgdGhlIHR3byBpc3N1ZXMgc2VwYXJhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1h
ciAxMSwgMjAxNiwgYXQgMTI6MDcgQU0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9z
b2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHJlbGF0aW9uc2hpcCBiZXR3
ZWVuIEFTIGFuZCBSUyBuZWVkIHRvIGJlIHNjb3BlZCB0byDigJxkb2VzIHRoaXMgUlMgYWNjZXB0
IHRva2VucyBmcm9tIHRoaXMgQVPigJ0gYXMgYSBsaXN0IGlzIHRvbyBtdWNoIGluZm9ybWF0aW9u
IHRoYXQgY291bGQgYmUgdXNlZCBpbiB0aGUgd3Jvbmcgd2F5PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iMTI3Mjg5NjQy
OV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7T0F1dGgg
WzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSZuYnNwOzxiPk9uDQogQmVoYWxmIE9m
Jm5ic3A7PC9iPk5hdCBTYWtpbXVyYTxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO1RodXJzZGF5LCBN
YXJjaCAxMCwgMjAxNiA2OjI1IFBNPGJyPg0KPGI+VG86PC9iPiZuYnNwO1BoaWwgSHVudCAoSURN
KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4mbmJzcDtvYXV0
aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1
dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbT0FVVEgt
V0ddIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIE9BdXRoIDIuMCBEaXNjb3Zlcnk8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5QaGlsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQuIFNvIHdoYXQgbXkgY29u
ZGl0aW9uYWwgYXBwcm92YWxzICgxMSBjb25kaXRpb25zIGluIHRvdGFsKSBzYWlkIHdhcyB0byBk
cm9wIHRoZSB3b3JkICZxdW90O2Rpc2NvdmVyeSZxdW90OyBmcm9tIGV2ZXJ5d2hlcmUuIFRoaXMg
aXMgbm90IGEgZGlzY292ZXJ5IHNwZWMuIFRoaXMgaXMgYSBjb25maWd1cmF0aW9uIGxvb2t1cCBz
cGVjIGFzIHlvdSBjb3JyZWN0bHkgcG9pbnRzIG91dC4gU28sIEkgYW0gd2l0aCB5b3UgaGVyZS4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgbXkgMm5kIGNvbmRpdGlpb24g
aXMgZXNzZW50aWFsbHkgc2F5aW5nIHRvIGRyb3Agc2VjdGlvbiAzLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5PbmUgdGhpbmcgdGhhdCBJIG92ZXJsb29rZWQgYW5kIGFtIHdpdGgg
eW91IGlzIHRoYXQgd2UgbmVlZCB0byBiZSBhYmxlIHRvIGV4cHJlc3MgdGhlIEFTLVJTIHJlbGF0
aW9uc2hpcHMuIEkgaGF2ZSBiZWVuIHByZWFjaGluZyB0aGlzIGluIHRoZSBvdGhlciB0aHJlYWQg
Zm9yIHNvIG1hbnkgdGltZXMgYXMgeW91IGtub3cgc28gSSB0aG91Z2h0IEkgcG9pbnRlZCBpdCBv
dXQsIGJ1dCBtaXNzZWQgYXBwYXJlbnRseQ0KIGluIG15IHByZXZpb3VzIGNvbW1lbnQuIFNvLCBJ
IHdvdWxkIGFkZCBteSAxMnRoIGNvbmRpdGlvbjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+MTIuIEEgd2F5IHRvIGV4cHJlc3MgYSBsaXN0IG9mIHZhbGlkIFJTcyBmb3IgdGhpcyBB
UyBuZWVkcyB0byBiZSBhZGRlZCB0byBzZWN0aW9uIDIuJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkJlc3QsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2LTAzLTExIDI6MDkgR01UJiM0MzswOTowMCBQaGls
IEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUu
Y29tPC9zcGFuPjwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3Ryb25nbHkgb3Bwb3NlLiAyIG1ham9yIGlzc3Vlcy4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBub3Qgc2VydmljZSBkaXNj
b3ZlcnkgdGhpcyBpcyBjb25maWd1cmF0aW9uIGxvb2t1cC4gVGhlIGNsaWVudCBtdXN0IGhhdmUg
YWxyZWFkeSBkaXNjb3ZlcmVkIHRoZSBvYXV0aCBpc3N1ZXIgdXJpIGFuZCB0aGUgcmVzb3VyY2Ug
dXJpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb2JqZWN0aXZlIHdhcyB0
byBwcm92aWRlIGEgbWV0aG9kIHRvIGVuc3VyZSB0aGUgY2xpZW50IGhhcyBhIHZhbGlkIHNldCBv
ZiBlbmRwb2ludHMgdG8gcHJldmVudCBtaXRtIG9mIGVuZHBvaW50cyBsaWtlIHRoZSB0b2tlbiBl
bmRwb2ludCB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGUgZHJhZnQgZG9lcyBub3QgYWRkcmVzcyB0aGUgaXNzdWUgb2YgYSBjbGllbnQg
YmVpbmcgZ2l2ZW4gYSBiYWQgZW5kcG9pbnQgZm9yIGFuIHJzLiBXaGF0IHdlIGVuZCB1cCB3aXRo
IGlzIGEgcHJvbWlzY3VvdXMgYXV0aHogc2VydmljZSBnaXZpbmcgb3V0IHRva2VucyB0byBhbiB1
bndpdHRpbmcgY2xpZW50LiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8
YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KT24gTWFyIDEwLCAyMDE2LCBhdCAwODowNiwgVmxhZGltaXIgRHpodXZpbm92
ICZsdDs8YSBocmVmPSJtYWlsdG86dmxhZGltaXJAY29ubmVjdDJpZC5jb20iIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwv
c3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mIzQzOzEgdG8g
bW92ZSBmb3J3YXJkIHdpdGggdGhlc2U8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gMTAvMDMvMTYgMTc6MzUsIEJyaWFuIENhbXBiZWxsIHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4mIzQzOzE8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PbiBUaHUsIE1hciAx
MCwgMjAxNiBhdCA2OjA0IEFNLCBSb2xhbmQgSGVkYmVyZyA8YSBocmVmPSJtYWlsdG86cm9sYW5k
LmhlZGJlcmdAdW11LnNlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+Jmx0O3JvbGFuZC5oZWRiZXJnQHVtdS5zZSZndDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPndyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwcmU+SSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgYmVpbmcgbW92ZWQgZm9yd2Fy
ZCB3aXRoIHRoZXNlIHR3byBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gY2hhbmdlIG5hbWUgdG8g4oCcT0F1dGggMi4wIEF1dGhv
cml6YXRpb24gU2VydmVyIERpc2NvdmVyeSBNZXRhZGF0YeKAnSBhczxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPnByb3Bvc2VkIGJ5IEJyaWFuIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gdXNl
IHRoZSBVUkkgcGF0aCBzdWZmaXgg4oCZb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXLigJkgaW5z
dGVhZCBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPuKAmW9wZW5pZC1jb25maWd1cmF0aW9u4oCZ
IGFzIHByb3Bvc2VkIGJ5IEp1c3Rpbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjE4IGZlYiAyMDE2IGtsLiAxNDo0MCBza3JldiBIYW5uZXMg
VHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQi
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oYW5uZXMudHNjaG9m
ZW5pZ0BnbXgubmV0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT46PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SGkgYWxsLDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgaXMg
YSBMYXN0IENhbGwgZm9yIGNvbW1lbnRzIG9uIHRoZSZuYnNwOyBPQXV0aCAyLjAgRGlzY292ZXJ5
PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+c3BlY2lmaWNhdGlvbjo8bzpw
PjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv
dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZo
dG1sJTJmZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEmYW1wO2RhdGE9MDElN2MwMSU3Y3Rv
bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIl
N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXczJTJiaWlh
V29uODFMSkNVJTJiMm1DUFJtQSUyYnJFQ0JIZ3F5UnIwT2dxaVdTSFUlM2QiIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNpbmNlIHRoaXMgZG9jdW1l
bnQgd2FzIG9ubHkgYWRvcHRlZCByZWNlbnRseSB3ZSBhcmUgcnVubmluZyB0aGlzIGxhc3Q8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5jYWxsIGZvciAqKjMgd2Vla3MqKi48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2UgaGF2ZSB5b3VyIGNv
bW1lbnRzIGluIG5vIGxhdGVyIHRoYW4gTWFyY2ggMTB0aC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DaWFvPG86cD48L286cD48L3ByZT4NCjxw
cmU+SGFubmVzICZhbXA7IERlcmVrPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48
L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2MxMTZlYWU2YmQxYjI0OTJkNTZhNTA4ZDM0OTU0NWM3MiU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9dE5DaWttWERCRjd1Ymsl
MmIlMmJ6SmlYd1BCMExJelFYQSUyZmslMmJxUjltNVdnQTJrJTNkIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N
CjxwcmU+4oCUIFJvbGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPuKAnUV2ZXJ5Ym9keSBzaG91bGQgYmUgcXVpZXQgbmVhciBhIGxpdHRsZSBz
dHJlYW0gYW5kIGxpc3Rlbi4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7RnJvbSDi
gJlPcGVuIEhvdXNlIGZvciBCdXR0ZXJmbGllc+KAmSBieSBSdXRoIEtyYXVzczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286
cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9h
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu
cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJm
bWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjMTE2ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJrJTJi
JTJiekppWHdQQjBMSXpRWEElMmZrJTJicVI5bTVXZ0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9z
cGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL25hMDEuc2Fm
ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRm
Lm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255
bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1YzcyJTdj
NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT10TkNpa21YREJG
N3ViayUyYiUyYnpKaVh3UEIwTEl6UVhBJTJmayUyYnFSOW01V2dBMmslM2QiIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r
LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZv
JTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMTE2
ZWFlNmJkMWIyNDkyZDU2YTUwOGQzNDk1NDVjNzIlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk
MDExZGI0NyU3YzEmYW1wO3NkYXRhPXROQ2lrbVhEQkY3dWJrJTJiJTJiekppWHdQQjBMSXpRWEEl
MmZrJTJicVI5bTVXZ0EyayUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+TmF0IFNha2ltdXJhICg9bmF0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv
bS8/dXJsPWh0dHAlM2ElMmYlMmZuYXQuc2FraW11cmEub3JnJTJmJmFtcDtkYXRhPTAxJTdjMDEl
N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzExNmVhZTZiZDFiMjQ5MmQ1NmE1MDhkMzQ5NTQ1
YzcyJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT02RlZt
ZE43YWQwWXpvWUtTTkYlMmZETyUyZmZHMkVGMWhhajVhT0hpTWlkNlVNSSUzZCIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9uYXQuc2FraW11cmEub3Jn
Lzwvc3Bhbj48L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm
JTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDEl
N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNGI5YmFlNWRkYTdhNDUwOTZiODQwOGQz
NGEwMzFlNTclN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRh
PWJLc0VWQlVYYzUyOHlhQU1MbXljWGNMMzMlMmJGSkNRcm5xOWFzeFJvNUhlOCUzZCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2M0YjliYWU1ZGRhN2E0NTA5NmI4NDA4ZDM0YTAzMWU1NyU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9YktzRVZCVVhjNTI4eWFB
TUxteWNYY0wzMyUyYkZKQ1FybnE5YXN4Um81SGU4JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BN3PR0301MB1234636F63100E32FD4E6FE7A6B60BN3PR0301MB1234_--


From nobody Sat Mar 12 09:03:31 2016
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 ACB5612D7BA for ; Sat, 12 Mar 2016 09:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.579
X-Spam-Level: 
X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-com.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 dEg0lVsmLwFf for ; Sat, 12 Mar 2016 09:03:28 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 E42CA12D7CF for ; Sat, 12 Mar 2016 09:03:27 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id h129so124432277ywb.1 for ; Sat, 12 Mar 2016 09:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=RwOxJ3vuI8+JGau7Nmlmg7Te0g3XeeeF4HfOkilpmrE=; b=lLjN8Sub/NtLQfWj8nqOH8qU1KA+lWsYxf+l4OwyWj+PCSaImF/WEYm0t3Kp163li3 cQ3DTs1pj7+emS69uMB/TvHDEJwVrw/aU3Qol0fGEk7RU1G2MFBVIBVVf0MNK3ca2jx0 YMF17S6SjQ7QDGiWl5Ll4gIj+vq7WoN8Vao85MR9uI4VbgQHKw1KPHrkZzQBtqFyXODw aQ9bvc8fCcikeA+QrD2BracCLshB9ePPjUzC3hjWq82USE8Ty1ZCzcYYArY5jXJ9Y7Bg cik1sYGfm/OcNtbFIjynMinc4vxRCl/k3aaAYnv51GtYe4Tp4JH8DZeZ8CPTHMZvNxGd nxDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=RwOxJ3vuI8+JGau7Nmlmg7Te0g3XeeeF4HfOkilpmrE=; b=Mi4D3cYBaYx0sRsLnQCx+Cli5Bt68vIo4MVtK3riFYIEM/ouc37X+mWEMS4DXT5sVM h9QYlda89pZK8JPzNXKMa3dPaVwJcgmZGM1ln+omOtAOOz+35yUFa6ggIJQabKNxt2tR tS6ZDwfdso78yejO5ZQoDXziKD8Pjzn/r3lDm7cJNSz+pKPWgEDRuQ6mU3ojK/CBGUjk 0Jpc1DkxTAucqdNKxRH14QOegRnMTeXHwFLc3eyE8ylx4tzWPgvCoobbWIaRKQs4rFgg 2PjPq1ostTWHvbE5MKixLYdWbyXUWrSFVOSZNV0V9EY/JKU1oCvXAnt6gNMZedGCG6dC GnLw==
X-Gm-Message-State: AD7BkJKufzuIMCJ9x0YabAHcgsxBlkQGhmGtfqUFdAtt+ln0W0vXaksnwDTdvFUA+HAyrMDpG093YRei3ygrVwRd
X-Received: by 10.37.93.137 with SMTP id r131mr8197782ybb.106.1457802207030; Sat, 12 Mar 2016 09:03:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.193.130 with HTTP; Sat, 12 Mar 2016 09:02:47 -0800 (PST)
In-Reply-To: 
References:  
From: Jim Willeke 
Date: Sat, 12 Mar 2016 09:02:47 -0800
Message-ID: 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a1140d942b470fd052ddd06e0
Archived-At: 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 17:03:29 -0000

--001a1140d942b470fd052ddd06e0
Content-Type: text/plain; charset=UTF-8

Why not register JWT as an access token type

and then the the Issuer is implied?

--
-jim
Jim Willeke

On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:

> Kawasaki-san,
>
> This is a really good question: how to know the issuer of a bearer token.
> Is there a header that could be added to specify the issuer, or other
> important metadata?
>
> - Mike
>
>
> -------------------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
> mike@gluu.org
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a1140d942b470fd052ddd06e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Why not register JWT as an access to=
ken type and then the the Issuer is implied?

    --
    -jim
    Jim Willeke
    

    On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwar=
tz <mike@gluu.org> wrote:
    Kawa=
saki-san,
    

    
This is a really good question: how to know the issuer of a bearer token. I=
s there a header that could be added to specify the issuer, or other import=
ant metadata?
    

    
- Mike
    

    

    
-------------------------------------
    
Michael Schwartz
    
Gluu
    
Founder / CEO
    
mike@gluu.org
    

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


    

--001a1140d942b470fd052ddd06e0--


From nobody Sat Mar 12 09:04:09 2016
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 12D7B12D7EA for ; Sat, 12 Mar 2016 09:04:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.09
X-Spam-Level: 
X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] 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 tnEHXe_U0iD3 for ; Sat, 12 Mar 2016 09:04:04 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 93A4012D6B0 for ; Sat, 12 Mar 2016 09:04:04 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2CH42Tj014995 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Mar 2016 17:04:03 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2CH41Qc002024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 12 Mar 2016 17:04:02 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2CH40l8022500; Sat, 12 Mar 2016 17:04:00 GMT
Received: from [25.80.78.218] (/72.143.232.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Mar 2016 09:03:59 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-471088D2-E134-4512-9945-69B2A5159F1E
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Sat, 12 Mar 2016 09:03:49 -0800
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>     
To: Mike Jones 
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 17:04:08 -0000

--Apple-Mail-471088D2-E134-4512-9945-69B2A5159F1E
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I will put that forward in an alternate draft.=20

Phil

> On Mar 12, 2016, at 08:28, Mike Jones  wrote:=

>=20
> The AS metadata format is a necessary part of discovery.  No, it doesn=E2=80=
=99t accomplish every possible aspect of discovery =E2=80=93 nor was it ever=
 intended to.  I=E2=80=99ve consistently encouraged Phil and others to write=
 down additional aspects of discovery in specifications that build upon this=
 one so that the working group and implementers can evaluate them.
> =20
> Since we=E2=80=99re chartered to do discovery and this is part of discover=
y, no rechartering is needed either for the current specification or for new=
 specifications performing additional discovery tasks.
> =20
>                                                           -- Mike
> =20
> From: Anthony Nadalin=20
> Sent: Saturday, March 12, 2016 8:20 AM
> To: Mike Jones ; Brian Campbell ; John Bradley 
> Cc: oauth 
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
> =20
> We agreed upon a discovery specification that the WG would work on, we did=
 not agree upon what this has turned out to actually be, so at the minimum t=
he chairs should call for adoption of a Authorization Server Metadata specif=
ication and we can continue to work on a Discovery specification
> =20
> From: Mike Jones=20
> Sent: Saturday, March 12, 2016 8:06 AM
> To: Anthony Nadalin ; Brian Campbell ; John Bradley 
> Cc: oauth 
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
> =20
> The draft enables easy configuration of OAuth clients with an AS.  For ins=
tance, the Microsoft =E2=80=9CADAL=E2=80=9D OAuth client software uses AS me=
tadata in this format as an input at client configuration time.
> =20
> As a side benefit, having this standard AS metadata format and returning t=
he issuer URL per the Mix-Up Mitigation draft will also enable clients to va=
lidate that they are using a consistent set of AS endpoints and information.=
  But even without the mitigation benefits, the client configuration benefit=
 is the primary reason for the specification.
> =20
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Friday, March 11, 2016 3:25 PM
> To: Brian Campbell ; John Bradley 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
> =20
> Disagree, what purpose is this activity solving then, it was being pushed a=
s what was need to solve the Mix-up, but that is not true. So now you are su=
ggesting a change in scope and not dealing with discovery.
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, March 11, 2016 3:11 PM
> To: John Bradley 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
> =20
> I tend to agree with John that addressing the concerns Phil raises should b=
e part of (extension to) the core protocol.  And that those kinds of concern=
s don't manifest in the way OAuth is typically deployed now.=20
>=20
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" s=
hould keep it's scope to the publishing of authorization server metadata. Th=
e act of doing discovery is beyond its scope and so is trying to prevent a c=
lient from presenting a token to someplace it shouldn't.
>=20
> =20
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley  wrote:
> Inline
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM)  wrote=
:
> =20
> John
> =20
> In many case all the AS has to check is the domain name component to check=
 for mitm.=20
> =20
> POP and the other solns are dramatically more complex than a simple check.=
=20
> =20
> I was proposing ding that check at the authorization endpoint or token end=
point as part of AT issuance.=20
> =20
> It is up to the AS how much of the path to validate and or put in the aud o=
r dst.=20
> =20
> =20
> =20
> I see it as part of the discovery(bad name aside) problem because we discu=
ssed that if a client finds app.example.com how do we ensure it gets a compl=
ete set of oauth endpoints as a valid set of endpoints--that a hacker has no=
t inserted one of their own endpoints. The most important endpoint to get ri=
ght is ensuring the resource server (and optionally the path) is the correct=
 one. We can't really define resource discovery but we can validate it to so=
me degree.=20
> =20
> I think it is part of core protocol security and should/must not require d=
iscovery.=20
> =20
> What is app.example.com ?=20
> =20
> If it is the resource then the client would be preconfigured for it=E2=80=99=
s AS out of band or optionally would do discovery on the issuer uri that you=
 admit needs to be configured out of band some way (note discovery is option=
al)
> =20
> In the AS meta-data draft it would do a get on a well known file that woul=
d have configuration for the AS, but not the RS, though some API may optiona=
lly list a API endpoint like connect has. =20
> =20
> The client then makes a authorization request (after registering out of ba=
nd or dynamically). =20
> As part of the authorization request for implicit it could provide the aud=
/dst that it wants the token for.
> If that is not sent then the aud/dst are implicit in the scopes.
> =20
> The client gets back a AT with a list of scopes granted, aud/dst allowed a=
nd time to live for the token (one extra thing returned)
> =20
> This doesn=E2=80=99t require any discovery (yes there is a optional AS met=
a-data discovery but not required)
> =20
> I prefer to fix the RS man in the middle issue as part of the protocol and=
 not part of discovery that should remain optional.
> =20
> I honestly don=E2=80=99t quite know how the client learns about this bad R=
S and starts talking to it, so this may be a solution to a problem that does=
n=E2=80=99t yet exist.   The one place this is posable is if the registratio=
n for the client is compromised.  However we are discussing other mitigation=
s for that that also explicitly do not require discovery.
> =20
> John B.
> =20
> =20
>=20
> I am not stuck on webfinger or well-known. Because this is config maybe it=
 should be an oauth endpoint.=20
>=20
> Phil
>=20
> On Mar 11, 2016, at 06:51, John Bradley  wrote:
>=20
> I think Phil is proposing something different.   Should the client send a t=
oken from this AS to that RS. =20
> =20
> His goal is to prevent man in the middle attacks where a bad RS gets a AT t=
hat is audianced to/accepted by another RS.
> =20
> That is separate from the question of if a RS accepts tokens from a good A=
S.   A bad AS would always say yes.
> =20
> We need to be careful of what if anything the RS provides to the client as=
 meta-data without validation.
> =20
> Currently the client can provide a list of scopes required to get access. =
  I personally feel it would be useful to also include in the unauthenticate=
d error response an indication of what API the resource supports.  Say =E2=80=
=9Cscim2=E2=80=9D as an example.   I don=E2=80=99t think adding that is howe=
ver a high priority as most if all clients know what API they expect.   It m=
ight be useful if at some point in the future if a client were to be given a=
 RS URI it could check to see if it is a protocol that it supports before bo=
thering with OAuth.    I expect that a lot of people will want that left to t=
he API definition.   I think we can talk about it but rate this low priority=
.
> =20
> I agree that the RS giving out a list of AS that it trusts is a generally b=
ad idea.  I hope that is not on the table.
> =20
> I don=E2=80=99t think that preventing a client from sending a token to the=
 wrong RS is part of a AS meta-data discovery problem.
> =20
> I do however think that it is important.
> =20
> We have been discussing this as a separate problem to AS meta-data discove=
ry where the endpoints of the AS and it=E2=80=99s configuration are discover=
y.   Sorry for perhaps stating the obvious, but the RS is explicitly not par=
t of the AS in OAuth 2.   Starting in WAP that was a core principal.
> =20
> So we have a number of options to address the RS token leakage via MiTM at=
tacks.
> =20
> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS o=
r Token binding they cannot be replayed.  Signed messages where the signing c=
overs the RS Host and path components,  also would work.
> =20
> 2) Have the AS audience restrict the resources the AT is good at. (AT shou=
ld be doing that now)=20
> In the token response include the list of audience/s the token is presenta=
ble at.  The client would throw an error if the RS it intends to send the to=
ken to is not on the list.   The RS the token is good at might change based o=
n scopes, client_id and resource owner.   This is the place where all of tha=
t comes together.   In some cases the RS and AS might not have a pre-establi=
shed relationship.   The client should send the RS base URI to the AS as par=
t of the request.  The AS can use that to audience restrict the AT and issue=
 the AT or refuse to issue the AT based on policy.
> It can also use the audience in the request to down audience the AT if the=
 default is to have multiple audiences.    We may want to use a term other t=
han audience for this like resource or destination.  It is a audience but th=
at term might confuse people with AT.
> =20
> We did talk about breaking audience out of POP key distribution, and Brian=
 Campbell did a draft https://tools.ietf.org/html/draft-campbell-oauth-dst4j=
wt.  =20
> =20
> To do this we could take dst4jwt and add another spec that adds a new dst p=
arameter to the token and authorization endpoints requests That would be a s=
pace separated list of dst values.  and in the response from the token endpo=
int would be a JSON array of dst values.
> =20
> 3) Have the AS always return all the list of all RS the token can be used a=
t (basically Nat's link relationship proposal).  It needs a way to handle=20=

> down destinationing of AT and to allow for un-configured RS that it might i=
ssue a token for.  So could be combined with dst from 2.  Basically returnin=
g the acceptable destinations as link headers vs JS in the response is mostl=
y a style issue that other people can bike shed.
> =20
> =20
> 4) Trying to add all the RS to the AS discovery document.  This seems impr=
actical as there would be multiple protocols and doesn=E2=80=99t address un-=
configured RS.
> =20
> 5) Some new AS endpoint that the client could introspect the RS URI and ge=
t back metadata about if the client should send tokens there.
>     A couple of problems with this.  The first is that it would not suppor=
t un-configured RS unless you add dst to the token and authorization endpoin=
ts.   The other is that the introspection endpoint doesn=E2=80=99t have the c=
ontext of the RO and client_id unless you also pass the code/RT and client_i=
d, and probably client credentials.    Basically this is trying to introspec=
t the AT to determine the audiance/dst.   By the time you build a new intros=
pection endpoint securely it is going to look like the token endpoint with a=
 bit more meta data about the token beyond expiry and scopes.
> =20
> =20
> I think we should go a head with the renamed "OAuth 2.0 Authorization Serv=
er Discovery Metadata=E2=80=9D=20
> I am also fine with making the default document 'openid-configuration=E2=80=
=99  as long as we allow for protocol specific variation so that SCIM2 could=
 define a file name.    If people want we could do a API  to file name regis=
try so that protocol specific ones can be defined.
> =20
> We are all-ready working on option 1 to secure AT, we need a spec like I p=
ropose in 2 for bearer tokens.  We can add one request parameter and a bit m=
ore token meta-data to the token response and that takes care of the problem=
.   Honestly we probably should have separated scope and destination in the f=
irst place and returned both dst and scope in the response all along, so thi=
s is update that is consistent with the eisting architecture of OAuth 2.
> =20
> Lets keep the two issues separate.
> =20
> John B.
> =20
> =20
> =20
> =20
> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin  wrot=
e:
> =20
> The relationship between AS and RS need to be scoped to =E2=80=9Cdoes this=
 RS accept tokens from this AS=E2=80=9D as a list is too much information th=
at could be used in the wrong way
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
> Sent: Thursday, March 10, 2016 6:25 PM
> To: Phil Hunt (IDM) 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
> =20
> Phil,=20
> =20
> Right. So what my conditional approvals (11 conditions in total) said was t=
o drop the word "discovery" from everywhere. This is not a discovery spec. T=
his is a configuration lookup spec as you correctly points out. So, I am wit=
h you here.=20
> =20
> Also, my 2nd conditiion is essentially saying to drop section 3.=20
> =20
> One thing that I overlooked and am with you is that we need to be able to e=
xpress the AS-RS relationships. I have been preaching this in the other thre=
ad for so many times as you know so I thought I pointed it out, but missed a=
pparently in my previous comment. So, I would add my 12th condition:=20
> =20
> 12. A way to express a list of valid RSs for this AS needs to be added to s=
ection 2.=20
> =20
> Best,=20
> =20
> Nat
> =20
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
> I strongly oppose. 2 major issues.=20
> =20
> This is not service discovery this is configuration lookup. The client mus=
t have already discovered the oauth issuer uri and the resource uri.=20
> =20
> The objective was to provide a method to ensure the client has a valid set=
 of endpoints to prevent mitm of endpoints like the token endpoint to the re=
source server.=20
> =20
> The draft does not address the issue of a client being given a bad endpoin=
t for an rs. What we end up with is a promiscuous authz service giving out t=
okens to an unwitting client.=20
>=20
> Phil
>=20
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  wr=
ote:
>=20
> +1 to move forward with these
>=20
> On 10/03/16 17:35, Brian Campbell wrote:
> +1
> =20
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
> wrote:
> =20
> I support this document being moved forward with these two changes:
> =20
> - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Metadat=
a=E2=80=9D as
> proposed by Brian and
> - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 ins=
tead of
> =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
> =20
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  :
> =20
> Hi all,
> =20
> This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> =20
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
> =20
> Please have your comments in no later than March 10th.
> =20
> Ciao
> Hannes & Derek
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =E2=80=94 Roland
> =20
> =E2=80=9DEverybody should be quiet near a little stream and listen."
> >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss
> =20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =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
>=20
>=20
>=20
> =20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> =20
> =20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-471088D2-E134-4512-9945-69B2A5159F1E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    I will put that forward in an alternat=
e draft. 

    Phil

    On Mar 12, 2016, at 08:28, Mike Jon=
es <Michael.Jones@microsof=
t.com> wrote:

    







    

    The AS metadata format is a necessary p=
art of discovery.  No, it doesn=E2=80=99t accomplish every possible asp=
ect of discovery =E2=80=93 nor was it ever intended to.  I=E2=80=99ve c=
onsistently
 encouraged Phil and others to write down additional aspects of discovery in=
 specifications that build upon this one so that the working group and imple=
menters can evaluate them.
    

     
    

    Since we=E2=80=99re chartered to do dis=
covery and this is part of discovery, no rechartering is needed either for t=
he current specification or for new specifications
 performing additional discovery tasks.
    

     
    

          &nb=
sp;            &=
nbsp;            =
;            &nb=
sp;             -=
- Mike
    

     =

    


    

    

    From: Anthony Nadalin

    
Sent: Saturday, March 12, 2016 8:20 AM
    
To: Mike Jones <Mic=
hael.Jones@microsoft.com>; Brian Campbell <bcampbell@pingidentity.com>; John Bradley <=
ve7jtb@ve7jtb.com>
    
Cc: oauth <oauth@ietf.org>=
;
    
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discover=
y
    

    

    

     
    

    We agreed upon a discovery specification that the WG w=
ould work on, we did not agree upon what this has turned out to actually be,=
 so at the minimum the chairs should call
 for adoption of a Authorization Server Metadata specification and we can co=
ntinue to work on a Discovery specification
    

     
    

    

    

    From: Mike Jones

    
Sent: Saturday, March 12, 2016 8:06 AM
    
To: Anthony Nadalin <tony=
nad@microsoft.com>; Brian Campbell <bcampbell@pingidentity.com>; John Bradley <ve7jtb@ve7jtb.com>
    
Cc: oauth <oauth@ietf.org>=
;
    
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discover=
y
    

    

    

     
    

    The draft enables easy configuration of=
 OAuth clients with an AS.  For instance, the Microsoft =E2=80=9CADAL=E2=
=80=9D OAuth client software uses AS metadata in this format as
 an input at client configuration time.
    

     
    

    As a side benefit, having this standard=
 AS metadata format and returning the issuer URL per the Mix-Up Mitigation d=
raft will also enable clients to validate that
 they are using a consistent set of AS endpoints and information.  But e=
ven without the mitigation benefits, the client configuration benefit is the=
 primary reason for the specification.
    

     
    

          &nb=
sp;            &=
nbsp;            =
;            &nb=
sp;             -=
- Mike
    

     
    

    

    

    From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Anthony Nadalin
    
Sent: Friday, March 11, 2016 3:25 PM
    
To: Brian Campbell <=
bcampbell@pingidentity.com>; John Bradley <ve7jtb@ve7jtb.com>
    
Cc: oauth <oauth@ietf.org>=
;
    
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discover=
y
    

    

    

     
    

    Disagree, what purpose is this activity solving then,=
 it was being pushed as what was need to solve the Mix-up, but that is not t=
rue. So now you are suggesting a change in
 scope and not dealing with discovery.
    

     
    

    From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell
    
Sent: Friday, March 11, 2016 3:11 PM
    
To: John Bradley <ve7jtb@ve7j=
tb.com>
    
Cc: oauth <oauth@ietf.org>=
;
    
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discover=
y
    

     
    

    

    I tend to agree with J=
ohn that addressing the concerns Phil raises should be part of (extension to=
) the core protocol.  And that those kinds of concerns don't manifest i=
n the way OAuth is typically deployed
 now. 
    

    
The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" sho=
uld keep it's scope to the publishing of authorization server metadata. The a=
ct of doing discovery is beyond its scope and so is trying to prevent a clie=
nt from presenting a token to
 someplace it shouldn't. 
    

    

    

     
    

    

    On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7jtb@ve7jtb.com>=
 wrote:
    

    

    

    Inline
    


    

     
    

    

    

    It is up to the AS how much of the path to validate a=
nd or put in the aud or dst. 
    

    

    

     
    

    

    

     
    

    

    

    

    

    

    

     
    

    

    

    I see it as part of the discovery(bad name aside) pro=
blem because we discussed that if a client finds

app.example.com how do we ensure it gets a complete set of oauth endpoin=
ts as a valid set of endpoints--that a hacker has not inserted one of their o=
wn endpoints. The most important endpoint to get right is ensuring the resou=
rce server (and optionally the
 path) is the correct one. We can't really define resource discovery but we c=
an validate it to some degree. 
    

    

    

     
    

    

    

    

    

    

    I think it is part of core protocol security and shou=
ld/must not require discovery. 
    

    

    

     
    

    

    

    What is 
app.example.com ? 
    

    

    

     
    

    

    

    If it is the resource then the client would be precon=
figured for it=E2=80=99s AS out of band or optionally would do discovery on t=
he issuer uri that you admit needs to be configured out of band some way (no=
te discovery is optional)
    

    

    

     
    

    

    

    In the AS meta-data draft it would do a get on a well=
 known file that would have configuration for the AS, but not the RS, though=
 some API may optionally list a API endpoint like connect has.  
    

    

    

     
    

    

    

    The client then makes a authorization request (after r=
egistering out of band or dynamically).  
    

    

    

    As part of the authorization request for implicit it c=
ould provide the aud/dst that it wants the token for.
    

    

    

    If that is not sent then the aud/dst are implicit in t=
he scopes.
    

    

    

     
    

    

    

    The client gets back a AT with a list of scopes grant=
ed, aud/dst allowed and time to live for the token (one extra thing returned=
)
    

    

    

     
    

    

    

    This doesn=E2=80=99t require any discovery (yes there=
 is a optional AS meta-data discovery but not required)
    

    

    

     
    

    

    

    I prefer to fix the RS man in the middle issue as par=
t of the protocol and not part of discovery that should remain optional.
    

    

    

     
    

    

    

    I honestly don=E2=80=99t quite know how the client le=
arns about this bad RS and starts talking to it, so this may be a solution t=
o a problem that doesn=E2=80=99t yet exist.   The one place this is pos=
able is if the registration for the client is compromised. 
 However we are discussing other mitigations for that that also explicitly d=
o not require discovery.
    

    

    

     
    

    

    

    John B.
    

    

    

    

    

     
    

    

     
    

    

    

    

    

    I am not stuck on webfinger or well-known. Because th=
is is config maybe it should be an oauth endpoint. 
    

    
Phil
    

    

    


    
On Mar 11, 2016, at 06:51, John Bradley <ve7jtb@ve7jtb.com> wrote:
    

    

    

    

    I think Phil is proposing something different.  =
 Should the client send a token from this AS to that RS.  

    

     
    

    

    

    His goal is to prevent man in the middle attacks wher=
e a bad RS gets a AT that is audianced to/accepted by another RS.=

    

    

    

     
    

    

    

    That is separate from the question of if a RS accepts=
 tokens from a good AS.   A bad AS would always say yes.
    =


    

    

     
    

    

    

    We need to be careful of what if anything the RS prov=
ides to the client as meta-data without validation.
    

    

    

     
    

    

    

    Currently the client can provide a list of scopes req=
uired to get access.   I personally feel it would be useful to also inc=
lude in the unauthenticated error response an indication of what API the res=
ource supports.  Say =E2=80=9Cscim2=E2=80=9D as an example.
   I don=E2=80=99t think adding that is however a high priority as most=
 if all clients know what API they expect.   It might be useful if at s=
ome point in the future if a client were to be given a RS URI it could check=
 to see if it is a protocol that it supports before
 bothering with OAuth.    I expect that a lot of people will want t=
hat left to the API definition.   I think we can talk about it but rate=
 this low priority.
    

    

    

     
    

    

    

    I agree that the RS giving out a list of AS that it t=
rusts is a generally bad idea.  I hope that is not on the table.
    

    

    

     
    

    

    

    I don=E2=80=99t think that preventing a client from s=
ending a token to the wrong RS is part of a AS meta-data discovery problem.<=
o:p>
    

    

    

     
    

    

    

    I do however think that it is important.

    

    

     
    

    

    

    We have been discussing this as a separate problem to=
 AS meta-data discovery where the endpoints of the AS and it=E2=80=99s confi=
guration are discovery.   Sorry for perhaps stating the obvious, but th=
e RS is explicitly not part of the AS in OAuth
 2.   Starting in WAP that was a core principal.
    

    

    

     
    

    

    

    So we have a number of options to address the RS toke=
n leakage via MiTM attacks.
    

    

    

     
    

    

    

    1) PoP bound tokens.  If they are bound to the T=
LS channel by mutual TLS or Token binding they cannot be replayed.  Sig=
ned messages where the signing covers the RS Host and path components,  =
;also would work.
    

    

    

     
    

    

    

    2) Have the AS audience restrict the resources the AT=
 is good at. (AT should be doing that now) 
    

    

    

    In the token response include the list of audience/s t=
he token is presentable at.  The client would throw an error if the RS i=
t intends to send the token to is not on the list.   The RS the token i=
s good at might change based on scopes,
 client_id and resource owner.   This is the place where all of that co=
mes together.   In some cases the RS and AS might not have a pre-establ=
ished relationship.   The client should send the RS base URI to the AS a=
s part of the request.  The AS can use that
 to audience restrict the AT and issue the AT or refuse to issue the AT base=
d on policy.
    

    

    

    It can also use the audience in the request to down a=
udience the AT if the default is to have multiple audiences.    We=
 may want to use a term other than audience for this like resource or destin=
ation.  It is a audience but that term might
 confuse people with AT.
    

    

    

     
    

    

    

    We did talk about breaking audience out of POP key di=
stribution, and Brian Campbell did a draft =
https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt.
   
    

    

    

     
    

    

    

    To do this we could take dst4jwt and add another spec=
 that adds a new dst parameter to the token and authorization endpoints requ=
ests That would be a space separated list of dst values.  and in the re=
sponse from the token endpoint would
 be a JSON array of dst values.
    

    

    

     
    

    

    

    3) Have the AS always return all the list of all RS t=
he token can be used at (basically Nat's link relationship proposal).  I=
t needs a way to handle 
    

    

    

    down destinationing of AT and to allow for un-configu=
red RS that it might issue a token for.  So could be combined with dst f=
rom 2.  Basically returning the acceptable destinations as link headers=
 vs JS in the response is mostly a style
 issue that other people can bike shed.
    

    

    

     
    

    

    

     
    

    

    

    4) Trying to add all the RS to the AS discovery docum=
ent.  This seems impractical as there would be multiple protocols and d=
oesn=E2=80=99t address un-configured RS.
    

    

    

     
    

    

    

    5) Some new AS endpoint that the client could introsp=
ect the RS URI and get back metadata about if the client should send tokens t=
here.
    

    

    

        A couple of problems with this.  T=
he first is that it would not support un-configured RS unless you add dst to=
 the token and authorization endpoints.   The other is that the introsp=
ection endpoint doesn=E2=80=99t have the context of the RO
 and client_id unless you also pass the code/RT and client_id, and probably c=
lient credentials.    Basically this is trying to introspect the A=
T to determine the audiance/dst.   By the time you build a new introspe=
ction endpoint securely it is going to look
 like the token endpoint with a bit more meta data about the token beyond ex=
piry and scopes.
    

    

    

     
    

    

    

     
    

    

    

    I think we should go a head with the renamed "OAuth 2=
.0 Authorization Server Discovery Metadata=E2=80=9D 
    

    

    

    I am also fine with making the default document 'open=
id-configuration=E2=80=99  as long as we allow for protocol specific va=
riation so that SCIM2 could define a file name.    If people want w=
e could do a API  to file name registry so that protocol
 specific ones can be defined.
    

    

    

     
    

    

    

    We are all-ready working on option 1 to secure AT, we=
 need a spec like I propose in 2 for bearer tokens.  We can add one req=
uest parameter and a bit more token meta-data to the token response and that=
 takes care of the problem.   Honestly
 we probably should have separated scope and destination in the first place a=
nd returned both dst and scope in the response all along, so this is update t=
hat is consistent with the eisting architecture of OAuth 2.
    

    

    

     
    

    

    

    Lets keep the two issues separate.
    

    

    

     
    

    

    

    John B.
    

    

    

     
    

    

    

     
    

    

    

     
    

    

    

     
    

    

    

    

    

    

    On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tonynad@microsoft.com=
> wrote:
    

    

     
    

    

    

    

    The relationship between AS and RS need to be scoped t=
o =E2=80=9Cdoes this RS accept tokens from this AS=E2=80=9D as a list is too=
 much information that could be used in the wrong way
    

    


    

    From: OAuth [mailto:oauth-bounces@ietf.org]&nb=
sp;On
 Behalf Of Nat Sakimura
    
Sent: Thursday, March 10, 2016 6:25 PM
    
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
    
Cc: oauth <oauth@ietf.org>
    
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Dis=
covery
    

    

    

     
    

    

    

    

    Phil, 
    

    

    

    

     
    

    

    

    

    

    Right. So what my conditional approvals (11 condition=
s in total) said was to drop the word "discovery" from everywhere. This is n=
ot a discovery spec. This is a configuration lookup spec as you correctly po=
ints out. So, I am with you here. 
    

    

    

    

    

     
    

    

    

    

    

    Also, my 2nd conditiion is essentially saying to drop=
 section 3. 
    

    

    

    

    

     
    

    

    

    

    

    One thing that I overlooked and am with you is that w=
e need to be able to express the AS-RS relationships. I have been preaching t=
his in the other thread for so many times as you know so I thought I pointed=
 it out, but missed apparently
 in my previous comment. So, I would add my 12th condition: =

    

    

    

    

    

     
    

    

    

    

    

    12. A way to express a list of valid RSs for this AS n=
eeds to be added to section 2. 
    

    

    

    

    

     
    

    

    

    

    

    Best, 
    

    

    

    

    

     
    

    

    

    

    

    Nat
    

    

    

    

    

    

     
    

    

    

    

    2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
    

    

    

    

    

    

    I strongly oppose. 2 major issues. 

    

    

    

    

     
    

    

    

    

    

    This is not service discovery this is configuration l=
ookup. The client must have already discovered the oauth issuer uri and the r=
esource uri. 
    

    

    

    

    

     
    

    

    

    

    

    The objective was to provide a method to ensure the c=
lient has a valid set of endpoints to prevent mitm of endpoints like the tok=
en endpoint to the resource server. 
    

    

    

    

    

     
    

    

    

    

    

    The draft does not address the issue of a client bein=
g given a bad endpoint for an rs. What we end up with is a promiscuous authz=
 service giving out tokens to an unwitting client. 
    

    
Phil
    

    

    

    

    

    


    
On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@con=
nect2id.com> wrote:
    

    

    

    

    +1 to move forward wit=
h these
    

    

    

    On 10/03/16 17:35, Brian Campbell wrote:

    

    

    

    +1
    

     
    

    On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.=
hedberg@umu.se>
    

    wrote:
    

     
    

    

    I support this document being moved forward with these two changes:
    

     
    

    - change name to =E2=80=9COAuth 2.0 Authorization Server Discovery Meta=
data=E2=80=9D as
    

    proposed by Brian and
    

    - use the URI path suffix =E2=80=99oauth-authorization-server=E2=80=99 i=
nstead of
    

    =E2=80=99openid-configuration=E2=80=99 as proposed by Justin.
    

     
    

    

    18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hanne=
s.tschofenig@gmx.net
    

    :
    

     
    

    Hi all,
    

     
    

    This is a Last Call for comments on the  OAuth 2.0 Discovery<=
/o:p>
    

    

    specification:
    

    

    https://too=
ls.ietf.org/html/draft-ietf-oauth-discovery-01
    

     
    

    Since this document was only adopted recently we are running this last<=
o:p>
    

    call for **3 weeks**.
    

     
    

    Please have your comments in no later than March 10th.
    =


     
    

    Ciao
    

    Hannes & Derek
    

     
    

    _______________________________________________
    

    OAuth mailing list
    

    OAuth@ietf.org
    

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

    

    =E2=80=94 Roland
    

     
    

    =E2=80=9DEverybody should be quiet near a little stream and listen."
    

    >=46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss<=
o:p>
    

     
    

     
    

    _______________________________________________
    

    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
    

    

    

    

    

    

    


    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailm=
an/listinfo/oauth
    

    

    

    


    

    

    

    

    

    

     
    

    

    

    

    -- 
    

    

    

    

    Nat Sakimura (=3Dnat)
    

    

    

    

    Chairman, OpenID Foundation
    
http://nat.sakimura.org/
    
@_nat_en
    

    

    

    

    

    

    _______________________________________________
    
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

    

    

     
    

    

    



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

--Apple-Mail-471088D2-E134-4512-9945-69B2A5159F1E--


From nobody Sat Mar 12 10:04:00 2016
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 2F1B112D56B for ; Sat, 12 Mar 2016 10:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 z-bFQPcFAfLn for ; Sat, 12 Mar 2016 10:03:47 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 5D3AD12D529 for ; Sat, 12 Mar 2016 10:03:45 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2CI3hXd002020 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Mar 2016 18:03:44 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2CI3gXK017286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 12 Mar 2016 18:03:42 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2CI3dOU005898; Sat, 12 Mar 2016 18:03:40 GMT
Received: from [25.80.78.218] (/72.143.232.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Mar 2016 10:03:38 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-D7BADF59-8F2F-474B-872E-33D2A1A2837B
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Sat, 12 Mar 2016 10:03:30 -0800
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   
To: Jim Willeke 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 18:03:50 -0000

--Apple-Mail-D7BADF59-8F2F-474B-872E-33D2A1A2837B
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

A header might open another attack vector. Better to parse the jwt and look f=
or the issuer assuming the jwt validates.=20

Phil

> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
>=20
> Why not register JWT as an access token type and then the the Issuer is im=
plied?
>=20
> --
> -jim
> Jim Willeke
>=20
>> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>> Kawasaki-san,
>>=20
>> This is a really good question: how to know the issuer of a bearer token.=
 Is there a header that could be added to specify the issuer, or other impor=
tant metadata?
>>=20
>> - Mike
>>=20
>>=20
>> -------------------------------------
>> Michael Schwartz
>> Gluu
>> Founder / CEO
>> mike@gluu.org
>>=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-D7BADF59-8F2F-474B-872E-33D2A1A2837B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


    A header might open another attack vector. Better to parse the jwt and look for the issuer assuming the jwt validates. 

    Phil

    On Mar 12, 2016, at 09:02, Jim Willeke <jim@willeke.com> wrote:

    Why not register JWT as an access token type and then the the Issuer is implied?

    --
    -jim
    Jim Willeke
    

    On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz <mike@gluu.org> wrote:
    Kawasaki-san,
    

    
This is a really good question: how to know the issuer of a bearer token. Is there a header that could be added to specify the issuer, or other important metadata?
    

    
- Mike
    

    

    
-------------------------------------
    
Michael Schwartz
    
Gluu
    
Founder / CEO
    
mike@gluu.org
    

    
_______________________________________________
    
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
    
--Apple-Mail-D7BADF59-8F2F-474B-872E-33D2A1A2837B--


From nobody Sat Mar 12 11:30:31 2016
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 DA3DF12D800 for ; Sat, 12 Mar 2016 11:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.579
X-Spam-Level: 
X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-com.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 N11PN-KLjizU for ; Sat, 12 Mar 2016 11:30:27 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 9E0AE12D567 for ; Sat, 12 Mar 2016 11:30:27 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id d65so126639114ywb.0 for ; Sat, 12 Mar 2016 11:30:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=jOVd6mOLXWR7g4J9P/8OV6cqbAmJWfzDSnOafhp4pYA=; b=ownkaxJLhjkytqzO6B5EOz3hlHASA87VSzCkAADyJZ063xSkrGACfnomAhyl/H4c8Q 1Ks/8UI4cTEiXjKEHvRcFKiz1BI395TKsBUO/oWWNI9nDKkILHchYyNHe03/wXqy9vqL WvopgZTZVnaAxeoPpFSOhqJqRU7tMlSh6iUNlnU/WbknowtPnbWHdZ+fxwuiLPeCcE4o tAW4aun5QlCQmVbeMmNZ5pOZyCNfg3NCoKcCQ2BGUgR1HXO+7O0CCfm0yPF+qKHldvaD Zs9bAo/zfgQ98KkhE2+ZvfgRkt5WZNL8LOD39M9EUh3ofFB4uZ3MpCsWSzNbn8D7Vz7Z nZvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=jOVd6mOLXWR7g4J9P/8OV6cqbAmJWfzDSnOafhp4pYA=; b=XRYJL25gKGb23IrbqKBdNnEsaM0gcR/jogL8jJkb0oxpkSJ1IGuAiWWcbWKEKzqn79 8GSNfpmtXLYQT1bF/ZOFAA6/gF+U3d+UABHyWIQ7uQP4jMeX87hu/au2PTOt7L49wpCr zmlYpVW5wT4ooLH4DBM7Alyv6VKR2FwlbC5VskRO6Ohu0SNr9Dt4UzFV5opbKzuXFCkN k8x1dcYbJnBO57pGBHWLQfb22GY/N86g7OO+7gdmXj1LOjnz0rbaHAJAIvOt01tEAKfU r/LD2/IR48wWN9Q0XDPHiykRKMAD1FEUxDSua11nqcZsFNbzQs9Ekx0kn8QHoGMl8gIH N6yw==
X-Gm-Message-State: AD7BkJIG8DVYIgEPfrJZl0Fwgas538BpGJFHD84EBLYkVSUII9/pG6v024YZLSEA7DbvADXf9UDFGS5w34bz0Sd3
X-Received: by 10.129.74.135 with SMTP id x129mr8410517ywa.74.1457811026529; Sat, 12 Mar 2016 11:30:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.193.130 with HTTP; Sat, 12 Mar 2016 11:29:47 -0800 (PST)
In-Reply-To: 
References:    
From: Jim Willeke 
Date: Sat, 12 Mar 2016 11:29:47 -0800
Message-ID: 
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a114d90be63038b052ddf1444
Archived-At: 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 19:30:30 -0000

--001a114d90be63038b052ddf1444
Content-Type: text/plain; charset=UTF-8

Would a header be a concern if TLS was used for transportation?

--
-jim
Jim Willeke

On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) 
wrote:

> A header might open another attack vector. Better to parse the jwt and
> look for the issuer assuming the jwt validates.
>
> Phil
>
> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
>
> Why not register JWT as an access token type
> 
> and then the the Issuer is implied?
>
> --
> -jim
> Jim Willeke
>
> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>
>> Kawasaki-san,
>>
>> This is a really good question: how to know the issuer of a bearer token.
>> Is there a header that could be added to specify the issuer, or other
>> important metadata?
>>
>> - Mike
>>
>>
>> -------------------------------------
>> Michael Schwartz
>> Gluu
>> Founder / CEO
>> mike@gluu.org
>>
>> _______________________________________________
>> 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
>
>

--001a114d90be63038b052ddf1444
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Would a header be a concern if TLS was used for transporta=
tion?

    --<=
/span>
    -jim
    Jim W=
illeke
    

    On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt =
(IDM) <phil.hunt@oracle.com> wrote:
    A header might open another attack vec=
tor. Better to parse the jwt and look for the issuer assuming the jwt valid=
ates.=C2=A0

    Phil

    On Mar 12, 2016, at 09:02, J=
im Willeke <jim@wil=
leke.com> wrote:

    Why not register JWT as an access token type and then the the Issuer is implied?

    --
    -jim
    Jim Willeke
    

    On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwar=
tz <mike@gluu.org> wrote:
    Kawa=
saki-san,
    

    
This is a really good question: how to know the issuer of a bearer token. I=
s there a header that could be added to specify the issuer, or other import=
ant metadata?
    

    
- Mike
    

    

    
-------------------------------------
    
Michael Schwartz
    
Gluu
    
Founder / CEO
    
mike@gluu.org
    

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


    

    ___________________=
____________________________
    OAuth mailing list
    <=
span>OAuth@ietf.org=

    https://www.ietf.org/mailman/listinfo/oauth
    <=
/div>

    

--001a114d90be63038b052ddf1444--


From nobody Sat Mar 12 11:37:03 2016
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 E4E4012D807 for ; Sat, 12 Mar 2016 11:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 DP2xXk3juwn5 for ; Sat, 12 Mar 2016 11:37:00 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 D967D12D805 for ; Sat, 12 Mar 2016 11:36:59 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2CJawGk010579 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 12 Mar 2016 19:36:58 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2CJawIs018876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 12 Mar 2016 19:36:58 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2CJavc0012787; Sat, 12 Mar 2016 19:36:57 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Mar 2016 11:36:57 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-A2A18886-9CF0-4981-A64B-D0656C45118E
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Sat, 12 Mar 2016 11:36:56 -0800
Content-Transfer-Encoding: 7bit
Message-Id: 
References:     
To: Jim Willeke 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 19:37:02 -0000

--Apple-Mail-A2A18886-9CF0-4981-A64B-D0656C45118E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Right now we are discussing mis-configured clients that have been convinced t=
o use a token or rs endpoint that has been mitm. Adding a new parameter incr=
eases attack surface because the rs is now ignoring the token abd believing t=
he header which may have been inserted.=20

Phil

> On Mar 12, 2016, at 11:29, Jim Willeke  wrote:
>=20
> Would a header be a concern if TLS was used for transportation?
>=20
> --
> -jim
> Jim Willeke
>=20
>> On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM)  w=
rote:
>> A header might open another attack vector. Better to parse the jwt and lo=
ok for the issuer assuming the jwt validates.=20
>>=20
>> Phil
>>=20
>>> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
>>>=20
>>> Why not register JWT as an access token type and then the the Issuer is i=
mplied?
>>>=20
>>> --
>>> -jim
>>> Jim Willeke
>>>=20
>>>> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>>>> Kawasaki-san,
>>>>=20
>>>> This is a really good question: how to know the issuer of a bearer toke=
n. Is there a header that could be added to specify the issuer, or other imp=
ortant metadata?
>>>>=20
>>>> - Mike
>>>>=20
>>>>=20
>>>> -------------------------------------
>>>> Michael Schwartz
>>>> Gluu
>>>> Founder / CEO
>>>> mike@gluu.org
>>>>=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
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-A2A18886-9CF0-4981-A64B-D0656C45118E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Right now we are discussing mis-config=
ured clients that have been convinced to use a token or rs endpoint that has=
 been mitm. Adding a new parameter increases attack surface because the rs i=
s now ignoring the token abd believing the header which may have been insert=
ed. 

    Phil

    On Mar 12, 2016, at 11:29, Jim Willeke &=
lt;jim@willeke.com> wrote:

    =

    Would a header be a co=
ncern if TLS was used for transportation?
    --
    -jim
    Jim Willeke
    

    On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (=
IDM) <phil.hunt@oracle.com> wrote:
    A header might open another attack vector. B=
etter to parse the jwt and look for the issuer assuming the jwt validates.&n=
bsp;

    Phil

    On Mar 12, 2016, at 09:02, Jim Willek=
e <jim@willeke.com> wrote:

    W=
hy not register JWT as an access toke=
n type and then the the Issuer is implied?

    --
    -=
jim
    Jim Willeke
    

    On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwart=
z <m=
ike@gluu.org> wrote:
    Kawasaki=
-san,
    

    
This is a really good question: how to know the issuer of a bearer token. Is=
 there a header that could be added to specify the issuer, or other importan=
t metadata?
    

    
- Mike
    

    

    
-------------------------------------
    
Michael Schwartz
    
Gluu
    
Founder / CEO
    
mike@gluu.org
    

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


    

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

--Apple-Mail-A2A18886-9CF0-4981-A64B-D0656C45118E--


From nobody Sat Mar 12 11:51:32 2016
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 D416412D804 for ; Sat, 12 Mar 2016 11:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 2M2rkEt9S42p for ; Sat, 12 Mar 2016 11:51:29 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 3F90C12D715 for ; Sat, 12 Mar 2016 11:51:29 -0800 (PST)
Received: by mail-lb0-x22c.google.com with SMTP id bc4so194625307lbc.2 for ; Sat, 12 Mar 2016 11:51:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7cHOXukchbAnbSD+PnZVKhF4cics5fZNcjP3BKMC0rc=; b=elfr/dYn4wArAnAeb1Jp7N40c3XwvWmttiir82YE4vQtDbRdG6iLOvY01VZlGbvi4M oC+3/EoRUcpriKSyd9jmKjcczYTa3/aBXM6WDOceh8IK0RkQTzMKfFGXQVtpb11NHgBw efK7M9g0X0l6137RX4BwjzzRzolH82e5ezCh99odC3T/dNzFfSrExYciTsUbwuanMxkU aUKwoHoauo+Ps1+ItH14FpbM6Ht3EPLyynMFzXubcXrF+TGYco91AaW/2dZ56Tq8HwGZ JjPYbWy+xSja39O3VikYbauQymcZ8f3AZeitWnHj00B2J7iWpWxVyTInRX2UwhMCrQKM iItw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7cHOXukchbAnbSD+PnZVKhF4cics5fZNcjP3BKMC0rc=; b=ZELOvI7otOlqVyVkFP9hy+UTh8PJmOvc5hXKmqtYYH7oY+8CK9JMyTet9C6H0BiYHH IqoRd7aClSB8Rk5YS3DiDDB9MiOxlfN8MuCdx8fTND9dTuRoYRtXxwCflIJawO5vHTSd oeYqjlnofr07PzLdhzSluFp+HHWNFNKuBbRGHmItvenzWyz42Fh9ghLVUYaDlnCZbx7A 0MpRrNweVsHlXn33Ppmfp/ubhG8CGckQ3oqX1jiev0VMmdlRJUqfzXm/qKKkWRc5bVZB Bxkrm9UxqpfEKpgJjX4Fd49Fd1MyUHURND5OwBHwaJ9cCIwKmekHMewtFun2kgubVIpb 7I2Q==
X-Gm-Message-State: AD7BkJIKsMdlsaq1PdS8HQj/7/7nTcTmvDzTxAPiqd/KKXobxdKZ7EObN9YMOUOFUBqscLA4Ey02HdD4N1CZww==
X-Received: by 10.25.89.201 with SMTP id n192mr5263906lfb.69.1457812287303; Sat, 12 Mar 2016 11:51:27 -0800 (PST)
MIME-Version: 1.0
References: <56C5C9D5.6040703@gmx.net>   <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com>    <091CB09C-1552-4777-ABF1-5E50DBC45437@oracle.com> <1CD23C2D-98EC-4FF9-AE43-F3D2453B3EB3@ve7jtb.com>      
In-Reply-To: 
From: Thomas Broyer 
Date: Sat, 12 Mar 2016 19:51:17 +0000
Message-ID: 
To: Anthony Nadalin , Mike Jones ,  Brian Campbell , John Bradley 
Content-Type: multipart/alternative; boundary=001a11412a2088ba83052ddf5f21
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Mar 2016 19:51:30 -0000

--001a11412a2088ba83052ddf5f21
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 12, 2016 at 6:01 PM Anthony Nadalin 
wrote:

> This is not discovery, its simply metadata, [=E2=80=A6], I don=E2=80=99t =
understand the
> rush to get this document out when we already know it=E2=80=99s incomplet=
e
>
+1

--001a11412a2088ba83052ddf5f21
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On Sat=
, Mar 12, 2016 at 6:01 PM Anthony Nadalin <tonynad@microsoft.com> wrote:
    






    

    

    This is not discovery, its simply metadata, [=E2=80=
=A6], I don=E2=80=99t understand the rush to get this document out when we =
already know it=E2=80=99s incomplete
    +1
    

--001a11412a2088ba83052ddf5f21--


From nobody Sat Mar 12 17:03:26 2016
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 BADB612D903 for ; Sat, 12 Mar 2016 17:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Oh0l8R4SNAQm for ; Sat, 12 Mar 2016 17:03:22 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 5277F12D8EE for ; Sat, 12 Mar 2016 17:03:22 -0800 (PST)
X-AuditID: 12074423-4d3ff700000061cf-6d-56e4bc594125
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 06.7D.25039.95CB4E65; Sat, 12 Mar 2016 20:03:21 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u2D13Kw6031688; Sat, 12 Mar 2016 20:03:20 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2D13IKH032459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 12 Mar 2016 20:03:20 -0500
To: Takahiko Kawasaki , "oauth@ietf.org" 
References: 
From: Justin Richer 
Message-ID: <56E4BC4D.9000806@mit.edu>
Date: Sat, 12 Mar 2016 20:03:09 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010700080202070501010109"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrRu550mYwdSH7BZdPZuZLE6+fcXm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGWsOnObrWCXZsU8oGQD4yKZLkZODgkBE4nX XzYwdzFycQgJtDFJNF86D+VsZJR43/SQCcK5zSTxcONkRpAWYQE/iVmX7jGB2CICPhJntj8D iwsJBEh0ne5iB7HZBFQlpq9pAavhFVCTuPz/HVCcg4MFKP7sqj5IWFQgRuL4u3OMECWCEidn PmEBsTkFAiW+/5wHFmcWCJO4Nec++wRGvllIymYhSUHYthJ35u5mhrDlJba/nQNl60os2raC HSbevHU28wJGtlWMsim5Vbq5iZk5xanJusXJiXl5qUW6Znq5mSV6qSmlmxhBAczuoryD8WWf 9yFGAQ5GJR7eHZOfhAmxJpYVV+YeYpTkYFIS5X0vAxTiS8pPqcxILM6ILyrNSS0+xCjBwawk whs4ASjHm5JYWZValA+TkuZgURLnZWRgYBASSE8sSc1OTS1ILYLJynBwKEnw/twF1ChYlJqe WpGWmVOCkGbi4AQZzgM0vBukhre4IDG3ODMdIn+KUVFKnPcdSEIAJJFRmgfXC0owCW8Pm75i FAd6RZg3bTdQFQ8wOcF1vwIazAQ0eELXI5DBJYkIKakGxjy+npR3Bs9LuVrPST79+uH/2eO7 F9Yk7tq34/2vT3OabQKuisrvKprBnBvu9j5zFt9n/uXB7s7Nx1xKL/S5/Us6cblzmnF6TMYO llk2C8OSjYIuebAo9ppt0Ti+VXtqQuGSG0b5hwuvlvPZmpxjuCFsoPlk8R/3G1Pmu1gtsvNs co2KM+6JUWIpzkg01GIuKk4EADdRH5kLAwAA
Archived-At: 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Mar 2016 01:03:24 -0000

This is a multi-part message in MIME format.
--------------010700080202070501010109
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

What we've done in deployments is to combine JWT and introspection. You 
have all of your servers issue signed JWTs that include the "iss" 
(issuer) in the body, signed with the key of the AS. The tokens also 
include a random "jti" field. The RS submits the token to the 
introspection endpoint of the server identified in "iss", but only after 
validating the signature and other basic bits of information. If the 
introspection call comes back positive (and with the right scope, 
client, and resource owner information), the resource is served.

  -- Justin

On 3/11/2016 10:02 PM, Takahiko Kawasaki wrote:
> Hello,
>
> I have a question.
>
> If there exist multiple authorization servers that can issue access 
> tokens for one resource server, when the resource server receives an 
> access token from a client application, as the first step, the 
> resource server has to determine which authorization server to use for 
> access token introspection.
>
> Is there any standard way to determine which authorization server to use?
>
> There may be several ways, for example:
>
> (1) Embed information about the access token issuer in the access token.
> (2) Add a request parameter to identify the access token issuer.
> (3) Separate protected resource endpoints for each authorization server.
>
> If there is a standard way, I'd like to know it.
>
> Best Regards,
> Takahiko Kawasaki
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------010700080202070501010109
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    What we've done in deployments is to combine JWT and introspection.
    You have all of your servers issue signed JWTs that include the
    "iss" (issuer) in the body, signed with the key of the AS. The
    tokens also include a random "jti" field. The RS submits the token
    to the introspection endpoint of the server identified in "iss", but
    only after validating the signature and other basic bits of
    information. If the introspection call comes back positive (and with
    the right scope, client, and resource owner information), the
    resource is served.
    
    
    
     -- Justin
    
    
    
    
    On 3/11/2016 10:02 PM, Takahiko
      Kawasaki wrote:
    
    
    
    
    
      
      
    
        
    
          
    
            
    
              
    
                
    
                  
    
                    
    
                      
    
                        
    Hello,
    
                          
    
                        
    
                        I have a question.
    
                        
    
                        If there exist multiple authorization servers
                        that can issue access tokens for one resource
                        server, when the resource server receives an
                        access token from a client application, as the
                        first step, the resource server has to determine
                        which authorization server to use for access
                        token introspection.
    
                        
    
                      
    
                      Is there any standard way to determine which
                      authorization server to use?
    
                      
    
                    
    
                    There may be several ways, for example:
    
                    
    
                  
    
                  (1) Embed information about the access token issuer in
                  the access token.
    
                
    
                (2) Add a request parameter to identify the access token
                issuer.
    
              
    
              (3) Separate protected resource endpoints for each
              authorization server.
    
              
    
            
    
            If there is a standard way, I'd like to know it.
    
            
    
          
    
          Best Regards,
    
        
    
        Takahiko Kawasaki
    
        
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  


--------------010700080202070501010109--


From nobody Sat Mar 12 17:04:41 2016
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 EF1C412D8F1 for ; Sat, 12 Mar 2016 17:04:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2tiowxgctXea for ; Sat, 12 Mar 2016 17:04:36 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 4AA2E12D8EE for ; Sat, 12 Mar 2016 17:04:36 -0800 (PST)
X-AuditID: 1209190c-4abff70000002ea8-08-56e4bca3057b
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id E1.AA.11944.3ACB4E65; Sat, 12 Mar 2016 20:04:35 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u2D14YkV031780; Sat, 12 Mar 2016 20:04:34 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2D14WfT000308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 12 Mar 2016 20:04:33 -0500
To: "Phil Hunt (IDM)" , Jim Willeke 
References:      
From: Justin Richer 
Message-ID: <56E4BC97.30107@mit.edu>
Date: Sat, 12 Mar 2016 20:04:23 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030201080704010307020500"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1l2850mYwcOjrBaXb6xmtTj59hWb xYL5jewOzB5Llvxk8vj49BaLx/otwQHMUVw2Kak5mWWpRfp2CVwZH+ZMZS/oiarY1vSDtYHx pEUXIyeHhICJROe0N2xdjFwcQgJtTBKbj3UxQTgbGSXm31/GAuHcZpJo+HaUBaRFWMBPYtal e0wgtoiAt8TrM0vYIYruMEkcXfiaESTBLCAk8eFSE1gDm4CqxPQ1LWANvAIqEs/2nQGLswDF V2+7BmaLCsRIHH93jhGiRlDi5MwnQHEODk4BO4kvy1IgRoZJLHyxhHECI/8sJFWzkKQgbFuJ O3N3M0PY8hLb386BsnUlFm1bwQ4Tb946m3kBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXUO9 3MwSvdSU0k2M4GCX5NnBeOaN1yFGAQ5GJR7eHZOfhAmxJpYVV+YeYpTkYFIS5X0vAxTiS8pP qcxILM6ILyrNSS0+xCjBwawkwhs4ASjHm5JYWZValA+TkuZgURLnLdx/OkxIID2xJDU7NbUg tQgmK8PBoSTBu3E3UKNgUWp6akVaZk4JQpqJgxNkOA/Q8B0gNbzFBYm5xZnpEPlTjIpS4rzv dgElBEASGaV5cL2gZJTw9rDpK0ZxoFeEeQWAqUmIB5jI4LpfAQ1mAho8oesRyOCSRISUVAPj nL1rOVtyexzT5F/GWoU9XCAyc8lUrh0tm6zsVf96Tluk0+Z59YhmcF3GCnXzt3bl2tOc1q3V OKTetHb2xBupu7e5aN81l+2+zMvTc/yx+DTf+fNY2pY9Fgw5qLsxZf/FfIa3s/LS7LLDWIKe mx74+sOd5aJP2prrpoF1b45N2pHTfehnA0+mEktxRqKhFnNRcSIAc1O5viEDAAA=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Mar 2016 01:04:40 -0000

This is a multi-part message in MIME format.
--------------030201080704010307020500
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Agree with Phil, an additional header is a bad idea. It's not only yet 
another thing that can be attacked, it's another thing that can get out 
of sync by the client. Always assume OAuth clients are the dumbest parts 
of the system.

  -- Justin

On 3/12/2016 2:36 PM, Phil Hunt (IDM) wrote:
> Right now we are discussing mis-configured clients that have been 
> convinced to use a token or rs endpoint that has been mitm. Adding a 
> new parameter increases attack surface because the rs is now ignoring 
> the token abd believing the header which may have been inserted.
>
> Phil
>
> On Mar 12, 2016, at 11:29, Jim Willeke  > wrote:
>
>> Would a header be a concern if TLS was used for transportation?
>>
>> --
>> -jim
>> Jim Willeke
>>
>> On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) 
>> > wrote:
>>
>>     A header might open another attack vector. Better to parse the
>>     jwt and look for the issuer assuming the jwt validates.
>>
>>     Phil
>>
>>     On Mar 12, 2016, at 09:02, Jim Willeke >     > wrote:
>>
>>>     Why not register JWT as anaccess token type
>>>     
>>>     and then the the Issuer is implied?
>>>
>>>     --
>>>     -jim
>>>     Jim Willeke
>>>
>>>     On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz >>     > wrote:
>>>
>>>         Kawasaki-san,
>>>
>>>         This is a really good question: how to know the issuer of a
>>>         bearer token. Is there a header that could be added to
>>>         specify the issuer, or other important metadata?
>>>
>>>         - Mike
>>>
>>>
>>>         -------------------------------------
>>>         Michael Schwartz
>>>         Gluu
>>>         Founder / CEO
>>>         mike@gluu.org 
>>>
>>>         _______________________________________________
>>>         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
>>
>>
>> _______________________________________________
>> 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


--------------030201080704010307020500
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Agree with Phil, an additional header is a bad idea. It's not only
    yet another thing that can be attacked, it's another thing that can
    get out of sync by the client. Always assume OAuth clients are the
    dumbest parts of the system.
    
    
    
     -- Justin
    
    
    
    
    On 3/12/2016 2:36 PM, Phil Hunt (IDM)
      wrote:
    
    
    
    
    
      
      
    Right now we are discussing mis-configured clients that have
        been convinced to use a token or rs endpoint that has been mitm.
        Adding a new parameter increases attack surface because the rs
        is now ignoring the token abd believing the header which may
        have been inserted. 
    
        
    
        Phil
    
      

    
        On Mar 12, 2016, at 11:29, Jim Willeke <jim@willeke.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
    Would a header be a concern if TLS was used for
            transportation?
    
          

    
            
    
              
    
                
    --
    
                -jim
    
                  Jim Willeke
    
            
    
            
    
            
    On Sat, Mar 12, 2016 at 10:03 AM,
              Phil Hunt (IDM) <phil.hunt@oracle.com>
              wrote:
    
              
    
                
    
                  
    A header might open another attack vector. Better
                    to parse the jwt and look for the issuer assuming
                    the jwt validates. 
    
                        
    
                        Phil
    
                  
    
                    
    
                      

    
                        On Mar 12, 2016, at 09:02, Jim Willeke <jim@willeke.com>
                        wrote:
    
                        
    
                      
    
                      
    
                        
    
                          
    Why not register JWT as an access token type and
                            then the the Issuer is implied?
    
                          

    
                            
    
                              
    
                                
    --
    
                                -jim
    
                                  Jim Willeke
    
                            
    
                            
    
                            
    On Sat, Mar 12,
                              2016 at 8:32 AM, Mike Schwartz <mike@gluu.org>
                              wrote:
    
                              
    Kawasaki-san,
    
                                
    
                                This is a really good question: how to
                                know the issuer of a bearer token. Is
                                there a header that could be added to
                                specify the issuer, or other important
                                metadata?
    
                                
    
                                - Mike
    
                                
    
                                
    
                                -------------------------------------
    
                                Michael Schwartz
    
                                Gluu
    
                                Founder / CEO
    
                                mike@gluu.org
    
                                
    
_______________________________________________
    
                                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
    
                        
    
                      
    
                    
    
                  
    
                
    
              
    
            
    
            
    
          
    
        
    
      
    
      
    
        
    _______________________________________________
    
          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

    
    
    
    
    
  


--------------030201080704010307020500--


From nobody Sun Mar 13 05:43:43 2016
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 A75E712D5F4 for ; Sun, 13 Mar 2016 05:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 n47DOJ6z39VR for ; Sun, 13 Mar 2016 05:43:39 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 110D812D5A2 for ; Sun, 13 Mar 2016 05:43:39 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id o6so65445398qkc.2 for ; Sun, 13 Mar 2016 05:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FlZB0S/QfrG10uaQLzRF0OBgHFbPs+IVC5s0DvgQ0wY=; b=eqZ52ukwT20tIkxDoZhTyduvoqsFuZ3idQn97abkD+YDdJydGBCA+mAU0l5xHu3R9b 0HGIxILbC9HTyfobJvCJrnHiFzcNnjAru43uME/nGRlkVhjgIgk07QIWc6kJfXTn8HKx fu/bC8Ei6F6aEahI/qfuSajNqDdELF4o4LBFicMhdPwFrOG3qHlFXeP+pldHxR5U3Isd c1w5+bIVlh8CiZD5ygkjyv3HZlDFmysMAkoH0UGfKuZ9tCAWtIVJPBeGSpO910y583H7 q2N4p+gybZM6VHo8CgVkMxWsaIntHehQVLxtPoiyb8Nm5HLNimVSTgQqSQil++679hYy 0sBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FlZB0S/QfrG10uaQLzRF0OBgHFbPs+IVC5s0DvgQ0wY=; b=Z//+7AJzBuKoeEFXLcjSagSc/3KbOkpMdip6NuzU1cF/VI8D5SXl7TIt8XmAPGNIGk TxAYhj/eQCzW9pdh4I44vc2zzj8SyE/UOywl5qL1EQPd+xlYLJwWEALEzovLqWoIr9OS ufLxAweNwEmJ5ldWNYca2gUKcRNDefBJequHVWzGujIz8dAMgzsUql+t0VTdsu4dQI6x Q0JSjamnNR6AWVVcwJoVzRkoKZWuMzkjPUc+4mk9+4i4ckZDioeK/5LDeOv2loUIkakK 5pMfZ2Yt9lIp/7Gvsu6X9Emje4JPKOWbMQknn4l+pDMN+MlRlkzsIA3EqB8/q4ejeutH ohXw==
X-Gm-Message-State: AD7BkJIhbAsPtHxMXI0o9EMv2FNPTAnmq0UVXFkxC1ao4c5X3yALD8TYH3YFOY5JjpzJnyo1b7KyUkKJdabDfw==
X-Received: by 10.55.221.18 with SMTP id n18mr23632072qki.50.1457873018049; Sun, 13 Mar 2016 05:43:38 -0700 (PDT)
MIME-Version: 1.0
References:       <56E4BC97.30107@mit.edu>
In-Reply-To: <56E4BC97.30107@mit.edu>
From: Nat Sakimura 
Date: Sun, 13 Mar 2016 12:43:27 +0000
Message-ID: 
To: Justin Richer , "Phil Hunt (IDM)" ,  Jim Willeke 
Content-Type: multipart/alternative; boundary=001a1147a5d45e5d15052ded8396
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Mar 2016 12:43:41 -0000

--001a1147a5d45e5d15052ded8396
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The question is about how RS can find the issuer from a bearer token that
it received from the client. Obviously, a header from the AS does not work.
We would have to have some kind of structured token. It can be a JWS or
something proprietary to the trust framework.

Note: the client is untrusted and forms an unprotected segment. You would
have to treat the client as the smartest, in a bad way.
2016=E5=B9=B43=E6=9C=8813=E6=97=A5(=E6=97=A5) 10:04 Justin Richer :

> Agree with Phil, an additional header is a bad idea. It's not only yet
> another thing that can be attacked, it's another thing that can get out o=
f
> sync by the client. Always assume OAuth clients are the dumbest parts of
> the system.
>
>
>  -- Justin
>
>
> On 3/12/2016 2:36 PM, Phil Hunt (IDM) wrote:
>
> Right now we are discussing mis-configured clients that have been
> convinced to use a token or rs endpoint that has been mitm. Adding a new
> parameter increases attack surface because the rs is now ignoring the tok=
en
> abd believing the header which may have been inserted.
>
> Phil
>
> On Mar 12, 2016, at 11:29, Jim Willeke  wrote:
>
> Would a header be a concern if TLS was used for transportation?
>
> --
> -jim
> Jim Willeke
>
> On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) 
> wrote:
>
>> A header might open another attack vector. Better to parse the jwt and
>> look for the issuer assuming the jwt validates.
>>
>> Phil
>>
>> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
>>
>> Why not register JWT as an access token type
>> 
>> and then the the Issuer is implied?
>>
>> --
>> -jim
>> Jim Willeke
>>
>> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>>
>>> Kawasaki-san,
>>>
>>> This is a really good question: how to know the issuer of a bearer
>>> token. Is there a header that could be added to specify the issuer, or
>>> other important metadata?
>>>
>>> - Mike
>>>
>>>
>>> -------------------------------------
>>> Michael Schwartz
>>> Gluu
>>> Founder / CEO
>>> mike@gluu.org
>>>
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> 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
>

--001a1147a5d45e5d15052ded8396
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The question is about how RS can find the issuer from a bearer token that i=
t received from the client. Obviously, a header from the AS does not work. =
We would have to have some kind of structured token. It can be a JWS or som=
ething proprietary to the trust framework. 

    Note: the client is untr=
usted and forms an unprotected segment. You would have to treat  the client=
 as the smartest, in a bad way. 
    2016=E5=B9=B43=E6=9C=8813=E6=97=A5(=E6=97=A5) 10:04 Justin Richer <=
jricher@mit.edu>:
    
 =20
   =20
 =20
  
    
    Agree with Phil, an additional header is a bad idea. It's not only
    yet another thing that can be attacked, it's another thing that can
    get out of sync by the client. Always assume OAuth clients are the
    dumbest parts of the system.

    
    
    
    =C2=A0-- Justin

    
    
    
    
    On 3/12/2016 2:36 PM, Phil Hunt (IDM)
      wrote:
    
    
    
    
    
     =20
      
    Right now we are discussing mis-configured clients that have
        been convinced to use a token or rs endpoint that has been mitm.
        Adding a new parameter increases attack surface because the rs
        is now ignoring the token abd believing the header which may
        have been inserted.=C2=A0
    
        
    
        Phil
    
      

    
        On Mar 12, 2016, at 11:29, Jim Willeke <jim@willeke.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
    Would a header be a concern if TLS was used for
            transportation?
    
          

    
            
    
              
    
                
    --
    
                -jim
    
                  Jim Willeke
    
            
    
            
    
            
    On Sat, Mar 12, 2016 at 10:03 AM,
              Phil Hunt (IDM) <phil.hunt@oracle.com>
              wrote:
    
              
    
                
    
                  
    A header might open another attack vector. Better
                    to parse the jwt and look for the issuer assuming
                    the jwt validates.=C2=A0<=
br>
                        
    
                        Phil
    
                  
    
                    
    
                      

    
                        On Mar 12, 2016, at 09:02, Jim Willeke <jim@willeke.com>
                        wrote:
    
                        
    
                      
    
                      
    
                        
                      
    
                      
    
                        
    ________________________________________=
_______
    
                          OAuth mailing list
    
                          OAuth@ietf.org
    
                          https://www.ietf.org/mailman/listinfo/oauth<=
/a>
    
                        
    
                      
    
                    
    
                  
    
                
    
              
    
            
    
            
    
          
    
        
    
      
    
      
    
        
      
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  
    

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

    

--001a1147a5d45e5d15052ded8396--


From nobody Sun Mar 13 13:44:39 2016
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 3533712D805 for ; Sun, 13 Mar 2016 13:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 ThAMNdWAKzd0 for ; Sun, 13 Mar 2016 13:44:35 -0700 (PDT)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE5612D7DD for ; Sun, 13 Mar 2016 13:44:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id 34DE9B4137 for ; Sun, 13 Mar 2016 20:44:10 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1457901850; x=1458765851; bh=7ecOuHreGC wHOsauHslT+TXKrEZcoxW3i6iF03VmMxI=; b=orxLOf6Fi7NQa+bM7lz2AEhw+3 92afow3iqIoMgdQXslnu7XSXXcNCdqqnXRyb2gY1l1m9kfKNChb5hOwVqkX8ZRF4 CqI+qCJRFH3aRr/6uIY1QxM7xiY6nuy8rTXZLA2PcTHpfb9rarRVCuxybCyl0jOO dtIhEmanIDOSvAbo8=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK7sQSQL3y1Z for ; Sun, 13 Mar 2016 20:44:10 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id F2A44B40E6 for ; Sun, 13 Mar 2016 20:44:09 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 13 Mar 2016 15:44:09 -0500
From: Mike Schwartz 
To: oauth@ietf.org
Organization: Gluu
In-Reply-To: 
References: 
Message-ID: <0dfa1c46a1a3a9267864dd3265a5c0eb@gluu.org>
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Mar 2016 20:44:38 -0000

I like the idea of an encrypted JWT... I guess if there are multiple 
AS's, how would you know which key to use? Cycle through each key? Are 
you suggesting maybe use a non-encrypted JWT that contains an encrypted 
JWT as a value? Something like

{"iss": "https://example.com",
  "token": "fjbfgy5Fdx8ybx0.."
}

Are there any OAuth2 profiles to standardize this approach?

- Mike


--------------------------

Michael Schwartz
Gluu
Founder / CEO
mike@gluu.org


From nobody Sun Mar 13 14:21:00 2016
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 9528312D848 for ; Sun, 13 Mar 2016 14:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 De4B3DXBp1Ks for ; Sun, 13 Mar 2016 14:20:56 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 C91F812D8D0 for ; Sun, 13 Mar 2016 14:20:55 -0700 (PDT)
Received: by mail-qg0-x22c.google.com with SMTP id w104so139517319qge.1 for ; Sun, 13 Mar 2016 14:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=3ULfGq/MYDUYbzZCRTosY1kyd75dDvBG6WElmXzSCHU=; b=VOR17sQjreGrb8LPHlzoGmohTfavZ7xspNst/U5A3R0hStGk+3rdLSm2N3TYs7XQyH YbHfC+fEY4tqrZvivTaTOOgbagW1tBX4xLgfPsscrRo/34MAx9MXwyBY4p/4N3bWgDPj Tj2vHqFaLuznsq5WWiN+lu7Z+A4NzSVsZbd3xDFnNMj+Lccd5XBQUAU+s0M+FIgXqDva OcIlHKUBJxTgftIC6xFZGKdyrpdoEGez/Alv4TEN7IZ3JAcFdAHiYmH+86kddFA+idIv MZKQFdEi1Ns65BrLGH4aY5XMBuhfYAILicDuCeBYjgWQv122YVKt5UC5ps+BVSQt2DTx o3VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3ULfGq/MYDUYbzZCRTosY1kyd75dDvBG6WElmXzSCHU=; b=Ol2oxxzSf4sD0Dt4zySKcGSKivDRSe2qt+tH2izn0OIwEg925zANrQbcTyzS6doq89 FkBnw80YMhXLrfNUHrPFhVhQNck6c6mdduVbhYfV0qQmDxyXhcIhb6+gZiHSSvuZQrJj L54lmid/lU27iSCCJLsFUFlzlnFECNpjzr45vOEAI4QBYX983r3ANdY4aZsg7ae7QdG3 U9Ar56jtucx1/Tvc6GzaA16vnpInRQo+G3p2qdScmRDrYXu+XXzWJvDf1NBdUxt4rJ5/ MJVzSOSuI2S4AAJ6zhI9PSiHMI3tWcKo312PIW8XfaIEaURKbkhMCNq+tqh1NCqf+H4T lw/g==
X-Gm-Message-State: AD7BkJLlK4l58jVt7erBjPeOjyhyyuVlBMB3FcWYDzlQE91FMpLrjudDyAhO1/B0YHTFxg==
X-Received: by 10.140.98.71 with SMTP id n65mr25892614qge.22.1457904054829; Sun, 13 Mar 2016 14:20:54 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.245.223]) by smtp.gmail.com with ESMTPSA id w187sm8842016qhc.5.2016.03.13.14.20.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Mar 2016 14:20:53 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_E897912E-B1D0-451E-AECC-19232C82A624"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <0dfa1c46a1a3a9267864dd3265a5c0eb@gluu.org>
Date: Sun, 13 Mar 2016 18:20:50 -0300
Message-Id: 
References:  <0dfa1c46a1a3a9267864dd3265a5c0eb@gluu.org>
To: Michael Schwartz 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Mar 2016 21:20:58 -0000

--Apple-Mail=_E897912E-B1D0-451E-AECC-19232C82A624
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I would expect the RS would only have one or two keys that it has =
published for encryption. =20

I would expect the encryptor to provide a key ID =E2=80=9Ckid=E2=80=9D  =
if the RS has published more than one key (eg for key rotation) and they =
probably should anyway unless size is unusually constrained.

See JWE 4.1.6

The number of AS is not relevant for encryption to the RS unless you are =
using symmetric keys, and in that case there is likely only one key per =
AS (iss) so iss should be sufficient.

John B.


> On Mar 13, 2016, at 5:44 PM, Mike Schwartz  wrote:
>=20
> I like the idea of an encrypted JWT... I guess if there are multiple =
AS's, how would you know which key to use? Cycle through each key? Are =
you suggesting maybe use a non-encrypted JWT that contains an encrypted =
JWT as a value? Something like
>=20
> {"iss": "https://example.com",
> "token": "fjbfgy5Fdx8ybx0.."
> }
>=20
> Are there any OAuth2 profiles to standardize this approach?
>=20
> - Mike
>=20
>=20
> --------------------------
>=20
> Michael Schwartz
> Gluu
> Founder / CEO
> mike@gluu.org
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_E897912E-B1D0-451E-AECC-19232C82A624
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTMyMTIwNTBaMCMGCSqGSIb3DQEJBDEWBBR0g3zK175DfpG7G65ksNik
7kEprTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAejWkd/hSGx3DknWHPsFik1Zuv0bVtQb+XrAWGE3qOwzQlzwnxiM2t
MRLuEPg/t1iJCB0+jruXCacG2Gu4RpMntVVrZn8FbHeJCxrIKUJCQ1L/T+L/di3SSqnHAK3TwIw6
0BZt/Dpv5XRe1NoS60FPyfp/fck8ZwMP3/k805Meyxy0BBuzwy8qZ8GinyEyzY+Q4DcqSHPbqrz8
TzKegoXGFre07hJeRQvQJT56aIAS3s+e6zTnX1RKdC6Z3Rzv0G8v7l0ZUFQC5KOUCWZ/HNteR/KB
SKMYyLivd0MBDBChnhiNQCu1v6TT4zBcztZd0GqLQ/RGfyUR1SN35lZWZvieAAAAAAAA
--Apple-Mail=_E897912E-B1D0-451E-AECC-19232C82A624--


From nobody Sun Mar 13 16:12:59 2016
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 4313F12D56B for ; Sun, 13 Mar 2016 16:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 xxACMLmDAWwp for ; Sun, 13 Mar 2016 16:12:56 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 DA50612D113 for ; Sun, 13 Mar 2016 16:12:55 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2DNComl027748 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Mar 2016 23:12:50 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2DNCi2D031586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Mar 2016 23:12:44 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2DNChXv021945; Sun, 13 Mar 2016 23:12:44 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Mar 2016 16:12:43 -0700
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_F0E0A62D-B657-4DED-9B51-213DEB608AA1"
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Sun, 13 Mar 2016 16:12:42 -0700
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>
To: oauth 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Subject: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Mar 2016 23:12:58 -0000

--Apple-Mail=_F0E0A62D-B657-4DED-9B51-213DEB608AA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry for =
OAuth Config Metadata as the authors believe that both solutions are not =
required, or depending on WG discussion they will be merged. The intent =
is to provide a simple complete draft for consideration.

How it works...
Given that a client has previously discovered an OAuth protected =
resource, the bound configuration method allows a client to return the =
configuration for an oauth authorization server that can issue tokens =
for the resource URI specified by the client.  The AS is not required to =
be in the same domain.  The AS is however required to know if it can =
issue tokens for a resource service (which presumes some agreement =
exists on tokens etc).

The draft does not require that the resource exist (e.g. for =
unconfigured or new user based resources). It only requires that the AS =
service provider agrees it can issue tokens.

=46rom a security perspective, returning the OAuth service configuration =
for a specified resource URI serves to confirm the client is in =
possession of a valid resource URI ensuring the client has received a =
valid set of endpoints for the resource and the associated oauth =
services.

I propose that the WG consider the alternate draft carefully as well as =
other submissions and evaluate the broader discovery problem before =
proceeding with WGLC on OAuth Discovery.

Thanks!

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =



> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
> Date: March 13, 2016 at 3:53:37 PM PDT
> To: "Phil Hunt" , "Anthony Nadalin" =
, "Tony Nadalin" 
>=20
>=20
> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
>=20
> Name:		draft-hunt-oauth-bound-config
> Revision:	00
> Title:		OAuth 2.0 Bound Configuration Lookup
> Document date:	2016-03-13
> Group:		Individual Submission
> Pages:		22
> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>=20
>=20
> Abstract:
>   This specification defines a mechanism for the client of an OAuth =
2.0
>   protected resource service to obtain the configuration details of an
>   OAuth 2.0 authorization server that is capable of authorizing access
>   to a specific resource service.  The information includes the OAuth
>   2.0 component endpoint location URIs and as well as authorization
>   server capabilities.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


--Apple-Mail=_F0E0A62D-B657-4DED-9B51-213DEB608AA1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry =
for OAuth Config Metadata as the authors believe that both solutions are =
not required, or depending on WG discussion they will be merged. The =
intent is to provide a simple complete draft for consideration.

    How it =
works...
    Given that a client has previously =
discovered an OAuth protected resource, the bound configuration method =
allows a client to return the configuration for an oauth authorization =
server that can issue tokens for the resource URI specified by the =
client.  The AS is not required to be in the same domain.  The =
AS is however required to know if it can issue tokens for a resource =
service (which presumes some agreement exists on tokens etc).

    The draft does not =
require that the resource exist (e.g. for unconfigured or new user based =
resources). It only requires that the AS service provider agrees it can =
issue tokens.

    =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.

    I propose that the WG consider the alternate draft carefully =
as well as other submissions and evaluate the broader discovery problem =
before proceeding with WGLC on OAuth Discovery.

    Thanks!

    


    



    Begin forwarded message:

    From: =
internet-drafts@ietf.org
    Subject: =
New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
    Date: =
March 13, 2016 at 3:53:37 PM =
PDT
    To: =
"Phil Hunt" <phil.hunt@yahoo.com>, "Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>


    A new version =
of I-D, draft-hunt-oauth-bound-config-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:		=
draft-hunt-oauth-bound-config
    Revision:	00
    Title:=
		=
OAuth 2.0 Bound Configuration Lookup
    Document =
date:	=
2016-03-13
    Group:		Individual Submission
    Pages:=
		=
22
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

    Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


    Abstract:
     =
  This specification defines a mechanism for the client of an =
OAuth 2.0
       protected resource service to =
obtain the configuration details of an
       OAuth =
2.0 authorization server that is capable of authorizing access
       to a specific resource service.  The =
information includes the OAuth
       2.0 component =
endpoint location URIs and as well as authorization
     =
  server capabilities.




    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.

    The IETF Secretariat


    =

--Apple-Mail=_F0E0A62D-B657-4DED-9B51-213DEB608AA1--


From nobody Sun Mar 13 17:00:54 2016
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 C6C1312D7CC for ; Sun, 13 Mar 2016 17:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 MgeuUCUT_nEe for ; Sun, 13 Mar 2016 17:00:51 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 3E0E112D84A for ; Sun, 13 Mar 2016 17:00:51 -0700 (PDT)
Received: by mail-lb0-x22c.google.com with SMTP id x1so218331916lbj.3 for ; Sun, 13 Mar 2016 17:00:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=Od5kSSl3GheatBgWEyjW2M+LgJrYRDPPdV++9vOP154=; b=hpRadff4sw6/aXs3QOKz6b+o5eqtfpErhswIZyv+yE7PydVfZXyPvuMyi1/EfGYaFO QFsCNio8O83fvGu1zg7GUbA6lxhoC6bV/oQ33jBesJwvJapDuIaSDUezpWuY8k1EjxbA IjayLYAotKRSY/bvRKtgSgje9o+lWT7XA4xxSHfQ31y7422yOYtq3e4sLFeLNWCQ5Na1 1KvxsqqtSRndZCUaHMlJFiRU8xx06I7W2P/JlyUj+cVqv7ngtuHE7Db33vwLUJIquwnb VhPpXUTrNW2JBbrA1SFUQaaJ+E6rUUp70APO8xzJCCEPjSP2NSb0wkyJf+f4cTlfPreg KR9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Od5kSSl3GheatBgWEyjW2M+LgJrYRDPPdV++9vOP154=; b=MpM+8Du9j4J3IbLMKyZKHXL2fYxxscLNl9GCfMBxkvl0t7/zo75hLrZMM+ZgmFMuox oilfRXMlZR5FPlkf/7GpuRNRG37eF2GzD3iJPCLEvNJO9eJgjZKlg+cvhHEda0PBVrvS r9T9qK+LfRRmPez+FgsL3hbN4nzsbymlixBaPBUPwvKu2OpKA9BWP4kMjGHBPiVXAirE snfTD/P24zd2bKGKnXLdOCrx+8aHzQVnYFgbnqjTXoUFgJxXiKtQxpdCYiaHzKldlQde QNgM94kR68UDXIYrxrtF/1/4gHeZm+p7/QVSh+QxNtCwFLcfMqfycCvxAON5SCs0iENj b3jA==
X-Gm-Message-State: AD7BkJIhfbbep2XkIP4Moz8Rguwnk/a7WI4naZwaWJL2VNEVrd70sIz9twf16GnlroFxqGka6e46WJotVrv7iw==
X-Received: by 10.25.37.136 with SMTP id l130mr5529033lfl.60.1457913649238; Sun, 13 Mar 2016 17:00:49 -0700 (PDT)
MIME-Version: 1.0
References:  <56E4BC4D.9000806@mit.edu>
In-Reply-To: <56E4BC4D.9000806@mit.edu>
From: Thomas Broyer 
Date: Mon, 14 Mar 2016 00:00:39 +0000
Message-ID: 
To: Justin Richer , Takahiko Kawasaki ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113fcdae2d1c43052df6f915
Archived-At: 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 00:00:54 -0000

--001a113fcdae2d1c43052df6f915
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 13, 2016 at 2:03 AM Justin Richer  wrote:

> What we've done in deployments is to combine JWT and introspection. You
> have all of your servers issue signed JWTs that include the "iss" (issuer)
> in the body, signed with the key of the AS. The tokens also include a
> random "jti" field. The RS submits the token to the introspection endpoint
> of the server identified in "iss", but only after validating the signature
> and other basic bits of information. If the introspection call comes back
> positive (and with the right scope, client, and resource owner
> information), the resource is served.
>

But you cannot force every AS to emit access tokens that are JWTs.
For those AS that won't, then the RS would probably have to provide
endpoints (token endpoints?), one per AS, where the client could exchange
an AT from the AS for an AT specific to the RS (using token exchange with
unauthenticated clients?)

--001a113fcdae2d1c43052df6f915
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On Sun=
, Mar 13, 2016 at 2:03 AM Justin Richer <jricher@mit.edu> wrote:
    
 =20
   =20
 =20
  
    
    What we've done in deployments is to combine JWT and introspection.
    You have all of your servers issue signed JWTs that include the
    "iss" (issuer) in the body, signed with the key of the AS. Th=
e
    tokens also include a random "jti" field. The RS submits the =
token
    to the introspection endpoint of the server identified in "iss&quo=
t;, but
    only after validating the signature and other basic bits of
    information. If the introspection call comes back positive (and with
    the right scope, client, and resource owner information), the
    resource is served.

    But you canno=
t force every AS to emit access tokens that are JWTs.
    For those A=
S that won't, then the RS would probably have to provide endpoints (tok=
en endpoints?), one per AS, where the client could exchange an AT from the =
AS for an AT specific to the RS (using token exchange with unauthenticated =
clients?)
    

--001a113fcdae2d1c43052df6f915--


From nobody Sun Mar 13 18:45:38 2016
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 1E95F12D81A for ; Sun, 13 Mar 2016 18:45:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 XvQUJ6YdgpFP for ; Sun, 13 Mar 2016 18:45:34 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 8555C12D534 for ; Sun, 13 Mar 2016 18:45:33 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id x1so69683972qkc.1 for ; Sun, 13 Mar 2016 18:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Lkm1BUxqKobOYV1RHeLqHYbOvundUheh+n08hVfpAXw=; b=HgTVwm7GLo9MlKX5HzUovWpmXnxM2JtaCwm666cZS3oGr6jQ//NABW5JKefGLXiXxY 8OEHNz5XqYWkmV53yjGiIee9GgJ52F6iZj0hULCvPcevTsANBDcUaP8hA+ypRnJ5Yc6B UH2nvukBBiVXAA2SpQEMJgR1pOCFx8AUyDaAw0Mn98cJvCr+xhHsongofQlBn+GIHo82 hJ+GwEzX/457kCWDesWPTq2iXq1N+8bQesDs8SCCPFlcIi4YZMtFB7cxuLPwkQ6h1sTc xj14B5x0fDtxZASlNGL8ssQKXJ8EMCrGEcsH7KE6VHt9nsL3uWQ9mgLOMH4kGSBak65f vHOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Lkm1BUxqKobOYV1RHeLqHYbOvundUheh+n08hVfpAXw=; b=d65Y9B/Dcp7rSVoM1mfhbeE5a7c3GxSecsH9gCUmkcHz2x/B1oamS8OD5BAc9ocDk+ nzqJS5jGoGjaSje0RS5ko0CN4+15q4FahvRz3rg9n/s7l10kGIhG8BgdXUoHwpl7OfKB 56aBtIrxTkF0lZlLW8ZUWoWE6M0sFkx/yqOP9kkWR2LtcHGvJkkG6u8MJ3n4zaehvK+A 8Qa5DFaVRfib6FmnT2GVQ0oCqEcDJgRGAgQgVogdK+loudhTaF4IlyRYMlf3oA7ENgwz 8FJy6R5GNn3pbGH0h1dwMKelE6QCS1UV8qCwdgdEAuCH1z02zdqeIIuBl6GfwNiip2Nj VyWQ==
X-Gm-Message-State: AD7BkJIAj20OrAAjfn7N2s56N2g7R4iCGILHB40IRFUuWdQs2WfhvfhNH9I4xDVo4BrTyg==
X-Received: by 10.55.74.141 with SMTP id x135mr26707380qka.20.1457919932535; Sun, 13 Mar 2016 18:45:32 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.43.182]) by smtp.gmail.com with ESMTPSA id 49sm9273941qgx.32.2016.03.13.18.45.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Mar 2016 18:45:31 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_6AE33B0B-D97B-49F6-9D06-EBC61397CA42"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Sun, 13 Mar 2016 22:45:26 -0300
Message-Id: <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 01:45:37 -0000

--Apple-Mail=_6AE33B0B-D97B-49F6-9D06-EBC61397CA42
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6C392291-F9D4-41A3-B5CC-E95A590E2B5D"


--Apple-Mail=_6C392291-F9D4-41A3-B5CC-E95A590E2B5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

As I have told Phil off list. =20

Discovery is the wrong place to try and provide security against man in =
the middle attacks on the RS.

This requires the client to know what the RS URI is before retrieving =
the information on the AS Configuration.

The proposal Mike and I have been working on requires the client to have =
a notion of what API it is looking for and retrieve the .well-known file =
for that API from the issuer.   That allows a protocol like Connect to =
register its own config file that can point to the RS.  =20

If the API specific well known is not available the client can try the =
default oauth-server one.

That then allows us to deal with restricting where AT are presented as =
part of the protocol rather then dragging discovery in as a requirement.

In my opinion the resource the token is targeted to should be separated =
from the scope and returned as part of the meta-data about the AT along =
with scopes granted and expiry time.   We should also have a input =
parameter for resources so that a client can restrict tokens issued to a =
subset of the ones granted by the refresh token.   It would then also be =
possible to ask a AS for a token for a unregistered RS and have the AS =
produce a JWT access token with the resource as an audience if policy =
allows.

That however was supposed to be dealt with as part of the mixed up =
client set of mitigations. =20
In that the goal was to mitigate the attacks by returning meta-data =
about the tokens, and not to require discovery.

We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=9D =
for the code, and I intend to discuss at the F2F returning resource for =
AT as well.

Those mitigate the attack. =20

I will continue to resist mixing up discovery of configuration meta-data =
with mitigation of the attacks.

We return meta-data about the tokens now, because AT are opaque to the =
client, we neglected to include some of the information for the client =
needs to be secure.   We just need to add that in to the existing flows.

While Phil=E2=80=99s proposal is easier for the AS to implement as an =
add on, it puts more of a burden on the client needing to potentially =
change how it stores the relationships between AS and RS to prevent =
compromise, I think the solution should be biased towards simplicity on =
the client side.

If we return the resources as part of the existing meta data the client =
checks that against the resource it intends to send the token to and if =
it is not in the list then it can=E2=80=99t send the token.  Simple =
check every time it gets a new AT, no optionality.

I am not saying anything new Nat has been advocating basically this for =
some time, and dis submit a draft.   I prefer to return the info in the =
existing format rather than as link headers,  but that is the largest =
difference between what Nat and I are saying with respect to resource.

That is the core of my problem with Phil=E2=80=99s draft.

I guess we will need to have a long conversation in BA.

Regards
John B.

> On Mar 13, 2016, at 8:12 PM, Phil Hunt  wrote:
>=20
> This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry for =
OAuth Config Metadata as the authors believe that both solutions are not =
required, or depending on WG discussion they will be merged. The intent =
is to provide a simple complete draft for consideration.
>=20
> How it works...
> Given that a client has previously discovered an OAuth protected =
resource, the bound configuration method allows a client to return the =
configuration for an oauth authorization server that can issue tokens =
for the resource URI specified by the client.  The AS is not required to =
be in the same domain.  The AS is however required to know if it can =
issue tokens for a resource service (which presumes some agreement =
exists on tokens etc).
>=20
> The draft does not require that the resource exist (e.g. for =
unconfigured or new user based resources). It only requires that the AS =
service provider agrees it can issue tokens.
>=20
> =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.
>=20
> I propose that the WG consider the alternate draft carefully as well =
as other submissions and evaluate the broader discovery problem before =
proceeding with WGLC on OAuth Discovery.
>=20
> Thanks!
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>> Begin forwarded message:
>>=20
>> From: internet-drafts@ietf.org 
>> Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>> Date: March 13, 2016 at 3:53:37 PM PDT
>> To: "Phil Hunt" >, =
"Anthony Nadalin" >, "Tony Nadalin" >
>>=20
>>=20
>> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>> has been successfully submitted by Phil Hunt and posted to the
>> IETF repository.
>>=20
>> Name:		draft-hunt-oauth-bound-config
>> Revision:	00
>> Title:		OAuth 2.0 Bound Configuration Lookup
>> Document date:	2016-03-13
>> Group:		Individual Submission
>> Pages:		22
>> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =

>> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =

>>=20
>>=20
>> Abstract:
>>   This specification defines a mechanism for the client of an OAuth =
2.0
>>   protected resource service to obtain the configuration details of =
an
>>   OAuth 2.0 authorization server that is capable of authorizing =
access
>>   to a specific resource service.  The information includes the OAuth
>>   2.0 component endpoint location URIs and as well as authorization
>>   server capabilities.
>>=20
>>=20
>>=20
>>=20
>> 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 =
.
>>=20
>> The IETF Secretariat
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_6C392291-F9D4-41A3-B5CC-E95A590E2B5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

As I have told Phil off list.  

    Discovery is the wrong place to try and =
provide security against man in the middle attacks on the RS.

    This requires the client =
to know what the RS URI is before retrieving the information on the AS =
Configuration.

    The proposal Mike and I have been working on requires the =
client to have a notion of what API it is looking for and retrieve the =
.well-known file for that API from the issuer.   That allows a =
protocol like Connect to register its own config file that can point to =
the RS.   

    If the API specific well known is not available the client =
can try the default oauth-server one.

    That then allows us to deal with =
restricting where AT are presented as part of the protocol rather then =
dragging discovery in as a requirement.

    In my opinion the resource the token is =
targeted to should be separated from the scope and returned as part of =
the meta-data about the AT along with scopes granted and expiry time. =
  We should also have a input parameter for resources so that a =
client can restrict tokens issued to a subset of the ones granted by the =
refresh token.   It would then also be possible to ask a AS for a =
token for a unregistered RS and have the AS produce a JWT access token =
with the resource as an audience if policy allows.

    That however was =
supposed to be dealt with as part of the mixed up client set of =
mitigations.  
    In that the goal was to =
mitigate the attacks by returning meta-data about the tokens, and not to =
require discovery.

    We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_i=
d=E2=80=9D for the code, and I intend to discuss at the F2F returning =
resource for AT as well.

    Those mitigate the attack.  

    I will continue to resist mixing up =
discovery of configuration meta-data with mitigation of the =
attacks.

    We =
return meta-data about the tokens now, because AT are opaque to the =
client, we neglected to include some of the information for the client =
needs to be secure.   We just need to add that in to the existing =
flows.

    While =
Phil=E2=80=99s proposal is easier for the AS to implement as an add on, =
it puts more of a burden on the client needing to potentially change how =
it stores the relationships between AS and RS to prevent compromise, I =
think the solution should be biased towards simplicity on the client =
side.

    If we =
return the resources as part of the existing meta data the client checks =
that against the resource it intends to send the token to and if it is =
not in the list then it can=E2=80=99t send the token.  Simple check =
every time it gets a new AT, no optionality.

    I am not saying anything new Nat has =
been advocating basically this for some time, and dis submit a draft. =
  I prefer to return the info in the existing format rather than as =
link headers,  but that is the largest difference between what Nat =
and I are saying with respect to resource.

    That is the core of my problem with =
Phil=E2=80=99s draft.

    I guess we will need to have a long conversation in =
BA.

    Regards
    John B.


    =

--Apple-Mail=_6C392291-F9D4-41A3-B5CC-E95A590E2B5D--

--Apple-Mail=_6AE33B0B-D97B-49F6-9D06-EBC61397CA42
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTQwMTQ1MjZaMCMGCSqGSIb3DQEJBDEWBBSDbjsQF6nomNzwBHP2HIJ2
CA7v/DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQB8k8Bnpu0/BVoh8x7i6O6D4FntBPArGo2XA4MXhaLWo78Gx+7H1UXG
MNOkl4DDLtgi1jz1q8SA1zR3Zw/m8ZllE2MyAYpV6bT+A+D1Sg7MbutS+xrR4JeGRnybEiWDyuy3
Rtz/096Its453dYMBqGn/r52XR3td2N5m/QYrvFU2smeFGjIRSl6jkwN0hhj85sJ60ZkIG023Z33
mEfoUwoE70MLnp6rqaW4hBQEFHkpIquTc2wUXLXLYu6Cgdayy4V3MWOJOAw065IMOXLKKE6a9qFR
chK6J1r16f+KP33nQcwwCMmE3AgQu7c5yTdInejZUqIHW4/CveaFztgJwLIRAAAAAAAA
--Apple-Mail=_6AE33B0B-D97B-49F6-9D06-EBC61397CA42--


From nobody Sun Mar 13 19:36:39 2016
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 0692312D914 for ; Sun, 13 Mar 2016 19:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 7e4ID1Fp-cQd for ; Sun, 13 Mar 2016 19:36:35 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 8158612D913 for ; Sun, 13 Mar 2016 19:36:35 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id n186so88454067wmn.1 for ; Sun, 13 Mar 2016 19:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n4aMwiT7yPpGO5BnvkkIyr6+v7hdGa9w8NzJ3D6X8yI=; b=LYySOhOnEX3XkCMSUvBxQCdB5hDx955BsNO2/HO1WKHvUBGivaUeIaBR791SgjbRnj ZDP6AhLdhocSc/yQPnhYZk/bqD+ERy3HSx8FBifVmfpk4LCtyFTuvIrt3J7FsAXiDd6d msjojXn5YMZ3PAPU2qChj9YgTAE0/+p2iSfkA9aHg3J8M+L+2+8whf0FfIEBJGSgB8cp B7crXldKWG4Ba+zv3Xcnki9lxy0T/sVJO6ZFZ5eRRuJS2yJDP6izD0ZUCI62VMr/aU3k YSzCrTftWVR3F6BPwk3NjJht7WjXrxIg63j9ANeKXnKN19Y0U/AjlojtLfJjkIgttAlY YMJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n4aMwiT7yPpGO5BnvkkIyr6+v7hdGa9w8NzJ3D6X8yI=; b=Aok+qCX4rW0xkw+QZwZfZc4CYfOcAzD5/BvNU5tPVocc3xQMTbIIdeJZBIoqueJDT3 42ObYrdhG89PfqdPpGG/1f37XxGiOhXmd4nfLmSOPA3AK9QFaqG29xtuEK8lhS+lYh0R C0S59lbUNrzdi3IUkCPV6iHk1WNt85Yr5aoTscMgtk9uAXlrQfCrmRMBAxFd7NJpG0i3 Ethl3XrRDI/l+6oErVIdn9v95T4jhgKuhiBuqchJSlJzQiRzYh0h5jV9SizOxNc4SApb YIhJXc1rBnMDN8OW8zGui4SzxTfq4iAjsZn91awF+Kp+gNbkgGlrO7/dN/cFshTbN4gn sW5Q==
X-Gm-Message-State: AD7BkJIy2rNj8IYDjZ31YitkZixqvmNgylFIzB1a8kbctFObmd7e53Iq5kaUhc3/CPTZc8c3xXBcD5eUMtCqJA==
X-Received: by 10.194.84.66 with SMTP id w2mr21579167wjy.6.1457922994082; Sun, 13 Mar 2016 19:36:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.211.206 with HTTP; Sun, 13 Mar 2016 19:36:14 -0700 (PDT)
In-Reply-To: <56E4BC4D.9000806@mit.edu>
References:  <56E4BC4D.9000806@mit.edu>
From: Andrea Ceccanti 
Date: Mon, 14 Mar 2016 10:36:14 +0800
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7bb04faa2c1af6052df92635
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 02:36:38 -0000

--047d7bb04faa2c1af6052df92635
Content-Type: text/plain; charset=UTF-8

Hello,

interesting thread, thanks.

Assuming the scopes are included in the token, the main purpose of call to
the introspection endpoint is to ensure
the token hasn't been revoked?

We are considering a deployment where a RS can trust multiple AS, and
having a JWT as access token, with
issuer, scopes and basic identity information included seems to solve our
issues.

Thanks,
Andrea




2016-03-13 9:03 GMT+08:00 Justin Richer :

> What we've done in deployments is to combine JWT and introspection. You
> have all of your servers issue signed JWTs that include the "iss" (issuer)
> in the body, signed with the key of the AS. The tokens also include a
> random "jti" field. The RS submits the token to the introspection endpoint
> of the server identified in "iss", but only after validating the signature
> and other basic bits of information. If the introspection call comes back
> positive (and with the right scope, client, and resource owner
> information), the resource is served.
>
>  -- Justin
>
>
> On 3/11/2016 10:02 PM, Takahiko Kawasaki wrote:
>
> Hello,
>
> I have a question.
>
> If there exist multiple authorization servers that can issue access tokens
> for one resource server, when the resource server receives an access token
> from a client application, as the first step, the resource server has to
> determine which authorization server to use for access token introspection.
>
> Is there any standard way to determine which authorization server to use?
>
> There may be several ways, for example:
>
> (1) Embed information about the access token issuer in the access token.
> (2) Add a request parameter to identify the access token issuer.
> (3) Separate protected resource endpoints for each authorization server.
>
> If there is a standard way, I'd like to know it.
>
> Best Regards,
> Takahiko Kawasaki
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--047d7bb04faa2c1af6052df92635
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Hello,

    interesting thread, thanks.

    Assuming the scopes are included in the token, the mai=
n purpose of call to the introspection endpoint is to ensure
    the =
token hasn't been revoked?

    We are considering =
a deployment where a RS can trust multiple AS, and having a JWT as access t=
oken, with
    issuer, scopes and basic identity information included=
 seems to solve our issues.

    Thanks,
    Andr=
ea




    2016-03-13 9:03 GMT+08:00 Justin =
Richer <jricher@mit.edu>:
    
 =20
   =20
 =20
  
    
    What we've done in deployments is to combine JWT and introspection.
    You have all of your servers issue signed JWTs that include the
    "iss" (issuer) in the body, signed with the key of the AS. Th=
e
    tokens also include a random "jti" field. The RS submits the =
token
    to the introspection endpoint of the server identified in "iss&quo=
t;, but
    only after validating the signature and other basic bits of
    information. If the introspection call comes back positive (and with
    the right scope, client, and resource owner information), the
    resource is served.
    
    
    
    =C2=A0-- Justin

    
    
    
    
    On 3/11/2016 10:02 PM, Takahiko
      Kawasaki wrote:
    
    
    
    
    
     =20
      
    
        
    
          
    
            
    
              
    
                
    
                  
    
                    
    
                      
    
                        
    Hello,
    
                          
    
                        
    
                        I have a question.
    
                        
    
                        If there exist multiple authorization servers
                        that can issue access tokens for one resource
                        server, when the resource server receives an
                        access token from a client application, as the
                        first step, the resource server has to determine
                        which authorization server to use for access
                        token introspection.
    
                        
    
                      
    
                      Is there any standard way to determine which
                      authorization server to use?
    
                      
    
                    
    
                    There may be several ways, for example:
    
                    
    
                  
    
                  (1) Embed information about the access token issuer in
                  the access token.
    
                
    
                (2) Add a request parameter to identify the access token
                issuer.
    
              
    
              (3) Separate protected resource endpoints for each
              authorization server.
    
              
    
            
    
            If there is a standard way, I'd like to know it.
    
            
    
          
    
          Best Regards,
    
        
    
        Takahiko Kawasaki
    
        
    
      
    
      
    
      
    
      
    
      
    ___________________________________=
____________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  
    


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


    

--047d7bb04faa2c1af6052df92635--


From nobody Sun Mar 13 22:28:56 2016
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 A494312D94C for ; Sun, 13 Mar 2016 22:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 dO1uLqMG0qoX for ; Sun, 13 Mar 2016 22:28:51 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C66F12D7B3 for ; Sun, 13 Mar 2016 22:28:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Arb2p0w8zLa65RJFKxNCtjbFZBF+/Af7J53m/8H9UeM=; b=Ovk3f7c5sTGEd6soODL9fvRDtMs6h/W0Bk5fQ9/cMTFAZuNFFKA4hqH+THJdWMWpFnOZpH3WFlbk9WUhNbciMrvWmb1Ma9zB7b3/qQlyyXOPVmCISJ/XpNqUpvgDS9Kc/R+khDjluDxm6dj3OmrgQvDNJC9gQj0X7RovEeibQnQ=
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (TLS) id 15.1.427.16; Mon, 14 Mar 2016 05:28:48 +0000
Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0434.016; Mon, 14 Mar 2016 05:28:48 +0000
From: Mike Jones 
To: Phil Hunt 
Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
Thread-Index: AQHRfZM5R1Dffpld4kO9yCpVmTlXSZ9YXsIA
Date: Mon, 14 Mar 2016 05:28:48 +0000
Message-ID: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>
In-Reply-To: <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [74.119.161.41]
x-ms-office365-filtering-correlation-id: 2d4f8cc9-b3d3-423b-1de5-08d34bc9856d
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 5:4mihTRgampg44mOd5UGtS9vZ14qMKhRXirXG65WJreVx+8v2SrqF7yXWP9OsnTrKIk5yc0pgAJ5AjQu0BfQFr2pUJVOd29pUN/Bfq8M0HOab2WTehZYJM4qBgFUfXg6+29C7skmbwyMyRp41YmDqKQ==; 24:yhKnN2niNId7sSJPxCxGsYs/C4vRVB+UlJB3I1AGLooCjvvDtsJp0q6CsrBOPomvBzrQMwPAisbj4GrN3+/SUWTJCBbZWGgi4Vyc6S4kj9I=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; 
x-forefront-prvs: 0881A7A935
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(51414003)(52604005)(377454003)(377424004)(2420400007)(2950100001)(6116002)(5003600100002)(3660700001)(15650500001)(10710500007)(4326007)(92566002)(2906002)(110136002)(3280700002)(74316001)(3846002)(7110500001)(5008740100001)(19625215002)(586003)(50986999)(790700001)(102836003)(81166005)(33656002)(2900100001)(189998001)(5002640100001)(10290500002)(8990500004)(19300405004)(10400500002)(5005710100001)(15395725005)(15975445007)(77096005)(16236675004)(122556002)(106116001)(99286002)(86362001)(14971765001)(230783001)(19580395003)(87936001)(19580405001)(54356999)(561944003)(76576001)(66066001)(10090500001)(1220700001)(1096002)(76176999)(11100500001)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB164556D8BE843B6C141A66E6F5880SN1PR0301MB1645_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2016 05:28:48.5746 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 05:28:54 -0000

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

VGhhbmtzIGZvciBwb3N0aW5nIHRoaXMsIFBoaWwuICBJdCBwcm92aWRlcyBhIGNvbmNyZXRlIGV4
YW1wbGUgb2YgYSB3YXkgdGhhdCBwcm90ZWN0ZWQgcmVzb3VyY2UgZGlzY292ZXJ5IGNvdWxkIGJl
IGFkZGVkIHRvIGF1dGhvcml6YXRpb24gc2VydmVyIG1ldGFkYXRhIGRpc2NvdmVyeSwgYW5kIGFz
IHN1Y2gsIHNob3VsZCBwcm92aWRlIHVzZWZ1bCBpbnB1dCBmb3Igd29ya2luZyBncm91cCBkaXNj
dXNzaW9ucyBvbiB0aGlzIHRvcGljLiAgSXTigJlzIGFsd2F5cyBncmVhdCB3aGVuIHNvbWVvbmUg
dGFrZXMgdGhlIHRpbWUgdG8gd3JpdGUgYW4gYWN0dWFsIGRyYWZ0IHRoYXQgY2FuIGJlIGV4YW1p
bmVkIGFuZCBpbXBsZW1lbnRlZCwgYW5kIEkgYXBwcmVjaWF0ZSB5b3UgZG9pbmcgdGhhdC4NCg0K
VGhlIGNvbnRlbnQgb2YgeW91ciBkcmFmdCBwb2ludHMgb3V0IHRoYXQgdGhlcmUgYXBwZWFycyB0
byBiZSBjb21wbGV0ZSBhZ3JlZW1lbnQgb24gd2hhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg
bWV0YWRhdGEgZm9ybWF0IHNob3VsZCBiZSwgd2hpY2ggaXMgZ3JlYXQhICBJ4oCZbGwgbm90ZSB0
aGF0IFNlY3Rpb24gMyBvZiBkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0wMCB0aXRsZWQg
4oCcQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTWV0YWRhdGHigJ0gaXMgYW4gZXhhY3QgY29weSBvZiBT
ZWN0aW9uIDIgb2YgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDEgKHdpdGggdGhlIHNhbWUg
dGl0bGUpLCBtb2R1bG8gYXBwbHlpbmcgYSBjb3JyZWN0aW9uIHN1Z2dlc3RlZCBieSB0aGUgd29y
a2luZyBncm91cC4gIFRvIG1lIHRoaXMgc3VnZ2VzdHMgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXIgbWV0YWRhdGEgZGVmaW5pdGlvbnMgaW4gZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zlcnkg
KHdoaWNoIGlzIG5vdyB0aGUgd2hvbGUgbm9ybWF0aXZlIGNvbnRlbnQgb2YgdGhlIGRyYWZ0KSBh
cmUgY2xlYXJseSByZWFkeSBmb3Igc3RhbmRhcmRpemF0aW9uLCBzaW5jZSBldmVuIHlvdXIgYWx0
ZXJuYXRpdmUgcHJvcG9zYWwgaW5jbHVkZXMgdGhlbSB2ZXJiYXRpbS4NCg0KUmVhZGluZyB5b3Vy
IGRyYWZ0LCB0aGUgcHJvYmxlbSBJIGhhdmUgd2l0aCBpdCBpcyB0aGF0IHlvdSBhcmUgcmV0dXJu
aW5nIHRoZSBBUyBtZXRhZGF0YSBvbmx5IGFzIGEgV2ViRmluZ2VyIHJlc3BvbnNlLCByYXRoZXIg
dGhhbiBhcyBhbiBodHRwcy1wcm90ZWN0ZWQgcmVzb3VyY2UgcHVibGlzaGVkIGJ5IHRoZSBhdXRo
b3JpemF0aW9uIHNlcnZlci4gIFRoZSBjaG9pY2UgdG8gb25seSByZXR1cm4gdGhpcyB2aWEgV2Vi
RmluZ2VyIG1ha2VzIHlvdXIgZHJhZnQgaW5jb21wYXRpYmxlIHdpdGggbW9zdCBkZXBsb3llZCBp
bXBsZW1lbnRhdGlvbnMgb2YgT0F1dGggbWV0YWRhdGEsIGluY2x1ZGluZyB0aGUgMjIgaW1wbGVt
ZW50YXRpb25zIHVzaW5nIGl0IGxpc3RlZCBhdCBodHRwOi8vb3BlbmlkLm5ldC9jZXJ0aWZpY2F0
aW9uLyAoc2VlIHRoZSDigJxPUCBDb25maWfigJ0gY29sdW1uIGluIHRoZSB0YWJsZSkgYW5kIE9B
dXRoIDIuMCBsaWJyYXJpZXMgc3VjaCBhcyBNaWNyb3NvZnTigJlzIOKAnEFEQUzigJ0gbGlicmFy
eSwgd2hpY2ggdXNlcyB0aGUgbWV0YWRhdGEgcGF0aCBmb3IgY2xpZW50IGNvbmZpZ3VyYXRpb24u
ICBXaXRob3V0IGhhdmluZyBBU3MgcHJvdmlkZSB0aGUgbWV0YWRhdGEgYXMgYW4gaHR0cHMtcHJv
dGVjdGVkIHJlc291cmNlLCBpbXBsZW1lbnRhdGlvbnMgc3VjaCBhcyBBREFMIGNhbuKAmXQgdXNl
IGl0IGZvciBjbGllbnQgY29uZmlndXJhdGlvbiBhcyB0aGUgY3VycmVudGx5IGRvLg0KDQpUaGVy
ZWZvcmUsIEkgd291bGQgcmVxdWVzdCB0aGF0IHlvdSBtYWtlIHRoZXNlIG1pbm9yIHJldmlzaW9u
cyB0byB5b3VyIGRyYWZ0IGFuZCByZXB1Ymxpc2gsIHNvIGFzIHRvIHByb3ZpZGUgYSB1bmlmaWVk
IHdheSBmb3J3YXJkIHRoYXQgaXMgY29tcGF0aWJsZSB3aXRoIGFsbCBrbm93biBleGlzdGluZyBP
QXV0aCBEaXNjb3ZlcnkgZGVwbG95bWVudHM6DQoNCjEuICAgICAgIE1vZGlmeSB5b3VyIHNlY3Rp
b24gMiDigJxBdXRob3JpemF0aW9uIFNlcnZlciBXZWJGaW5nZXIgRGlzY292ZXJ54oCdIHRvIGhh
dmUgdGhlIFdlYkZpbmdlciByZXF1ZXN0IHJldHVybiB0aGUgaXNzdWVyIGlkZW50aWZpZXIgZm9y
IHRoZSBBUyBhcyB0aGUg4oCcV2ViRmluZ2VyIOKAnHJlbOKAnSB2YWx1ZSwgcmF0aGVyIHRoYW4g
cmV0dXJuaW5nIHRoZSBtZXRhZGF0YSB2YWx1ZXMgYnkgdmFsdWUgYXMgdGhlIOKAnHByb3BlcnRp
ZXPigJ0gdmFsdWUuDQoNCjIuICAgICAgIFJlZmVyZW5jZSB0aGUgbWV0YWRhdGEgZGVmaW5pdGlv
bnMgZnJvbSBTZWN0aW9uIDIgb2YgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnksIHJhdGhlciB0
aGFuIGR1cGxpY2F0aW5nIHRoZW0gaW4geW91ciBTZWN0aW9uIDMuDQoNClRoYXQgd291bGQgaGF2
ZSB0aGUgYWR2YW50YWdlIG9mIHBhcmluZyB5b3VyIGRyYWZ0IGRvd24gdG8gb25seSB0aGUgbmV3
IHRoaW5ncyB0aGF0IGl0IHByb3Bvc2VzLCBlbmFibGluZyB0aGVtIHRvIGJlIG1vcmUgY2xlYXJs
eSB1bmRlcnN0b29kIGFuZCBldmFsdWF0ZWQgb24gdGhlaXIgb3duIG1lcml0cy4gIEkgbG9vayBm
b3J3YXJkIHRvIHRoZSBkaXNjdXNzaW9ucyBvZiB3YXlzIG9mIHBlcmZvcm1pbmcgYWRkaXRpb25h
bCBraW5kcyBvZiBPQXV0aCBkaXNjb3ZlcnksIGFuZCBjb25zaWRlciB5b3VyIGRyYWZ0IGEgdmFs
dWFibGUgaW5wdXQgdG8gdGhvc2UgZGlzY3Vzc2lvbnMuDQoNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN
aWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogU3VuZGF5LCBNYXJjaCAxMywgMjAxNiA2OjQ1IFBN
DQpUbzogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp
b24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwLnR4dA0KDQpBcyBJIGhhdmUg
dG9sZCBQaGlsIG9mZiBsaXN0Lg0KDQpEaXNjb3ZlcnkgaXMgdGhlIHdyb25nIHBsYWNlIHRvIHRy
eSBhbmQgcHJvdmlkZSBzZWN1cml0eSBhZ2FpbnN0IG1hbiBpbiB0aGUgbWlkZGxlIGF0dGFja3Mg
b24gdGhlIFJTLg0KDQpUaGlzIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8ga25vdyB3aGF0IHRoZSBS
UyBVUkkgaXMgYmVmb3JlIHJldHJpZXZpbmcgdGhlIGluZm9ybWF0aW9uIG9uIHRoZSBBUyBDb25m
aWd1cmF0aW9uLg0KDQpUaGUgcHJvcG9zYWwgTWlrZSBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBv
biByZXF1aXJlcyB0aGUgY2xpZW50IHRvIGhhdmUgYSBub3Rpb24gb2Ygd2hhdCBBUEkgaXQgaXMg
bG9va2luZyBmb3IgYW5kIHJldHJpZXZlIHRoZSAud2VsbC1rbm93biBmaWxlIGZvciB0aGF0IEFQ
SSBmcm9tIHRoZSBpc3N1ZXIuICAgVGhhdCBhbGxvd3MgYSBwcm90b2NvbCBsaWtlIENvbm5lY3Qg
dG8gcmVnaXN0ZXIgaXRzIG93biBjb25maWcgZmlsZSB0aGF0IGNhbiBwb2ludCB0byB0aGUgUlMu
DQoNCklmIHRoZSBBUEkgc3BlY2lmaWMgd2VsbCBrbm93biBpcyBub3QgYXZhaWxhYmxlIHRoZSBj
bGllbnQgY2FuIHRyeSB0aGUgZGVmYXVsdCBvYXV0aC1zZXJ2ZXIgb25lLg0KDQpUaGF0IHRoZW4g
YWxsb3dzIHVzIHRvIGRlYWwgd2l0aCByZXN0cmljdGluZyB3aGVyZSBBVCBhcmUgcHJlc2VudGVk
IGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIHJhdGhlciB0aGVuIGRyYWdnaW5nIGRpc2NvdmVyeSBp
biBhcyBhIHJlcXVpcmVtZW50Lg0KDQpJbiBteSBvcGluaW9uIHRoZSByZXNvdXJjZSB0aGUgdG9r
ZW4gaXMgdGFyZ2V0ZWQgdG8gc2hvdWxkIGJlIHNlcGFyYXRlZCBmcm9tIHRoZSBzY29wZSBhbmQg
cmV0dXJuZWQgYXMgcGFydCBvZiB0aGUgbWV0YS1kYXRhIGFib3V0IHRoZSBBVCBhbG9uZyB3aXRo
IHNjb3BlcyBncmFudGVkIGFuZCBleHBpcnkgdGltZS4gICBXZSBzaG91bGQgYWxzbyBoYXZlIGEg
aW5wdXQgcGFyYW1ldGVyIGZvciByZXNvdXJjZXMgc28gdGhhdCBhIGNsaWVudCBjYW4gcmVzdHJp
Y3QgdG9rZW5zIGlzc3VlZCB0byBhIHN1YnNldCBvZiB0aGUgb25lcyBncmFudGVkIGJ5IHRoZSBy
ZWZyZXNoIHRva2VuLiAgIEl0IHdvdWxkIHRoZW4gYWxzbyBiZSBwb3NzaWJsZSB0byBhc2sgYSBB
UyBmb3IgYSB0b2tlbiBmb3IgYSB1bnJlZ2lzdGVyZWQgUlMgYW5kIGhhdmUgdGhlIEFTIHByb2R1
Y2UgYSBKV1QgYWNjZXNzIHRva2VuIHdpdGggdGhlIHJlc291cmNlIGFzIGFuIGF1ZGllbmNlIGlm
IHBvbGljeSBhbGxvd3MuDQoNClRoYXQgaG93ZXZlciB3YXMgc3VwcG9zZWQgdG8gYmUgZGVhbHQg
d2l0aCBhcyBwYXJ0IG9mIHRoZSBtaXhlZCB1cCBjbGllbnQgc2V0IG9mIG1pdGlnYXRpb25zLg0K
SW4gdGhhdCB0aGUgZ29hbCB3YXMgdG8gbWl0aWdhdGUgdGhlIGF0dGFja3MgYnkgcmV0dXJuaW5n
IG1ldGEtZGF0YSBhYm91dCB0aGUgdG9rZW5zLCBhbmQgbm90IHRvIHJlcXVpcmUgZGlzY292ZXJ5
Lg0KDQpXZSBpbnRlbmQgdG8gcmV0dXJuIOKAnGlzc+KAnSBhbmQg4oCcY2xlaW50X2lk4oCdIGZv
ciB0aGUgY29kZSwgYW5kIEkgaW50ZW5kIHRvIGRpc2N1c3MgYXQgdGhlIEYyRiByZXR1cm5pbmcg
cmVzb3VyY2UgZm9yIEFUIGFzIHdlbGwuDQoNClRob3NlIG1pdGlnYXRlIHRoZSBhdHRhY2suDQoN
Ckkgd2lsbCBjb250aW51ZSB0byByZXNpc3QgbWl4aW5nIHVwIGRpc2NvdmVyeSBvZiBjb25maWd1
cmF0aW9uIG1ldGEtZGF0YSB3aXRoIG1pdGlnYXRpb24gb2YgdGhlIGF0dGFja3MuDQoNCldlIHJl
dHVybiBtZXRhLWRhdGEgYWJvdXQgdGhlIHRva2VucyBub3csIGJlY2F1c2UgQVQgYXJlIG9wYXF1
ZSB0byB0aGUgY2xpZW50LCB3ZSBuZWdsZWN0ZWQgdG8gaW5jbHVkZSBzb21lIG9mIHRoZSBpbmZv
cm1hdGlvbiBmb3IgdGhlIGNsaWVudCBuZWVkcyB0byBiZSBzZWN1cmUuICAgV2UganVzdCBuZWVk
IHRvIGFkZCB0aGF0IGluIHRvIHRoZSBleGlzdGluZyBmbG93cy4NCg0KV2hpbGUgUGhpbOKAmXMg
cHJvcG9zYWwgaXMgZWFzaWVyIGZvciB0aGUgQVMgdG8gaW1wbGVtZW50IGFzIGFuIGFkZCBvbiwg
aXQgcHV0cyBtb3JlIG9mIGEgYnVyZGVuIG9uIHRoZSBjbGllbnQgbmVlZGluZyB0byBwb3RlbnRp
YWxseSBjaGFuZ2UgaG93IGl0IHN0b3JlcyB0aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIEFTIGFu
ZCBSUyB0byBwcmV2ZW50IGNvbXByb21pc2UsIEkgdGhpbmsgdGhlIHNvbHV0aW9uIHNob3VsZCBi
ZSBiaWFzZWQgdG93YXJkcyBzaW1wbGljaXR5IG9uIHRoZSBjbGllbnQgc2lkZS4NCg0KSWYgd2Ug
cmV0dXJuIHRoZSByZXNvdXJjZXMgYXMgcGFydCBvZiB0aGUgZXhpc3RpbmcgbWV0YSBkYXRhIHRo
ZSBjbGllbnQgY2hlY2tzIHRoYXQgYWdhaW5zdCB0aGUgcmVzb3VyY2UgaXQgaW50ZW5kcyB0byBz
ZW5kIHRoZSB0b2tlbiB0byBhbmQgaWYgaXQgaXMgbm90IGluIHRoZSBsaXN0IHRoZW4gaXQgY2Fu
4oCZdCBzZW5kIHRoZSB0b2tlbi4gIFNpbXBsZSBjaGVjayBldmVyeSB0aW1lIGl0IGdldHMgYSBu
ZXcgQVQsIG5vIG9wdGlvbmFsaXR5Lg0KDQpJIGFtIG5vdCBzYXlpbmcgYW55dGhpbmcgbmV3IE5h
dCBoYXMgYmVlbiBhZHZvY2F0aW5nIGJhc2ljYWxseSB0aGlzIGZvciBzb21lIHRpbWUsIGFuZCBk
aXMgc3VibWl0IGEgZHJhZnQuICAgSSBwcmVmZXIgdG8gcmV0dXJuIHRoZSBpbmZvIGluIHRoZSBl
eGlzdGluZyBmb3JtYXQgcmF0aGVyIHRoYW4gYXMgbGluayBoZWFkZXJzLCAgYnV0IHRoYXQgaXMg
dGhlIGxhcmdlc3QgZGlmZmVyZW5jZSBiZXR3ZWVuIHdoYXQgTmF0IGFuZCBJIGFyZSBzYXlpbmcg
d2l0aCByZXNwZWN0IHRvIHJlc291cmNlLg0KDQpUaGF0IGlzIHRoZSBjb3JlIG9mIG15IHByb2Js
ZW0gd2l0aCBQaGls4oCZcyBkcmFmdC4NCg0KSSBndWVzcyB3ZSB3aWxsIG5lZWQgdG8gaGF2ZSBh
IGxvbmcgY29udmVyc2F0aW9uIGluIEJBLg0KDQpSZWdhcmRzDQpKb2huIEIuDQoNCk9uIE1hciAx
MywgMjAxNiwgYXQgODoxMiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWls
dG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KVGhpcyBkcmFmdCBpcyBhIHByb3Bv
c2VkIGFsdGVybmF0ZSBwcm9wb3NhbCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnkuICBB
cyBzdWNoLCBpdCBjb250YWlucyB0aGUgc2FtZSByZWdpc3RyeSBmb3IgT0F1dGggQ29uZmlnIE1l
dGFkYXRhIGFzIHRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCBib3RoIHNvbHV0aW9ucyBhcmUgbm90
IHJlcXVpcmVkLCBvciBkZXBlbmRpbmcgb24gV0cgZGlzY3Vzc2lvbiB0aGV5IHdpbGwgYmUgbWVy
Z2VkLiBUaGUgaW50ZW50IGlzIHRvIHByb3ZpZGUgYSBzaW1wbGUgY29tcGxldGUgZHJhZnQgZm9y
IGNvbnNpZGVyYXRpb24uDQoNCkhvdyBpdCB3b3Jrcy4uLg0KR2l2ZW4gdGhhdCBhIGNsaWVudCBo
YXMgcHJldmlvdXNseSBkaXNjb3ZlcmVkIGFuIE9BdXRoIHByb3RlY3RlZCByZXNvdXJjZSwgdGhl
IGJvdW5kIGNvbmZpZ3VyYXRpb24gbWV0aG9kIGFsbG93cyBhIGNsaWVudCB0byByZXR1cm4gdGhl
IGNvbmZpZ3VyYXRpb24gZm9yIGFuIG9hdXRoIGF1dGhvcml6YXRpb24gc2VydmVyIHRoYXQgY2Fu
IGlzc3VlIHRva2VucyBmb3IgdGhlIHJlc291cmNlIFVSSSBzcGVjaWZpZWQgYnkgdGhlIGNsaWVu
dC4gIFRoZSBBUyBpcyBub3QgcmVxdWlyZWQgdG8gYmUgaW4gdGhlIHNhbWUgZG9tYWluLiAgVGhl
IEFTIGlzIGhvd2V2ZXIgcmVxdWlyZWQgdG8ga25vdyBpZiBpdCBjYW4gaXNzdWUgdG9rZW5zIGZv
ciBhIHJlc291cmNlIHNlcnZpY2UgKHdoaWNoIHByZXN1bWVzIHNvbWUgYWdyZWVtZW50IGV4aXN0
cyBvbiB0b2tlbnMgZXRjKS4NCg0KVGhlIGRyYWZ0IGRvZXMgbm90IHJlcXVpcmUgdGhhdCB0aGUg
cmVzb3VyY2UgZXhpc3QgKGUuZy4gZm9yIHVuY29uZmlndXJlZCBvciBuZXcgdXNlciBiYXNlZCBy
ZXNvdXJjZXMpLiBJdCBvbmx5IHJlcXVpcmVzIHRoYXQgdGhlIEFTIHNlcnZpY2UgcHJvdmlkZXIg
YWdyZWVzIGl0IGNhbiBpc3N1ZSB0b2tlbnMuDQoNCkZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2
ZSwgcmV0dXJuaW5nIHRoZSBPQXV0aCBzZXJ2aWNlIGNvbmZpZ3VyYXRpb24gZm9yIGEgc3BlY2lm
aWVkIHJlc291cmNlIFVSSSBzZXJ2ZXMgdG8gY29uZmlybSB0aGUgY2xpZW50IGlzIGluIHBvc3Nl
c3Npb24gb2YgYSB2YWxpZCByZXNvdXJjZSBVUkkgZW5zdXJpbmcgdGhlIGNsaWVudCBoYXMgcmVj
ZWl2ZWQgYSB2YWxpZCBzZXQgb2YgZW5kcG9pbnRzIGZvciB0aGUgcmVzb3VyY2UgYW5kIHRoZSBh
c3NvY2lhdGVkIG9hdXRoIHNlcnZpY2VzLg0KDQpJIHByb3Bvc2UgdGhhdCB0aGUgV0cgY29uc2lk
ZXIgdGhlIGFsdGVybmF0ZSBkcmFmdCBjYXJlZnVsbHkgYXMgd2VsbCBhcyBvdGhlciBzdWJtaXNz
aW9ucyBhbmQgZXZhbHVhdGUgdGhlIGJyb2FkZXIgZGlzY292ZXJ5IHByb2JsZW0gYmVmb3JlIHBy
b2NlZWRpbmcgd2l0aCBXR0xDIG9uIE9BdXRoIERpc2NvdmVyeS4NCg0KVGhhbmtzIQ0KDQpQaGls
DQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRl
cGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y
YWNsZS5jb20+DQoNCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogaW50ZXJu
ZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtYm91bmQt
Y29uZmlnLTAwLnR4dA0KRGF0ZTogTWFyY2ggMTMsIDIwMTYgYXQgMzo1MzozNyBQTSBQRFQNClRv
OiAiUGhpbCBIdW50IiA8cGhpbC5odW50QHlhaG9vLmNvbTxtYWlsdG86cGhpbC5odW50QHlhaG9v
LmNvbT4+LCAiQW50aG9ueSBOYWRhbGluIiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0
b255bmFkQG1pY3Jvc29mdC5jb20+PiwgIlRvbnkgTmFkYWxpbiIgPHRvbnluYWRAbWljcm9zb2Z0
LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9m
IEktRCwgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAudHh0DQpoYXMgYmVlbiBzdWNj
ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBoaWwgSHVudCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiBy
ZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgICBkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNv
bmZpZw0KUmV2aXNpb246ICAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgICAgIE9BdXRoIDIu
MCBCb3VuZCBDb25maWd1cmF0aW9uIExvb2t1cA0KRG9jdW1lbnQgZGF0ZTogICAgICAgICAgMjAx
Ni0wMy0xMw0KR3JvdXA6ICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6
ICAgICAgICAgICAgICAyMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0wMC50eHQNClN0YXR1
czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odW50LW9h
dXRoLWJvdW5kLWNvbmZpZy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDANCg0KDQpBYnN0cmFjdDoNCiAg
VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgb2Yg
YW4gT0F1dGggMi4wDQogIHByb3RlY3RlZCByZXNvdXJjZSBzZXJ2aWNlIHRvIG9idGFpbiB0aGUg
Y29uZmlndXJhdGlvbiBkZXRhaWxzIG9mIGFuDQogIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIHNl
cnZlciB0aGF0IGlzIGNhcGFibGUgb2YgYXV0aG9yaXppbmcgYWNjZXNzDQogIHRvIGEgc3BlY2lm
aWMgcmVzb3VyY2Ugc2VydmljZS4gIFRoZSBpbmZvcm1hdGlvbiBpbmNsdWRlcyB0aGUgT0F1dGgN
CiAgMi4wIGNvbXBvbmVudCBlbmRwb2ludCBsb2NhdGlvbiBVUklzIGFuZCBhcyB3ZWxsIGFzIGF1
dGhvcml6YXRpb24NCiAgc2VydmVyIGNhcGFiaWxpdGllcy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUg
dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi
bWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs
ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYg
U2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll
dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo
DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz
IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv
bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN
CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxl
LW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHls
ZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K
QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjgwNDc3MjM2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk
Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyODE1NjAxMzAgNjc2OTg3MDMgNjc2OTg3MTMgNjc2
OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3
MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg
bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGww
OmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s
b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0
ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy
Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGFua3MgZm9yIHBv
c3RpbmcgdGhpcywgUGhpbC4mbmJzcDsgSXQgcHJvdmlkZXMgYSBjb25jcmV0ZSBleGFtcGxlIG9m
IGEgd2F5IHRoYXQgcHJvdGVjdGVkIHJlc291cmNlIGRpc2NvdmVyeSBjb3VsZCBiZSBhZGRlZCB0
byBhdXRob3JpemF0aW9uIHNlcnZlciBtZXRhZGF0YSBkaXNjb3ZlcnksDQogYW5kIGFzIHN1Y2gs
IHNob3VsZCBwcm92aWRlIHVzZWZ1bCBpbnB1dCBmb3Igd29ya2luZyBncm91cCBkaXNjdXNzaW9u
cyBvbiB0aGlzIHRvcGljLiZuYnNwOyBJdOKAmXMgYWx3YXlzIGdyZWF0IHdoZW4gc29tZW9uZSB0
YWtlcyB0aGUgdGltZSB0byB3cml0ZSBhbiBhY3R1YWwgZHJhZnQgdGhhdCBjYW4gYmUgZXhhbWlu
ZWQgYW5kIGltcGxlbWVudGVkLCBhbmQgSSBhcHByZWNpYXRlIHlvdSBkb2luZyB0aGF0LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIGNvbnRlbnQgb2YgeW91
ciBkcmFmdCBwb2ludHMgb3V0IHRoYXQgdGhlcmUgYXBwZWFycyB0byBiZSBjb21wbGV0ZSBhZ3Jl
ZW1lbnQgb24gd2hhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWV0YWRhdGEgZm9ybWF0IHNo
b3VsZCBiZSwgd2hpY2ggaXMgZ3JlYXQhJm5ic3A7DQogSeKAmWxsIG5vdGUgdGhhdCBTZWN0aW9u
IDMgb2YgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAgdGl0bGVkIOKAnEF1dGhvcml6
YXRpb24gU2VydmVyIE1ldGFkYXRh4oCdIGlzIGFuIGV4YWN0IGNvcHkgb2YgU2VjdGlvbiAyIG9m
IGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxICh3aXRoIHRoZSBzYW1lIHRpdGxlKSwgbW9k
dWxvIGFwcGx5aW5nIGEgY29ycmVjdGlvbiBzdWdnZXN0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAu
Jm5ic3A7IFRvIG1lIHRoaXMNCiBzdWdnZXN0cyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl
ciBtZXRhZGF0YSBkZWZpbml0aW9ucyBpbiBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeSAod2hp
Y2ggaXMgbm93IHRoZSB3aG9sZSBub3JtYXRpdmUgY29udGVudCBvZiB0aGUgZHJhZnQpIGFyZSBj
bGVhcmx5IHJlYWR5IGZvciBzdGFuZGFyZGl6YXRpb24sIHNpbmNlIGV2ZW4geW91ciBhbHRlcm5h
dGl2ZSBwcm9wb3NhbCBpbmNsdWRlcyB0aGVtIHZlcmJhdGltLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+UmVhZGluZyB5b3VyIGRyYWZ0LCB0aGUgcHJvYmxlbSBJ
IGhhdmUgd2l0aCBpdCBpcyB0aGF0IHlvdSBhcmUgcmV0dXJuaW5nIHRoZSBBUyBtZXRhZGF0YSBv
bmx5IGFzIGEgV2ViRmluZ2VyIHJlc3BvbnNlLCByYXRoZXIgdGhhbiBhcyBhbiBodHRwcy1wcm90
ZWN0ZWQgcmVzb3VyY2UNCiBwdWJsaXNoZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiZu
YnNwOyBUaGUgY2hvaWNlIHRvIG9ubHkgcmV0dXJuIHRoaXMgdmlhIFdlYkZpbmdlciBtYWtlcyB5
b3VyIGRyYWZ0IGluY29tcGF0aWJsZSB3aXRoIG1vc3QgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25z
IG9mIE9BdXRoIG1ldGFkYXRhLCBpbmNsdWRpbmcgdGhlIDIyIGltcGxlbWVudGF0aW9ucyB1c2lu
ZyBpdCBsaXN0ZWQgYXQNCjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L2NlcnRpZmljYXRpb24v
Ij5odHRwOi8vb3BlbmlkLm5ldC9jZXJ0aWZpY2F0aW9uLzwvYT4gKHNlZSB0aGUg4oCcT1AgQ29u
Zmln4oCdIGNvbHVtbiBpbiB0aGUgdGFibGUpIGFuZA0KPGEgbmFtZT0iX01haWxFbmRDb21wb3Nl
Ij5PQXV0aCAyLjAgbGlicmFyaWVzIHN1Y2ggYXMgTWljcm9zb2Z04oCZcyDigJxBREFM4oCdIGxp
YnJhcnksIHdoaWNoIHVzZXMgdGhlIG1ldGFkYXRhIHBhdGggZm9yIGNsaWVudCBjb25maWd1cmF0
aW9uLiZuYnNwOyBXaXRob3V0IGhhdmluZyBBU3MgcHJvdmlkZSB0aGUgbWV0YWRhdGEgYXMgYW4g
aHR0cHMtcHJvdGVjdGVkIHJlc291cmNlLCBpbXBsZW1lbnRhdGlvbnMgc3VjaCBhcyBBREFMIGNh
buKAmXQgdXNlIGl0IGZvciBjbGllbnQNCiBjb25maWd1cmF0aW9uIGFzIHRoZSBjdXJyZW50bHkg
ZG8uPG86cD48L286cD48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlcmVmb3JlLCBJIHdvdWxkIHJlcXVlc3Qg
dGhhdCB5b3UgbWFrZSB0aGVzZSBtaW5vciByZXZpc2lvbnMgdG8geW91ciBkcmFmdCBhbmQgcmVw
dWJsaXNoLCBzbyBhcyB0byBwcm92aWRlIGEgdW5pZmllZA0KIHdheSBmb3J3YXJkIHRoYXQgaXMg
Y29tcGF0aWJsZSB3aXRoIGFsbCBrbm93biBleGlzdGluZyBPQXV0aCBEaXNjb3ZlcnkgZGVwbG95
bWVudHM6PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy
YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x
Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PCFbaWYgIXN1cHBv
cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxzcGFuIHN0eWxlPSJtc28t
bGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48
L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+TW9k
aWZ5IHlvdXIgc2VjdGlvbiAyIOKAnEF1dGhvcml6YXRpb24gU2VydmVyIFdlYkZpbmdlciBEaXNj
b3ZlcnnigJ0gdG8gaGF2ZSB0aGUgV2ViRmluZ2VyIHJlcXVlc3QgcmV0dXJuIHRoZSBpc3N1ZXIg
aWRlbnRpZmllciBmb3IgdGhlIEFTIGFzIHRoZSDigJxXZWJGaW5nZXINCiDigJxyZWzigJ0gdmFs
dWUsIHJhdGhlciB0aGFuIHJldHVybmluZyB0aGUgbWV0YWRhdGEgdmFsdWVzIGJ5IHZhbHVlIGFz
IHRoZSDigJxwcm9wZXJ0aWVz4oCdIHZhbHVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt
c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVu
ZENvbXBvc2UiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy
MDYwIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250Ojcu
MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPlJlZmVyZW5jZSB0aGUgbWV0YWRhdGEgZGVmaW5pdGlvbnMgZnJv
bSBTZWN0aW9uIDIgb2YgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnksIHJhdGhlciB0aGFuIGR1
cGxpY2F0aW5nIHRoZW0gaW4geW91ciBTZWN0aW9uIDMuPG86cD48L286cD48L3NwYW4+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MjA2MCI+VGhhdCB3b3VsZCBoYXZlIHRoZSBhZHZhbnRhZ2Ugb2YgcGFyaW5nIHlvdXIgZHJhZnQg
ZG93biB0byBvbmx5IHRoZSBuZXcgdGhpbmdzIHRoYXQgaXQgcHJvcG9zZXMsIGVuYWJsaW5nIHRo
ZW0gdG8gYmUNCiBtb3JlIGNsZWFybHkgdW5kZXJzdG9vZCBhbmQgZXZhbHVhdGVkIG9uIHRoZWly
IG93biBtZXJpdHMuJm5ic3A7IEkgbG9vayBmb3J3YXJkIHRvIHRoZSBkaXNjdXNzaW9ucyBvZiB3
YXlzIG9mIHBlcmZvcm1pbmcgYWRkaXRpb25hbCBraW5kcyBvZiBPQXV0aCBkaXNjb3ZlcnksIGFu
ZCBjb25zaWRlciB5b3VyIGRyYWZ0IGEgdmFsdWFibGUgaW5wdXQgdG8gdGhvc2UgZGlzY3Vzc2lv
bnMuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4N
CjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJy
YWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAxMywgMjAxNiA2OjQ1IFBNPGJy
Pg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4N
CjxiPkNjOjwvYj4gb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1
bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkFzIEkgaGF2ZSB0b2xkIFBoaWwgb2ZmIGxpc3QuICZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGlzY292ZXJ5IGlz
IHRoZSB3cm9uZyBwbGFjZSB0byB0cnkgYW5kIHByb3ZpZGUgc2VjdXJpdHkgYWdhaW5zdCBtYW4g
aW4gdGhlIG1pZGRsZSBhdHRhY2tzIG9uIHRoZSBSUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyByZXF1aXJlcyB0aGUgY2xpZW50IHRv
IGtub3cgd2hhdCB0aGUgUlMgVVJJIGlzIGJlZm9yZSByZXRyaWV2aW5nIHRoZSBpbmZvcm1hdGlv
biBvbiB0aGUgQVMgQ29uZmlndXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb3Bvc2FsIE1pa2UgYW5kIEkgaGF2ZSBiZWVu
IHdvcmtpbmcgb24gcmVxdWlyZXMgdGhlIGNsaWVudCB0byBoYXZlIGEgbm90aW9uIG9mIHdoYXQg
QVBJIGl0IGlzIGxvb2tpbmcgZm9yIGFuZCByZXRyaWV2ZSB0aGUgLndlbGwta25vd24gZmlsZSBm
b3IgdGhhdCBBUEkgZnJvbSB0aGUgaXNzdWVyLiAmbmJzcDsgVGhhdCBhbGxvd3MgYSBwcm90b2Nv
bCBsaWtlIENvbm5lY3QgdG8gcmVnaXN0ZXIgaXRzIG93biBjb25maWcNCiBmaWxlIHRoYXQgY2Fu
IHBvaW50IHRvIHRoZSBSUy4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBBUEkgc3BlY2lmaWMgd2VsbCBrbm93
biBpcyBub3QgYXZhaWxhYmxlIHRoZSBjbGllbnQgY2FuIHRyeSB0aGUgZGVmYXVsdCBvYXV0aC1z
ZXJ2ZXIgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGF0IHRoZW4gYWxsb3dzIHVzIHRvIGRlYWwgd2l0aCByZXN0cmljdGluZyB3aGVy
ZSBBVCBhcmUgcHJlc2VudGVkIGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIHJhdGhlciB0aGVuIGRy
YWdnaW5nIGRpc2NvdmVyeSBpbiBhcyBhIHJlcXVpcmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBteSBvcGluaW9uIHRoZSByZXNv
dXJjZSB0aGUgdG9rZW4gaXMgdGFyZ2V0ZWQgdG8gc2hvdWxkIGJlIHNlcGFyYXRlZCBmcm9tIHRo
ZSBzY29wZSBhbmQgcmV0dXJuZWQgYXMgcGFydCBvZiB0aGUgbWV0YS1kYXRhIGFib3V0IHRoZSBB
VCBhbG9uZyB3aXRoIHNjb3BlcyBncmFudGVkIGFuZCBleHBpcnkgdGltZS4gJm5ic3A7IFdlIHNo
b3VsZCBhbHNvIGhhdmUgYSBpbnB1dCBwYXJhbWV0ZXIgZm9yIHJlc291cmNlcyBzbw0KIHRoYXQg
YSBjbGllbnQgY2FuIHJlc3RyaWN0IHRva2VucyBpc3N1ZWQgdG8gYSBzdWJzZXQgb2YgdGhlIG9u
ZXMgZ3JhbnRlZCBieSB0aGUgcmVmcmVzaCB0b2tlbi4gJm5ic3A7IEl0IHdvdWxkIHRoZW4gYWxz
byBiZSBwb3NzaWJsZSB0byBhc2sgYSBBUyBmb3IgYSB0b2tlbiBmb3IgYSB1bnJlZ2lzdGVyZWQg
UlMgYW5kIGhhdmUgdGhlIEFTIHByb2R1Y2UgYSBKV1QgYWNjZXNzIHRva2VuIHdpdGggdGhlIHJl
c291cmNlIGFzIGFuIGF1ZGllbmNlIGlmIHBvbGljeQ0KIGFsbG93cy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBob3dldmVyIHdhcyBz
dXBwb3NlZCB0byBiZSBkZWFsdCB3aXRoIGFzIHBhcnQgb2YgdGhlIG1peGVkIHVwIGNsaWVudCBz
ZXQgb2YgbWl0aWdhdGlvbnMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhhdCB0aGUgZ29hbCB3YXMgdG8gbWl0aWdhdGUgdGhl
IGF0dGFja3MgYnkgcmV0dXJuaW5nIG1ldGEtZGF0YSBhYm91dCB0aGUgdG9rZW5zLCBhbmQgbm90
IHRvIHJlcXVpcmUgZGlzY292ZXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBpbnRlbmQgdG8gcmV0dXJuIOKAnGlzc+KAnSBhbmQg4oCc
Y2xlaW50X2lk4oCdIGZvciB0aGUgY29kZSwgYW5kIEkgaW50ZW5kIHRvIGRpc2N1c3MgYXQgdGhl
IEYyRiByZXR1cm5pbmcgcmVzb3VyY2UgZm9yIEFUIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3NlIG1pdGlnYXRlIHRoZSBh
dHRhY2suICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JIHdpbGwgY29udGludWUgdG8gcmVzaXN0IG1peGluZyB1cCBkaXNjb3Zlcnkg
b2YgY29uZmlndXJhdGlvbiBtZXRhLWRhdGEgd2l0aCBtaXRpZ2F0aW9uIG9mIHRoZSBhdHRhY2tz
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X
ZSByZXR1cm4gbWV0YS1kYXRhIGFib3V0IHRoZSB0b2tlbnMgbm93LCBiZWNhdXNlIEFUIGFyZSBv
cGFxdWUgdG8gdGhlIGNsaWVudCwgd2UgbmVnbGVjdGVkIHRvIGluY2x1ZGUgc29tZSBvZiB0aGUg
aW5mb3JtYXRpb24gZm9yIHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgc2VjdXJlLiAmbmJzcDsgV2Ug
anVzdCBuZWVkIHRvIGFkZCB0aGF0IGluIHRvIHRoZSBleGlzdGluZyBmbG93cy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgUGhpbOKA
mXMgcHJvcG9zYWwgaXMgZWFzaWVyIGZvciB0aGUgQVMgdG8gaW1wbGVtZW50IGFzIGFuIGFkZCBv
biwgaXQgcHV0cyBtb3JlIG9mIGEgYnVyZGVuIG9uIHRoZSBjbGllbnQgbmVlZGluZyB0byBwb3Rl
bnRpYWxseSBjaGFuZ2UgaG93IGl0IHN0b3JlcyB0aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIEFT
IGFuZCBSUyB0byBwcmV2ZW50IGNvbXByb21pc2UsIEkgdGhpbmsgdGhlIHNvbHV0aW9uIHNob3Vs
ZA0KIGJlIGJpYXNlZCB0b3dhcmRzIHNpbXBsaWNpdHkgb24gdGhlIGNsaWVudCBzaWRlLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBy
ZXR1cm4gdGhlIHJlc291cmNlcyBhcyBwYXJ0IG9mIHRoZSBleGlzdGluZyBtZXRhIGRhdGEgdGhl
IGNsaWVudCBjaGVja3MgdGhhdCBhZ2FpbnN0IHRoZSByZXNvdXJjZSBpdCBpbnRlbmRzIHRvIHNl
bmQgdGhlIHRva2VuIHRvIGFuZCBpZiBpdCBpcyBub3QgaW4gdGhlIGxpc3QgdGhlbiBpdCBjYW7i
gJl0IHNlbmQgdGhlIHRva2VuLiAmbmJzcDtTaW1wbGUgY2hlY2sgZXZlcnkgdGltZSBpdCBnZXRz
IGEgbmV3IEFULA0KIG5vIG9wdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzYXlpbmcgYW55dGhpbmcgbmV3IE5h
dCBoYXMgYmVlbiBhZHZvY2F0aW5nIGJhc2ljYWxseSB0aGlzIGZvciBzb21lIHRpbWUsIGFuZCBk
aXMgc3VibWl0IGEgZHJhZnQuICZuYnNwOyBJIHByZWZlciB0byByZXR1cm4gdGhlIGluZm8gaW4g
dGhlIGV4aXN0aW5nIGZvcm1hdCByYXRoZXIgdGhhbiBhcyBsaW5rIGhlYWRlcnMsICZuYnNwO2J1
dCB0aGF0IGlzIHRoZSBsYXJnZXN0IGRpZmZlcmVuY2UgYmV0d2VlbiB3aGF0DQogTmF0IGFuZCBJ
IGFyZSBzYXlpbmcgd2l0aCByZXNwZWN0IHRvIHJlc291cmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIHRoZSBjb3JlIG9mIG15
IHByb2JsZW0gd2l0aCBQaGls4oCZcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBndWVzcyB3ZSB3aWxsIG5lZWQgdG8gaGF2ZSBh
IGxvbmcgY29udmVyc2F0aW9uIGluIEJBLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMTMs
IDIwMTYsIGF0IDg6MTIgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu
dEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBpcyBhIHBy
b3Bvc2VkIGFsdGVybmF0ZSBwcm9wb3NhbCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zlcnku
ICZuYnNwO0FzIHN1Y2gsIGl0IGNvbnRhaW5zIHRoZSBzYW1lIHJlZ2lzdHJ5IGZvciBPQXV0aCBD
b25maWcgTWV0YWRhdGEgYXMgdGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IGJvdGggc29sdXRpb25z
IGFyZSBub3QgcmVxdWlyZWQsIG9yIGRlcGVuZGluZyBvbiBXRyBkaXNjdXNzaW9uIHRoZXkNCiB3
aWxsIGJlIG1lcmdlZC4gVGhlIGludGVudCBpcyB0byBwcm92aWRlIGEgc2ltcGxlIGNvbXBsZXRl
IGRyYWZ0IGZvciBjb25zaWRlcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SG93IGl0IHdvcmtzLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGF0IGEgY2xpZW50IGhhcyBwcmV2aW91
c2x5IGRpc2NvdmVyZWQgYW4gT0F1dGggcHJvdGVjdGVkIHJlc291cmNlLCB0aGUgYm91bmQgY29u
ZmlndXJhdGlvbiBtZXRob2QgYWxsb3dzIGEgY2xpZW50IHRvIHJldHVybiB0aGUgY29uZmlndXJh
dGlvbiBmb3IgYW4gb2F1dGggYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGhhdCBjYW4gaXNzdWUgdG9r
ZW5zIGZvciB0aGUgcmVzb3VyY2UgVVJJIHNwZWNpZmllZA0KIGJ5IHRoZSBjbGllbnQuICZuYnNw
O1RoZSBBUyBpcyBub3QgcmVxdWlyZWQgdG8gYmUgaW4gdGhlIHNhbWUgZG9tYWluLiAmbmJzcDtU
aGUgQVMgaXMgaG93ZXZlciByZXF1aXJlZCB0byBrbm93IGlmIGl0IGNhbiBpc3N1ZSB0b2tlbnMg
Zm9yIGEgcmVzb3VyY2Ugc2VydmljZSAod2hpY2ggcHJlc3VtZXMgc29tZSBhZ3JlZW1lbnQgZXhp
c3RzIG9uIHRva2VucyBldGMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgZG9lcyBub3QgcmVxdWlyZSB0aGF0IHRoZSByZXNv
dXJjZSBleGlzdCAoZS5nLiBmb3IgdW5jb25maWd1cmVkIG9yIG5ldyB1c2VyIGJhc2VkIHJlc291
cmNlcykuIEl0IG9ubHkgcmVxdWlyZXMgdGhhdCB0aGUgQVMgc2VydmljZSBwcm92aWRlciBhZ3Jl
ZXMgaXQgY2FuIGlzc3VlIHRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLCByZXR1cm5p
bmcgdGhlIE9BdXRoIHNlcnZpY2UgY29uZmlndXJhdGlvbiBmb3IgYSBzcGVjaWZpZWQgcmVzb3Vy
Y2UgVVJJIHNlcnZlcyB0byBjb25maXJtIHRoZSBjbGllbnQgaXMgaW4gcG9zc2Vzc2lvbiBvZiBh
IHZhbGlkIHJlc291cmNlIFVSSSBlbnN1cmluZyB0aGUgY2xpZW50IGhhcyByZWNlaXZlZCBhIHZh
bGlkIHNldCBvZiBlbmRwb2ludHMgZm9yIHRoZQ0KIHJlc291cmNlIGFuZCB0aGUgYXNzb2NpYXRl
ZCBvYXV0aCBzZXJ2aWNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBwcm9wb3NlIHRoYXQgdGhlIFdHIGNvbnNpZGVyIHRoZSBhbHRlcm5h
dGUgZHJhZnQgY2FyZWZ1bGx5IGFzIHdlbGwgYXMgb3RoZXIgc3VibWlzc2lvbnMgYW5kIGV2YWx1
YXRlIHRoZSBicm9hZGVyIGRpc2NvdmVyeSBwcm9ibGVtIGJlZm9yZSBwcm9jZWVkaW5nIHdpdGgg
V0dMQyBvbiBPQXV0aCBEaXNjb3ZlcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3
LmluZGVwZW5kZW50aWQuY29tLyI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu
Y29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206IDwvc3Bhbj4N
CjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh
dGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAudHh0PC9zcGFuPjwvYj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
RGF0ZTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+TWFyY2ggMTMsIDIwMTYgYXQgMzo1MzozNyBQTSBQRFQ8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPlRvOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtQaGlsIEh1bnQmcXVvdDsgJmx0OzxhIGhyZWY9
Im1haWx0bzpwaGlsLmh1bnRAeWFob28uY29tIj5waGlsLmh1bnRAeWFob28uY29tPC9hPiZndDss
ICZxdW90O0FudGhvbnkgTmFkYWxpbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRA
bWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDssICZxdW90O1Rvbnkg
TmFkYWxpbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+
dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
cj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0w
MC50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBoaWwgSHVudCBh
bmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOjxz
cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5kcmFmdC1o
dW50LW9hdXRoLWJvdW5kLWNvbmZpZzxicj4NClJldmlzaW9uOjxzcGFuIGNsYXNzPSJhcHBsZS10
YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDwvc3Bhbj4wMDxicj4NClRpdGxlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5PQXV0aCAyLjAgQm91bmQgQ29uZmlndXJhdGlv
biBMb29rdXA8YnI+DQpEb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv
c3Bhbj4yMDE2LTAzLTEzPGJyPg0KR3JvdXA6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgPC9zcGFuPkluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOjxz
cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4y
Mjxicj4NClVSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu
ZXQtZHJhZnRzL2RyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwLnR4dCI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmln
LTAwLnR4dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm
Lm9yZy9kb2MvZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWcvPC9hPjxicj4NCkh0bWxpemVk
OiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAiPmh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0wMDwv
YT48YnI+DQo8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsmbmJzcDtUaGlzIHNwZWNp
ZmljYXRpb24gZGVmaW5lcyBhIG1lY2hhbmlzbSBmb3IgdGhlIGNsaWVudCBvZiBhbiBPQXV0aCAy
LjA8YnI+DQombmJzcDsmbmJzcDtwcm90ZWN0ZWQgcmVzb3VyY2Ugc2VydmljZSB0byBvYnRhaW4g
dGhlIGNvbmZpZ3VyYXRpb24gZGV0YWlscyBvZiBhbjxicj4NCiZuYnNwOyZuYnNwO09BdXRoIDIu
MCBhdXRob3JpemF0aW9uIHNlcnZlciB0aGF0IGlzIGNhcGFibGUgb2YgYXV0aG9yaXppbmcgYWNj
ZXNzPGJyPg0KJm5ic3A7Jm5ic3A7dG8gYSBzcGVjaWZpYyByZXNvdXJjZSBzZXJ2aWNlLiAmbmJz
cDtUaGUgaW5mb3JtYXRpb24gaW5jbHVkZXMgdGhlIE9BdXRoPGJyPg0KJm5ic3A7Jm5ic3A7Mi4w
IGNvbXBvbmVudCBlbmRwb2ludCBsb2NhdGlvbiBVUklzIGFuZCBhcyB3ZWxsIGFzIGF1dGhvcml6
YXRpb248YnI+DQombmJzcDsmbmJzcDtzZXJ2ZXIgY2FwYWJpbGl0aWVzLjxicj4NCjxicj4NCjxi
cj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg
bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6
ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29s
cy5pZXRmLm9yZy8iPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNl
Y3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_SN1PR0301MB164556D8BE843B6C141A66E6F5880SN1PR0301MB1645_--


From nobody Mon Mar 14 08:10:55 2016
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 CC8D312DCA4 for ; Mon, 14 Mar 2016 08:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 cbZt_QbS065r for ; Mon, 14 Mar 2016 08:10:50 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B8112DBA7 for ; Mon, 14 Mar 2016 08:01:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P0q3tZYIGXm6t4GFZOhKxjlnkIFf+HjRKQ18kn4XkmM=; b=VpnZAYt4i4aKWDl0yKgBGkse9iIP5KaT9nYLAIpI9R95C30cn01n95GHTPCMbbIXCMAufwy2KRoToWZ+dzOKtKNDwbWVw9yRQ5ghi6OAwKcYoj2EvNWCMLOG7fqweNz+/0lx4KudinoBoidCytI00PbEIqMThb5tyfBZW32gI9U=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 14 Mar 2016 15:01:24 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0434.016; Mon, 14 Mar 2016 15:01:21 +0000
From: Anthony Nadalin 
To: Mike Jones , Phil Hunt 
Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
Thread-Index: AQHRfXsw7VgGJE45rUO1dQJbaliLD59YAM+WgAAqlwCAAD5oAIAAnNIg
Date: Mon, 14 Mar 2016 15:01:20 +0000
Message-ID: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:3::18b]
x-ms-office365-filtering-correlation-id: b3d02c56-9d5c-4030-7947-08d34c198114
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:lO+rAmfzzoBkzxhSFVG/xN75tHEWyPVU5w1hGnZrRFHVlrsGqcVdBVSbNn68T52KkTa9U65aiLheNHlI5CnEzsLFLgpKy09FQVMPzoGzJR5BeZ3Tc/qqW4s9JEFbk/K1PjevyiK+xwqL6hRodh4SLQ==; 24:gAnaWHFVuqY6OkI3n9AFNxejgmdDsItk1AGOFxvllPJiOpQ2CRqHKFniB7v9pyg4hqlJTVNYYaO7azTuAK/PAW4ihPTPQmNm7ZX3WajRP3U=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 0881A7A935
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(24454002)(51414003)(377454003)(52604005)(76576001)(5001770100001)(1511001)(586003)(99286002)(2561002)(19609705001)(2421001)(10090500001)(93886004)(15395725005)(16236675004)(230783001)(86362001)(790700001)(102836003)(6116002)(81166005)(106116001)(92566002)(1096002)(1220700001)(5008740100001)(15650500001)(54356999)(4326007)(10710500007)(122556002)(76176999)(5005710100001)(10400500002)(87936001)(33656002)(50986999)(2906002)(2420400007)(10290500002)(3280700002)(5002640100001)(15975445007)(19625215002)(3660700001)(77096005)(561944003)(5003600100002)(2900100001)(19300405004)(74316001)(5004730100002)(14971765001)(2950100001)(19580395003)(8990500004)(19580405001)(189998001)(7110500001)(19617315012)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12349A7F3F134F560F08137CA6880BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2016 15:01:20.9742 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 15:10:54 -0000

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

TWlrZSwgdGhlcmUgaXMgbm8gbmVlZCB0byBydXNoIHN0YW5kYXJkaXppbmcgdGhlIG1ldGFkYXRh
IHNpbmNlIHRoZXJlIGFyZSBzdGlsbCBvYnZpb3VzIGlzc3VlcyB3aXRoIGRpc2NvdmVyeSBvciB3
aGF0IG9uZSB0aGlua3MgZGlzY292ZXJ5IHNob3VsZCBiZSBhbmQgc2hvdWxkIG5vdCBiZS4gVGhp
cyBpcyBhbHNvIG5vdCB0aGUgT3BlbklEIEZvdW5kYXRpb24sIHRoaXMgZ3JvdXAgc2hvdWxkIG5v
dCBiZSBjb25zdHJhaW5lZCBieSB3aGF0IE9wZW5JRCBoYXMgZG9uZSBidXQgd2Ugc2hvdWxkIGJl
IGluZm9ybWVkLiBTb21lIGNvbXBhbmllcy9pbmRpdmlkdWFscyBtYXkgaGF2ZSB0YWtlbiB3aGF0
IHdhcyB1c2VkIGJ5IE9wZW5JRCBhbmQgdXNlZCB0aGF0IGFzIE9hdXRoIERpc2NvdmVyeSBidXQg
b25jZSBhZ2FpbiB3ZSBzaG91bGQgbm90IGJlIHJlc3RyYWluZWQgaW4gd2hhdCBpcyB0ZWNobmlj
YWxseSB0aGUgYmVzdCBjaG9pY2UgYmVjYXVzZSBPcGVuSUQgZGlkIGl0IGEgY2VydGFpbiB3YXks
IGl0IG1heSBiZSB0aGF0IE9wZW5JRCBkaWQgaXQgdGhlIGJlc3Qgd2F5IGJ1dCBsZXRzIG5vdCB0
cnkgdG8gZm9yY2UgdGhlIGRlY2lzaW9uIGJhc2VzIHVwb24gT3BlbklEIENlcnRpZmljYXRpb24u
DQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIE1pa2UgSm9uZXMNClNlbnQ6IFN1bmRheSwgTWFyY2ggMTMsIDIwMTYgMTA6MjkgUE0NClRv
OiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRm
Lm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm
b3IgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAudHh0DQoNClRoYW5rcyBmb3IgcG9z
dGluZyB0aGlzLCBQaGlsLiAgSXQgcHJvdmlkZXMgYSBjb25jcmV0ZSBleGFtcGxlIG9mIGEgd2F5
IHRoYXQgcHJvdGVjdGVkIHJlc291cmNlIGRpc2NvdmVyeSBjb3VsZCBiZSBhZGRlZCB0byBhdXRo
b3JpemF0aW9uIHNlcnZlciBtZXRhZGF0YSBkaXNjb3ZlcnksIGFuZCBhcyBzdWNoLCBzaG91bGQg
cHJvdmlkZSB1c2VmdWwgaW5wdXQgZm9yIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbnMgb24gdGhp
cyB0b3BpYy4gIEl04oCZcyBhbHdheXMgZ3JlYXQgd2hlbiBzb21lb25lIHRha2VzIHRoZSB0aW1l
IHRvIHdyaXRlIGFuIGFjdHVhbCBkcmFmdCB0aGF0IGNhbiBiZSBleGFtaW5lZCBhbmQgaW1wbGVt
ZW50ZWQsIGFuZCBJIGFwcHJlY2lhdGUgeW91IGRvaW5nIHRoYXQuDQoNClRoZSBjb250ZW50IG9m
IHlvdXIgZHJhZnQgcG9pbnRzIG91dCB0aGF0IHRoZXJlIGFwcGVhcnMgdG8gYmUgY29tcGxldGUg
YWdyZWVtZW50IG9uIHdoYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG1ldGFkYXRhIGZvcm1h
dCBzaG91bGQgYmUsIHdoaWNoIGlzIGdyZWF0ISAgSeKAmWxsIG5vdGUgdGhhdCBTZWN0aW9uIDMg
b2YgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAgdGl0bGVkIOKAnEF1dGhvcml6YXRp
b24gU2VydmVyIE1ldGFkYXRh4oCdIGlzIGFuIGV4YWN0IGNvcHkgb2YgU2VjdGlvbiAyIG9mIGRy
YWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTAxICh3aXRoIHRoZSBzYW1lIHRpdGxlKSwgbW9kdWxv
IGFwcGx5aW5nIGEgY29ycmVjdGlvbiBzdWdnZXN0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuICBU
byBtZSB0aGlzIHN1Z2dlc3RzIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG1ldGFkYXRh
IGRlZmluaXRpb25zIGluIGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5ICh3aGljaCBpcyBub3cg
dGhlIHdob2xlIG5vcm1hdGl2ZSBjb250ZW50IG9mIHRoZSBkcmFmdCkgYXJlIGNsZWFybHkgcmVh
ZHkgZm9yIHN0YW5kYXJkaXphdGlvbiwgc2luY2UgZXZlbiB5b3VyIGFsdGVybmF0aXZlIHByb3Bv
c2FsIGluY2x1ZGVzIHRoZW0gdmVyYmF0aW0uDQoNClJlYWRpbmcgeW91ciBkcmFmdCwgdGhlIHBy
b2JsZW0gSSBoYXZlIHdpdGggaXQgaXMgdGhhdCB5b3UgYXJlIHJldHVybmluZyB0aGUgQVMgbWV0
YWRhdGEgb25seSBhcyBhIFdlYkZpbmdlciByZXNwb25zZSwgcmF0aGVyIHRoYW4gYXMgYW4gaHR0
cHMtcHJvdGVjdGVkIHJlc291cmNlIHB1Ymxpc2hlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2
ZXIuICBUaGUgY2hvaWNlIHRvIG9ubHkgcmV0dXJuIHRoaXMgdmlhIFdlYkZpbmdlciBtYWtlcyB5
b3VyIGRyYWZ0IGluY29tcGF0aWJsZSB3aXRoIG1vc3QgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25z
IG9mIE9BdXRoIG1ldGFkYXRhLCBpbmNsdWRpbmcgdGhlIDIyIGltcGxlbWVudGF0aW9ucyB1c2lu
ZyBpdCBsaXN0ZWQgYXQgaHR0cDovL29wZW5pZC5uZXQvY2VydGlmaWNhdGlvbi88aHR0cHM6Ly9u
YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZm9w
ZW5pZC5uZXQlMmZjZXJ0aWZpY2F0aW9uJTJmJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy
b3NvZnQuY29tJTdjNTgyODRiMjAwZThmNDM5MzBiZjcwOGQzNGJjOThjYTAlN2M3MmY5ODhiZjg2
ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9MDU0NWpCNXhPanJKRjBLcmU3QlhLZ2RH
QlI2d1pTVGNIVkV3ZnR4am9VUSUzZD4gKHNlZSB0aGUg4oCcT1AgQ29uZmln4oCdIGNvbHVtbiBp
biB0aGUgdGFibGUpIGFuZCBPQXV0aCAyLjAgbGlicmFyaWVzIHN1Y2ggYXMgTWljcm9zb2Z04oCZ
cyDigJxBREFM4oCdIGxpYnJhcnksIHdoaWNoIHVzZXMgdGhlIG1ldGFkYXRhIHBhdGggZm9yIGNs
aWVudCBjb25maWd1cmF0aW9uLiAgV2l0aG91dCBoYXZpbmcgQVNzIHByb3ZpZGUgdGhlIG1ldGFk
YXRhIGFzIGFuIGh0dHBzLXByb3RlY3RlZCByZXNvdXJjZSwgaW1wbGVtZW50YXRpb25zIHN1Y2gg
YXMgQURBTCBjYW7igJl0IHVzZSBpdCBmb3IgY2xpZW50IGNvbmZpZ3VyYXRpb24gYXMgdGhlIGN1
cnJlbnRseSBkby4NCg0KVGhlcmVmb3JlLCBJIHdvdWxkIHJlcXVlc3QgdGhhdCB5b3UgbWFrZSB0
aGVzZSBtaW5vciByZXZpc2lvbnMgdG8geW91ciBkcmFmdCBhbmQgcmVwdWJsaXNoLCBzbyBhcyB0
byBwcm92aWRlIGEgdW5pZmllZCB3YXkgZm9yd2FyZCB0aGF0IGlzIGNvbXBhdGlibGUgd2l0aCBh
bGwga25vd24gZXhpc3RpbmcgT0F1dGggRGlzY292ZXJ5IGRlcGxveW1lbnRzOg0KDQoxLiAgICAg
IE1vZGlmeSB5b3VyIHNlY3Rpb24gMiDigJxBdXRob3JpemF0aW9uIFNlcnZlciBXZWJGaW5nZXIg
RGlzY292ZXJ54oCdIHRvIGhhdmUgdGhlIFdlYkZpbmdlciByZXF1ZXN0IHJldHVybiB0aGUgaXNz
dWVyIGlkZW50aWZpZXIgZm9yIHRoZSBBUyBhcyB0aGUg4oCcV2ViRmluZ2VyIOKAnHJlbOKAnSB2
YWx1ZSwgcmF0aGVyIHRoYW4gcmV0dXJuaW5nIHRoZSBtZXRhZGF0YSB2YWx1ZXMgYnkgdmFsdWUg
YXMgdGhlIOKAnHByb3BlcnRpZXPigJ0gdmFsdWUuDQoNCjIuICAgICAgUmVmZXJlbmNlIHRoZSBt
ZXRhZGF0YSBkZWZpbml0aW9ucyBmcm9tIFNlY3Rpb24gMiBvZiBkcmFmdC1pZXRmLW9hdXRoLWRp
c2NvdmVyeSwgcmF0aGVyIHRoYW4gZHVwbGljYXRpbmcgdGhlbSBpbiB5b3VyIFNlY3Rpb24gMy4N
Cg0KVGhhdCB3b3VsZCBoYXZlIHRoZSBhZHZhbnRhZ2Ugb2YgcGFyaW5nIHlvdXIgZHJhZnQgZG93
biB0byBvbmx5IHRoZSBuZXcgdGhpbmdzIHRoYXQgaXQgcHJvcG9zZXMsIGVuYWJsaW5nIHRoZW0g
dG8gYmUgbW9yZSBjbGVhcmx5IHVuZGVyc3Rvb2QgYW5kIGV2YWx1YXRlZCBvbiB0aGVpciBvd24g
bWVyaXRzLiAgSSBsb29rIGZvcndhcmQgdG8gdGhlIGRpc2N1c3Npb25zIG9mIHdheXMgb2YgcGVy
Zm9ybWluZyBhZGRpdGlvbmFsIGtpbmRzIG9mIE9BdXRoIGRpc2NvdmVyeSwgYW5kIGNvbnNpZGVy
IHlvdXIgZHJhZnQgYSB2YWx1YWJsZSBpbnB1dCB0byB0aG9zZSBkaXNjdXNzaW9ucy4NCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJl
c3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBTdW5kYXksIE1hcmNo
IDEzLCAyMDE2IDY6NDUgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1h
aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpDYzogb2F1dGggPG9hdXRoQGlldGYub3JnPG1h
aWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lv
biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwLnR4dA0K
DQpBcyBJIGhhdmUgdG9sZCBQaGlsIG9mZiBsaXN0Lg0KDQpEaXNjb3ZlcnkgaXMgdGhlIHdyb25n
IHBsYWNlIHRvIHRyeSBhbmQgcHJvdmlkZSBzZWN1cml0eSBhZ2FpbnN0IG1hbiBpbiB0aGUgbWlk
ZGxlIGF0dGFja3Mgb24gdGhlIFJTLg0KDQpUaGlzIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8ga25v
dyB3aGF0IHRoZSBSUyBVUkkgaXMgYmVmb3JlIHJldHJpZXZpbmcgdGhlIGluZm9ybWF0aW9uIG9u
IHRoZSBBUyBDb25maWd1cmF0aW9uLg0KDQpUaGUgcHJvcG9zYWwgTWlrZSBhbmQgSSBoYXZlIGJl
ZW4gd29ya2luZyBvbiByZXF1aXJlcyB0aGUgY2xpZW50IHRvIGhhdmUgYSBub3Rpb24gb2Ygd2hh
dCBBUEkgaXQgaXMgbG9va2luZyBmb3IgYW5kIHJldHJpZXZlIHRoZSAud2VsbC1rbm93biBmaWxl
IGZvciB0aGF0IEFQSSBmcm9tIHRoZSBpc3N1ZXIuICAgVGhhdCBhbGxvd3MgYSBwcm90b2NvbCBs
aWtlIENvbm5lY3QgdG8gcmVnaXN0ZXIgaXRzIG93biBjb25maWcgZmlsZSB0aGF0IGNhbiBwb2lu
dCB0byB0aGUgUlMuDQoNCklmIHRoZSBBUEkgc3BlY2lmaWMgd2VsbCBrbm93biBpcyBub3QgYXZh
aWxhYmxlIHRoZSBjbGllbnQgY2FuIHRyeSB0aGUgZGVmYXVsdCBvYXV0aC1zZXJ2ZXIgb25lLg0K
DQpUaGF0IHRoZW4gYWxsb3dzIHVzIHRvIGRlYWwgd2l0aCByZXN0cmljdGluZyB3aGVyZSBBVCBh
cmUgcHJlc2VudGVkIGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIHJhdGhlciB0aGVuIGRyYWdnaW5n
IGRpc2NvdmVyeSBpbiBhcyBhIHJlcXVpcmVtZW50Lg0KDQpJbiBteSBvcGluaW9uIHRoZSByZXNv
dXJjZSB0aGUgdG9rZW4gaXMgdGFyZ2V0ZWQgdG8gc2hvdWxkIGJlIHNlcGFyYXRlZCBmcm9tIHRo
ZSBzY29wZSBhbmQgcmV0dXJuZWQgYXMgcGFydCBvZiB0aGUgbWV0YS1kYXRhIGFib3V0IHRoZSBB
VCBhbG9uZyB3aXRoIHNjb3BlcyBncmFudGVkIGFuZCBleHBpcnkgdGltZS4gICBXZSBzaG91bGQg
YWxzbyBoYXZlIGEgaW5wdXQgcGFyYW1ldGVyIGZvciByZXNvdXJjZXMgc28gdGhhdCBhIGNsaWVu
dCBjYW4gcmVzdHJpY3QgdG9rZW5zIGlzc3VlZCB0byBhIHN1YnNldCBvZiB0aGUgb25lcyBncmFu
dGVkIGJ5IHRoZSByZWZyZXNoIHRva2VuLiAgIEl0IHdvdWxkIHRoZW4gYWxzbyBiZSBwb3NzaWJs
ZSB0byBhc2sgYSBBUyBmb3IgYSB0b2tlbiBmb3IgYSB1bnJlZ2lzdGVyZWQgUlMgYW5kIGhhdmUg
dGhlIEFTIHByb2R1Y2UgYSBKV1QgYWNjZXNzIHRva2VuIHdpdGggdGhlIHJlc291cmNlIGFzIGFu
IGF1ZGllbmNlIGlmIHBvbGljeSBhbGxvd3MuDQoNClRoYXQgaG93ZXZlciB3YXMgc3VwcG9zZWQg
dG8gYmUgZGVhbHQgd2l0aCBhcyBwYXJ0IG9mIHRoZSBtaXhlZCB1cCBjbGllbnQgc2V0IG9mIG1p
dGlnYXRpb25zLg0KSW4gdGhhdCB0aGUgZ29hbCB3YXMgdG8gbWl0aWdhdGUgdGhlIGF0dGFja3Mg
YnkgcmV0dXJuaW5nIG1ldGEtZGF0YSBhYm91dCB0aGUgdG9rZW5zLCBhbmQgbm90IHRvIHJlcXVp
cmUgZGlzY292ZXJ5Lg0KDQpXZSBpbnRlbmQgdG8gcmV0dXJuIOKAnGlzc+KAnSBhbmQg4oCcY2xl
aW50X2lk4oCdIGZvciB0aGUgY29kZSwgYW5kIEkgaW50ZW5kIHRvIGRpc2N1c3MgYXQgdGhlIEYy
RiByZXR1cm5pbmcgcmVzb3VyY2UgZm9yIEFUIGFzIHdlbGwuDQoNClRob3NlIG1pdGlnYXRlIHRo
ZSBhdHRhY2suDQoNCkkgd2lsbCBjb250aW51ZSB0byByZXNpc3QgbWl4aW5nIHVwIGRpc2NvdmVy
eSBvZiBjb25maWd1cmF0aW9uIG1ldGEtZGF0YSB3aXRoIG1pdGlnYXRpb24gb2YgdGhlIGF0dGFj
a3MuDQoNCldlIHJldHVybiBtZXRhLWRhdGEgYWJvdXQgdGhlIHRva2VucyBub3csIGJlY2F1c2Ug
QVQgYXJlIG9wYXF1ZSB0byB0aGUgY2xpZW50LCB3ZSBuZWdsZWN0ZWQgdG8gaW5jbHVkZSBzb21l
IG9mIHRoZSBpbmZvcm1hdGlvbiBmb3IgdGhlIGNsaWVudCBuZWVkcyB0byBiZSBzZWN1cmUuICAg
V2UganVzdCBuZWVkIHRvIGFkZCB0aGF0IGluIHRvIHRoZSBleGlzdGluZyBmbG93cy4NCg0KV2hp
bGUgUGhpbOKAmXMgcHJvcG9zYWwgaXMgZWFzaWVyIGZvciB0aGUgQVMgdG8gaW1wbGVtZW50IGFz
IGFuIGFkZCBvbiwgaXQgcHV0cyBtb3JlIG9mIGEgYnVyZGVuIG9uIHRoZSBjbGllbnQgbmVlZGlu
ZyB0byBwb3RlbnRpYWxseSBjaGFuZ2UgaG93IGl0IHN0b3JlcyB0aGUgcmVsYXRpb25zaGlwcyBi
ZXR3ZWVuIEFTIGFuZCBSUyB0byBwcmV2ZW50IGNvbXByb21pc2UsIEkgdGhpbmsgdGhlIHNvbHV0
aW9uIHNob3VsZCBiZSBiaWFzZWQgdG93YXJkcyBzaW1wbGljaXR5IG9uIHRoZSBjbGllbnQgc2lk
ZS4NCg0KSWYgd2UgcmV0dXJuIHRoZSByZXNvdXJjZXMgYXMgcGFydCBvZiB0aGUgZXhpc3Rpbmcg
bWV0YSBkYXRhIHRoZSBjbGllbnQgY2hlY2tzIHRoYXQgYWdhaW5zdCB0aGUgcmVzb3VyY2UgaXQg
aW50ZW5kcyB0byBzZW5kIHRoZSB0b2tlbiB0byBhbmQgaWYgaXQgaXMgbm90IGluIHRoZSBsaXN0
IHRoZW4gaXQgY2Fu4oCZdCBzZW5kIHRoZSB0b2tlbi4gIFNpbXBsZSBjaGVjayBldmVyeSB0aW1l
IGl0IGdldHMgYSBuZXcgQVQsIG5vIG9wdGlvbmFsaXR5Lg0KDQpJIGFtIG5vdCBzYXlpbmcgYW55
dGhpbmcgbmV3IE5hdCBoYXMgYmVlbiBhZHZvY2F0aW5nIGJhc2ljYWxseSB0aGlzIGZvciBzb21l
IHRpbWUsIGFuZCBkaXMgc3VibWl0IGEgZHJhZnQuICAgSSBwcmVmZXIgdG8gcmV0dXJuIHRoZSBp
bmZvIGluIHRoZSBleGlzdGluZyBmb3JtYXQgcmF0aGVyIHRoYW4gYXMgbGluayBoZWFkZXJzLCAg
YnV0IHRoYXQgaXMgdGhlIGxhcmdlc3QgZGlmZmVyZW5jZSBiZXR3ZWVuIHdoYXQgTmF0IGFuZCBJ
IGFyZSBzYXlpbmcgd2l0aCByZXNwZWN0IHRvIHJlc291cmNlLg0KDQpUaGF0IGlzIHRoZSBjb3Jl
IG9mIG15IHByb2JsZW0gd2l0aCBQaGls4oCZcyBkcmFmdC4NCg0KSSBndWVzcyB3ZSB3aWxsIG5l
ZWQgdG8gaGF2ZSBhIGxvbmcgY29udmVyc2F0aW9uIGluIEJBLg0KDQpSZWdhcmRzDQpKb2huIEIu
DQoNCk9uIE1hciAxMywgMjAxNiwgYXQgODoxMiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3Jh
Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KVGhpcyBkcmFm
dCBpcyBhIHByb3Bvc2VkIGFsdGVybmF0ZSBwcm9wb3NhbCBmb3IgZHJhZnQtaWV0Zi1vYXV0aC1k
aXNjb3ZlcnkuICBBcyBzdWNoLCBpdCBjb250YWlucyB0aGUgc2FtZSByZWdpc3RyeSBmb3IgT0F1
dGggQ29uZmlnIE1ldGFkYXRhIGFzIHRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCBib3RoIHNvbHV0
aW9ucyBhcmUgbm90IHJlcXVpcmVkLCBvciBkZXBlbmRpbmcgb24gV0cgZGlzY3Vzc2lvbiB0aGV5
IHdpbGwgYmUgbWVyZ2VkLiBUaGUgaW50ZW50IGlzIHRvIHByb3ZpZGUgYSBzaW1wbGUgY29tcGxl
dGUgZHJhZnQgZm9yIGNvbnNpZGVyYXRpb24uDQoNCkhvdyBpdCB3b3Jrcy4uLg0KR2l2ZW4gdGhh
dCBhIGNsaWVudCBoYXMgcHJldmlvdXNseSBkaXNjb3ZlcmVkIGFuIE9BdXRoIHByb3RlY3RlZCBy
ZXNvdXJjZSwgdGhlIGJvdW5kIGNvbmZpZ3VyYXRpb24gbWV0aG9kIGFsbG93cyBhIGNsaWVudCB0
byByZXR1cm4gdGhlIGNvbmZpZ3VyYXRpb24gZm9yIGFuIG9hdXRoIGF1dGhvcml6YXRpb24gc2Vy
dmVyIHRoYXQgY2FuIGlzc3VlIHRva2VucyBmb3IgdGhlIHJlc291cmNlIFVSSSBzcGVjaWZpZWQg
YnkgdGhlIGNsaWVudC4gIFRoZSBBUyBpcyBub3QgcmVxdWlyZWQgdG8gYmUgaW4gdGhlIHNhbWUg
ZG9tYWluLiAgVGhlIEFTIGlzIGhvd2V2ZXIgcmVxdWlyZWQgdG8ga25vdyBpZiBpdCBjYW4gaXNz
dWUgdG9rZW5zIGZvciBhIHJlc291cmNlIHNlcnZpY2UgKHdoaWNoIHByZXN1bWVzIHNvbWUgYWdy
ZWVtZW50IGV4aXN0cyBvbiB0b2tlbnMgZXRjKS4NCg0KVGhlIGRyYWZ0IGRvZXMgbm90IHJlcXVp
cmUgdGhhdCB0aGUgcmVzb3VyY2UgZXhpc3QgKGUuZy4gZm9yIHVuY29uZmlndXJlZCBvciBuZXcg
dXNlciBiYXNlZCByZXNvdXJjZXMpLiBJdCBvbmx5IHJlcXVpcmVzIHRoYXQgdGhlIEFTIHNlcnZp
Y2UgcHJvdmlkZXIgYWdyZWVzIGl0IGNhbiBpc3N1ZSB0b2tlbnMuDQoNCkZyb20gYSBzZWN1cml0
eSBwZXJzcGVjdGl2ZSwgcmV0dXJuaW5nIHRoZSBPQXV0aCBzZXJ2aWNlIGNvbmZpZ3VyYXRpb24g
Zm9yIGEgc3BlY2lmaWVkIHJlc291cmNlIFVSSSBzZXJ2ZXMgdG8gY29uZmlybSB0aGUgY2xpZW50
IGlzIGluIHBvc3Nlc3Npb24gb2YgYSB2YWxpZCByZXNvdXJjZSBVUkkgZW5zdXJpbmcgdGhlIGNs
aWVudCBoYXMgcmVjZWl2ZWQgYSB2YWxpZCBzZXQgb2YgZW5kcG9pbnRzIGZvciB0aGUgcmVzb3Vy
Y2UgYW5kIHRoZSBhc3NvY2lhdGVkIG9hdXRoIHNlcnZpY2VzLg0KDQpJIHByb3Bvc2UgdGhhdCB0
aGUgV0cgY29uc2lkZXIgdGhlIGFsdGVybmF0ZSBkcmFmdCBjYXJlZnVsbHkgYXMgd2VsbCBhcyBv
dGhlciBzdWJtaXNzaW9ucyBhbmQgZXZhbHVhdGUgdGhlIGJyb2FkZXIgZGlzY292ZXJ5IHByb2Js
ZW0gYmVmb3JlIHByb2NlZWRpbmcgd2l0aCBXR0xDIG9uIE9BdXRoIERpc2NvdmVyeS4NCg0KVGhh
bmtzIQ0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0
cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUy
ZiUyZnd3dy5pbmRlcGVuZGVudGlkLmNvbSUyZiZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj
cm9zb2Z0LmNvbSU3YzU4Mjg0YjIwMGU4ZjQzOTMwYmY3MDhkMzRiYzk4Y2EwJTdjNzJmOTg4YmY4
NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXdZWDFidm1haXdGVVRuUWZSNG1jSGNt
ell0TkE5SzE5dlZ3Z1BYJTJmRmtpNCUzZD4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpw
aGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJv
bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmc+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtb2F1
dGgtYm91bmQtY29uZmlnLTAwLnR4dA0KRGF0ZTogTWFyY2ggMTMsIDIwMTYgYXQgMzo1MzozNyBQ
TSBQRFQNClRvOiAiUGhpbCBIdW50IiA8cGhpbC5odW50QHlhaG9vLmNvbTxtYWlsdG86cGhpbC5o
dW50QHlhaG9vLmNvbT4+LCAiQW50aG9ueSBOYWRhbGluIiA8dG9ueW5hZEBtaWNyb3NvZnQuY29t
PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiwgIlRvbnkgTmFkYWxpbiIgPHRvbnluYWRA
bWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCg0KDQpBIG5ldyB2
ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAudHh0DQpoYXMg
YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBoaWwgSHVudCBhbmQgcG9zdGVkIHRvIHRo
ZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgICBkcmFmdC1odW50LW9hdXRo
LWJvdW5kLWNvbmZpZw0KUmV2aXNpb246ICAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgICAg
IE9BdXRoIDIuMCBCb3VuZCBDb25maWd1cmF0aW9uIExvb2t1cA0KRG9jdW1lbnQgZGF0ZTogICAg
ICAgICAgMjAxNi0wMy0xMw0KR3JvdXA6ICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv
bg0KUGFnZXM6ICAgICAgICAgICAgICAyMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0wMC50
eHQ8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0
cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZpbnRlcm5ldC1kcmFmdHMlMmZkcmFmdC1odW50LW9h
dXRoLWJvdW5kLWNvbmZpZy0wMC50eHQmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29m
dC5jb20lN2M1ODI4NGIyMDBlOGY0MzkzMGJmNzA4ZDM0YmM5OGNhMCU3YzcyZjk4OGJmODZmMTQx
YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1VQjhsN2l1Q0tpS2xCR1BjOEZXd1ZHdVgwc0wz
MHV0d29Ha0hkbkVQM2RnJTNkPg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnLzxodHRwczovL25hMDEu
c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZmRhdGF0
cmFja2VyLmlldGYub3JnJTJmZG9jJTJmZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWclMmYm
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M1ODI4NGIyMDBlOGY0Mzkz
MGJmNzA4ZDM0YmM5OGNhMCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZz
ZGF0YT1oUndadzRhdDVsTURudnhNUVM5OThob2FkdHptVXVvbVNKbnc1V2NDTks4JTNkPg0KSHRt
bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LW9hdXRo
LWJvdW5kLWNvbmZpZy0wMDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWh1
bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv
ZnQuY29tJTdjNTgyODRiMjAwZThmNDM5MzBiZjcwOGQzNGJjOThjYTAlN2M3MmY5ODhiZjg2ZjE0
MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9ZnhyT0VYcktPbCUyYmVYd2ElMmZuTSUyZkVm
SGFSVVhVSXNIWGN1M3JmRDNvZkZRTSUzZD4NCg0KDQpBYnN0cmFjdDoNCiAgVGhpcyBzcGVjaWZp
Y2F0aW9uIGRlZmluZXMgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgb2YgYW4gT0F1dGggMi4w
DQogIHByb3RlY3RlZCByZXNvdXJjZSBzZXJ2aWNlIHRvIG9idGFpbiB0aGUgY29uZmlndXJhdGlv
biBkZXRhaWxzIG9mIGFuDQogIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIHNlcnZlciB0aGF0IGlz
IGNhcGFibGUgb2YgYXV0aG9yaXppbmcgYWNjZXNzDQogIHRvIGEgc3BlY2lmaWMgcmVzb3VyY2Ug
c2VydmljZS4gIFRoZSBpbmZvcm1hdGlvbiBpbmNsdWRlcyB0aGUgT0F1dGgNCiAgMi4wIGNvbXBv
bmVudCBlbmRwb2ludCBsb2NhdGlvbiBVUklzIGFuZCBhcyB3ZWxsIGFzIGF1dGhvcml6YXRpb24N
CiAgc2VydmVyIGNhcGFiaWxpdGllcy4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg
dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50
aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p
ZXRmLm9yZzxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2M1ODI4NGIyMDBlOGY0MzkzMGJmNzA4ZDM0YmM5OGNhMCU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT00RjdzTzBKZ3pRdkJlM0h4VXlP
cGhMdTg1WEc3VTZobDNZVENyeGt4OE9ZJTNkPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9y
ZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBt
aWNyb3NvZnQuY29tJTdjNTgyODRiMjAwZThmNDM5MzBiZjcwOGQzNGJjOThjYTAlN2M3MmY5ODhi
Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9aUpra29HNktkMk5Ga3ZBdHdmWml5
RTRSQkZOb1NaaHJQcnh0bWpaOWZvRSUzZD4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo
DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz
IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv
bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN
CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxl
LW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHls
ZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93
dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K
CXttc28tbGlzdC1pZDo2ODA0NzcyMzY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp
c3QtdGVtcGxhdGUtaWRzOjI4MTU2MDEzMCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5
ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz
dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDIN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t
YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ
e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp
c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7
DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph
bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50
Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t
OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh
dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86
aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5NaWtlLCB0aGVyZSBpcyBubyBuZWVkIHRvIHJ1c2ggc3RhbmRh
cmRpemluZyB0aGUgbWV0YWRhdGEgc2luY2UgdGhlcmUgYXJlIHN0aWxsIG9idmlvdXMgaXNzdWVz
IHdpdGggZGlzY292ZXJ5IG9yIHdoYXQgb25lIHRoaW5rcyBkaXNjb3Zlcnkgc2hvdWxkIGJlIGFu
ZCBzaG91bGQgbm90IGJlLiBUaGlzDQogaXMgYWxzbyBub3QgdGhlIE9wZW5JRCBGb3VuZGF0aW9u
LCB0aGlzIGdyb3VwIHNob3VsZCBub3QgYmUgY29uc3RyYWluZWQgYnkgd2hhdCBPcGVuSUQgaGFz
IGRvbmUgYnV0IHdlIHNob3VsZCBiZSBpbmZvcm1lZC4gU29tZSBjb21wYW5pZXMvaW5kaXZpZHVh
bHMgbWF5IGhhdmUgdGFrZW4gd2hhdCB3YXMgdXNlZCBieSBPcGVuSUQgYW5kIHVzZWQgdGhhdCBh
cyBPYXV0aCBEaXNjb3ZlcnkgYnV0IG9uY2UgYWdhaW4gd2Ugc2hvdWxkIG5vdCBiZSByZXN0cmFp
bmVkDQogaW4gd2hhdCBpcyB0ZWNobmljYWxseSB0aGUgYmVzdCBjaG9pY2UgYmVjYXVzZSBPcGVu
SUQgZGlkIGl0IGEgY2VydGFpbiB3YXksIGl0IG1heSBiZSB0aGF0IE9wZW5JRCBkaWQgaXQgdGhl
IGJlc3Qgd2F5IGJ1dCBsZXRzIG5vdCB0cnkgdG8gZm9yY2UgdGhlIGRlY2lzaW9uIGJhc2VzIHVw
b24gT3BlbklEIENlcnRpZmljYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2UgSm9uZXM8YnI+DQo8Yj5TZW50Ojwv
Yj4gU3VuZGF5LCBNYXJjaCAxMywgMjAxNiAxMDoyOSBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBI
dW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoICZs
dDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10g
TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZp
Zy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhhbmtzIGZvciBwb3N0aW5nIHRoaXMsIFBo
aWwuJm5ic3A7IEl0IHByb3ZpZGVzIGEgY29uY3JldGUgZXhhbXBsZSBvZiBhIHdheSB0aGF0IHBy
b3RlY3RlZCByZXNvdXJjZSBkaXNjb3ZlcnkgY291bGQgYmUgYWRkZWQgdG8gYXV0aG9yaXphdGlv
biBzZXJ2ZXIgbWV0YWRhdGEgZGlzY292ZXJ5LA0KIGFuZCBhcyBzdWNoLCBzaG91bGQgcHJvdmlk
ZSB1c2VmdWwgaW5wdXQgZm9yIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbnMgb24gdGhpcyB0b3Bp
Yy4mbmJzcDsgSXTigJlzIGFsd2F5cyBncmVhdCB3aGVuIHNvbWVvbmUgdGFrZXMgdGhlIHRpbWUg
dG8gd3JpdGUgYW4gYWN0dWFsIGRyYWZ0IHRoYXQgY2FuIGJlIGV4YW1pbmVkIGFuZCBpbXBsZW1l
bnRlZCwgYW5kIEkgYXBwcmVjaWF0ZSB5b3UgZG9pbmcgdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBjb250ZW50IG9mIHlvdXIgZHJhZnQgcG9pbnRz
IG91dCB0aGF0IHRoZXJlIGFwcGVhcnMgdG8gYmUgY29tcGxldGUgYWdyZWVtZW50IG9uIHdoYXQg
dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG1ldGFkYXRhIGZvcm1hdCBzaG91bGQgYmUsIHdoaWNo
IGlzIGdyZWF0ISZuYnNwOw0KIEnigJlsbCBub3RlIHRoYXQgU2VjdGlvbiAzIG9mIGRyYWZ0LWh1
bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwIHRpdGxlZCDigJxBdXRob3JpemF0aW9uIFNlcnZlciBN
ZXRhZGF0YeKAnSBpcyBhbiBleGFjdCBjb3B5IG9mIFNlY3Rpb24gMiBvZiBkcmFmdC1pZXRmLW9h
dXRoLWRpc2NvdmVyeS0wMSAod2l0aCB0aGUgc2FtZSB0aXRsZSksIG1vZHVsbyBhcHBseWluZyBh
IGNvcnJlY3Rpb24gc3VnZ2VzdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiZuYnNwOyBUbyBtZSB0
aGlzDQogc3VnZ2VzdHMgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWV0YWRhdGEgZGVm
aW5pdGlvbnMgaW4gZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnkgKHdoaWNoIGlzIG5vdyB0aGUg
d2hvbGUgbm9ybWF0aXZlIGNvbnRlbnQgb2YgdGhlIGRyYWZ0KSBhcmUgY2xlYXJseSByZWFkeSBm
b3Igc3RhbmRhcmRpemF0aW9uLCBzaW5jZSBldmVuIHlvdXIgYWx0ZXJuYXRpdmUgcHJvcG9zYWwg
aW5jbHVkZXMgdGhlbSB2ZXJiYXRpbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMwMDIwNjAiPlJlYWRpbmcgeW91ciBkcmFmdCwgdGhlIHByb2JsZW0gSSBoYXZlIHdpdGggaXQg
aXMgdGhhdCB5b3UgYXJlIHJldHVybmluZyB0aGUgQVMgbWV0YWRhdGEgb25seSBhcyBhIFdlYkZp
bmdlciByZXNwb25zZSwgcmF0aGVyIHRoYW4gYXMgYW4gaHR0cHMtcHJvdGVjdGVkIHJlc291cmNl
DQogcHVibGlzaGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4mbmJzcDsgVGhlIGNob2lj
ZSB0byBvbmx5IHJldHVybiB0aGlzIHZpYSBXZWJGaW5nZXIgbWFrZXMgeW91ciBkcmFmdCBpbmNv
bXBhdGlibGUgd2l0aCBtb3N0IGRlcGxveWVkIGltcGxlbWVudGF0aW9ucyBvZiBPQXV0aCBtZXRh
ZGF0YSwgaW5jbHVkaW5nIHRoZSAyMiBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgaXQgbGlzdGVkIGF0
DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v
P3VybD1odHRwJTNhJTJmJTJmb3BlbmlkLm5ldCUyZmNlcnRpZmljYXRpb24lMmYmYW1wO2RhdGE9
MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNTgyODRiMjAwZThmNDM5MzBiZjcw
OGQzNGJjOThjYTAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3Nk
YXRhPTA1NDVqQjV4T2pySkYwS3JlN0JYS2dkR0JSNndaU1RjSFZFd2Z0eGpvVVElM2QiPg0KaHR0
cDovL29wZW5pZC5uZXQvY2VydGlmaWNhdGlvbi88L2E+IChzZWUgdGhlIOKAnE9QIENvbmZpZ+KA
nSBjb2x1bW4gaW4gdGhlIHRhYmxlKSBhbmQgT0F1dGggMi4wIGxpYnJhcmllcyBzdWNoIGFzIE1p
Y3Jvc29mdOKAmXMg4oCcQURBTOKAnSBsaWJyYXJ5LCB3aGljaCB1c2VzIHRoZSBtZXRhZGF0YSBw
YXRoIGZvciBjbGllbnQgY29uZmlndXJhdGlvbi4mbmJzcDsgV2l0aG91dCBoYXZpbmcgQVNzIHBy
b3ZpZGUgdGhlIG1ldGFkYXRhIGFzIGFuIGh0dHBzLXByb3RlY3RlZA0KIHJlc291cmNlLCBpbXBs
ZW1lbnRhdGlvbnMgc3VjaCBhcyBBREFMIGNhbuKAmXQgdXNlIGl0IGZvciBjbGllbnQgY29uZmln
dXJhdGlvbiBhcyB0aGUgY3VycmVudGx5IGRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+VGhlcmVmb3JlLCBJIHdvdWxkIHJlcXVlc3QgdGhhdCB5b3UgbWFrZSB0
aGVzZSBtaW5vciByZXZpc2lvbnMgdG8geW91ciBkcmFmdCBhbmQgcmVwdWJsaXNoLCBzbyBhcyB0
byBwcm92aWRlIGEgdW5pZmllZCB3YXkgZm9yd2FyZCB0aGF0IGlzIGNvbXBhdGlibGUgd2l0aCBh
bGwNCiBrbm93biBleGlzdGluZyBPQXV0aCBEaXNjb3ZlcnkgZGVwbG95bWVudHM6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu
ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNd
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu
b3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48
IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPk1vZGlmeSB5b3VyIHNlY3Rp
b24gMiDigJxBdXRob3JpemF0aW9uIFNlcnZlciBXZWJGaW5nZXIgRGlzY292ZXJ54oCdIHRvIGhh
dmUgdGhlIFdlYkZpbmdlciByZXF1ZXN0IHJldHVybiB0aGUgaXNzdWVyIGlkZW50aWZpZXIgZm9y
IHRoZSBBUyBhcyB0aGUg4oCcV2ViRmluZ2VyDQog4oCccmVs4oCdIHZhbHVlLCByYXRoZXIgdGhh
biByZXR1cm5pbmcgdGhlIG1ldGFkYXRhIHZhbHVlcyBieSB2YWx1ZSBhcyB0aGUg4oCccHJvcGVy
dGllc+KAnSB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh
cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv
MiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxz
cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN
Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MjA2MCI+UmVmZXJlbmNlIHRoZSBtZXRhZGF0YSBkZWZpbml0aW9ucyBmcm9tIFNlY3Rpb24gMiBv
ZiBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeSwgcmF0aGVyIHRoYW4gZHVwbGljYXRpbmcgdGhl
bSBpbiB5b3VyIFNlY3Rpb24gMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw
MDIwNjAiPlRoYXQgd291bGQgaGF2ZSB0aGUgYWR2YW50YWdlIG9mIHBhcmluZyB5b3VyIGRyYWZ0
IGRvd24gdG8gb25seSB0aGUgbmV3IHRoaW5ncyB0aGF0IGl0IHByb3Bvc2VzLCBlbmFibGluZyB0
aGVtIHRvIGJlIG1vcmUgY2xlYXJseSB1bmRlcnN0b29kIGFuZCBldmFsdWF0ZWQgb24NCiB0aGVp
ciBvd24gbWVyaXRzLiZuYnNwOyBJIGxvb2sgZm9yd2FyZCB0byB0aGUgZGlzY3Vzc2lvbnMgb2Yg
d2F5cyBvZiBwZXJmb3JtaW5nIGFkZGl0aW9uYWwga2luZHMgb2YgT0F1dGggZGlzY292ZXJ5LCBh
bmQgY29uc2lkZXIgeW91ciBkcmFmdCBhIHZhbHVhYmxlIGlucHV0IHRvIHRob3NlIGRpc2N1c3Np
b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lz
aGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll
dGYub3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg
T2YgPC9iPkpvaG4gQnJhZGxleTxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1hcmNoIDEzLCAy
MDE2IDY6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRv
OnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0K
PGI+Q2M6PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0
aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE5l
dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWct
MDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg
SSBoYXZlIHRvbGQgUGhpbCBvZmYgbGlzdC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EaXNjb3ZlcnkgaXMgdGhlIHdyb25nIHBsYWNlIHRvIHRy
eSBhbmQgcHJvdmlkZSBzZWN1cml0eSBhZ2FpbnN0IG1hbiBpbiB0aGUgbWlkZGxlIGF0dGFja3Mg
b24gdGhlIFJTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGlzIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8ga25vdyB3aGF0IHRoZSBSUyBVUkkg
aXMgYmVmb3JlIHJldHJpZXZpbmcgdGhlIGluZm9ybWF0aW9uIG9uIHRoZSBBUyBDb25maWd1cmF0
aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGUgcHJvcG9zYWwgTWlrZSBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbiByZXF1aXJlcyB0
aGUgY2xpZW50IHRvIGhhdmUgYSBub3Rpb24gb2Ygd2hhdCBBUEkgaXQgaXMgbG9va2luZyBmb3Ig
YW5kIHJldHJpZXZlIHRoZSAud2VsbC1rbm93biBmaWxlIGZvciB0aGF0IEFQSSBmcm9tIHRoZSBp
c3N1ZXIuICZuYnNwOyBUaGF0IGFsbG93cyBhIHByb3RvY29sIGxpa2UgQ29ubmVjdCB0byByZWdp
c3RlciBpdHMgb3duIGNvbmZpZw0KIGZpbGUgdGhhdCBjYW4gcG9pbnQgdG8gdGhlIFJTLiAmbmJz
cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SWYgdGhlIEFQSSBzcGVjaWZpYyB3ZWxsIGtub3duIGlzIG5vdCBhdmFpbGFibGUgdGhl
IGNsaWVudCBjYW4gdHJ5IHRoZSBkZWZhdWx0IG9hdXRoLXNlcnZlciBvbmUuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgdGhlbiBhbGxv
d3MgdXMgdG8gZGVhbCB3aXRoIHJlc3RyaWN0aW5nIHdoZXJlIEFUIGFyZSBwcmVzZW50ZWQgYXMg
cGFydCBvZiB0aGUgcHJvdG9jb2wgcmF0aGVyIHRoZW4gZHJhZ2dpbmcgZGlzY292ZXJ5IGluIGFz
IGEgcmVxdWlyZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkluIG15IG9waW5pb24gdGhlIHJlc291cmNlIHRoZSB0b2tlbiBpcyB0YXJn
ZXRlZCB0byBzaG91bGQgYmUgc2VwYXJhdGVkIGZyb20gdGhlIHNjb3BlIGFuZCByZXR1cm5lZCBh
cyBwYXJ0IG9mIHRoZSBtZXRhLWRhdGEgYWJvdXQgdGhlIEFUIGFsb25nIHdpdGggc2NvcGVzIGdy
YW50ZWQgYW5kIGV4cGlyeSB0aW1lLiAmbmJzcDsgV2Ugc2hvdWxkIGFsc28gaGF2ZSBhIGlucHV0
IHBhcmFtZXRlciBmb3IgcmVzb3VyY2VzIHNvDQogdGhhdCBhIGNsaWVudCBjYW4gcmVzdHJpY3Qg
dG9rZW5zIGlzc3VlZCB0byBhIHN1YnNldCBvZiB0aGUgb25lcyBncmFudGVkIGJ5IHRoZSByZWZy
ZXNoIHRva2VuLiAmbmJzcDsgSXQgd291bGQgdGhlbiBhbHNvIGJlIHBvc3NpYmxlIHRvIGFzayBh
IEFTIGZvciBhIHRva2VuIGZvciBhIHVucmVnaXN0ZXJlZCBSUyBhbmQgaGF2ZSB0aGUgQVMgcHJv
ZHVjZSBhIEpXVCBhY2Nlc3MgdG9rZW4gd2l0aCB0aGUgcmVzb3VyY2UgYXMgYW4gYXVkaWVuY2Ug
aWYgcG9saWN5DQogYWxsb3dzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGF0IGhvd2V2ZXIgd2FzIHN1cHBvc2VkIHRvIGJlIGRlYWx0IHdp
dGggYXMgcGFydCBvZiB0aGUgbWl4ZWQgdXAgY2xpZW50IHNldCBvZiBtaXRpZ2F0aW9ucy4gJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
biB0aGF0IHRoZSBnb2FsIHdhcyB0byBtaXRpZ2F0ZSB0aGUgYXR0YWNrcyBieSByZXR1cm5pbmcg
bWV0YS1kYXRhIGFib3V0IHRoZSB0b2tlbnMsIGFuZCBub3QgdG8gcmVxdWlyZSBkaXNjb3Zlcnku
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldl
IGludGVuZCB0byByZXR1cm4g4oCcaXNz4oCdIGFuZCDigJxjbGVpbnRfaWTigJ0gZm9yIHRoZSBj
b2RlLCBhbmQgSSBpbnRlbmQgdG8gZGlzY3VzcyBhdCB0aGUgRjJGIHJldHVybmluZyByZXNvdXJj
ZSBmb3IgQVQgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhvc2UgbWl0aWdhdGUgdGhlIGF0dGFjay4gJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCBjb250
aW51ZSB0byByZXNpc3QgbWl4aW5nIHVwIGRpc2NvdmVyeSBvZiBjb25maWd1cmF0aW9uIG1ldGEt
ZGF0YSB3aXRoIG1pdGlnYXRpb24gb2YgdGhlIGF0dGFja3MuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHJldHVybiBtZXRhLWRhdGEgYWJv
dXQgdGhlIHRva2VucyBub3csIGJlY2F1c2UgQVQgYXJlIG9wYXF1ZSB0byB0aGUgY2xpZW50LCB3
ZSBuZWdsZWN0ZWQgdG8gaW5jbHVkZSBzb21lIG9mIHRoZSBpbmZvcm1hdGlvbiBmb3IgdGhlIGNs
aWVudCBuZWVkcyB0byBiZSBzZWN1cmUuICZuYnNwOyBXZSBqdXN0IG5lZWQgdG8gYWRkIHRoYXQg
aW4gdG8gdGhlIGV4aXN0aW5nIGZsb3dzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSBQaGls4oCZcyBwcm9wb3NhbCBpcyBlYXNpZXIg
Zm9yIHRoZSBBUyB0byBpbXBsZW1lbnQgYXMgYW4gYWRkIG9uLCBpdCBwdXRzIG1vcmUgb2YgYSBi
dXJkZW4gb24gdGhlIGNsaWVudCBuZWVkaW5nIHRvIHBvdGVudGlhbGx5IGNoYW5nZSBob3cgaXQg
c3RvcmVzIHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gQVMgYW5kIFJTIHRvIHByZXZlbnQgY29t
cHJvbWlzZSwgSSB0aGluayB0aGUgc29sdXRpb24gc2hvdWxkDQogYmUgYmlhc2VkIHRvd2FyZHMg
c2ltcGxpY2l0eSBvbiB0aGUgY2xpZW50IHNpZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIHJldHVybiB0aGUgcmVzb3VyY2VzIGFz
IHBhcnQgb2YgdGhlIGV4aXN0aW5nIG1ldGEgZGF0YSB0aGUgY2xpZW50IGNoZWNrcyB0aGF0IGFn
YWluc3QgdGhlIHJlc291cmNlIGl0IGludGVuZHMgdG8gc2VuZCB0aGUgdG9rZW4gdG8gYW5kIGlm
IGl0IGlzIG5vdCBpbiB0aGUgbGlzdCB0aGVuIGl0IGNhbuKAmXQgc2VuZCB0aGUgdG9rZW4uICZu
YnNwO1NpbXBsZSBjaGVjayBldmVyeSB0aW1lIGl0IGdldHMgYSBuZXcgQVQsDQogbm8gb3B0aW9u
YWxpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgYW0gbm90IHNheWluZyBhbnl0aGluZyBuZXcgTmF0IGhhcyBiZWVuIGFkdm9jYXRpbmcg
YmFzaWNhbGx5IHRoaXMgZm9yIHNvbWUgdGltZSwgYW5kIGRpcyBzdWJtaXQgYSBkcmFmdC4gJm5i
c3A7IEkgcHJlZmVyIHRvIHJldHVybiB0aGUgaW5mbyBpbiB0aGUgZXhpc3RpbmcgZm9ybWF0IHJh
dGhlciB0aGFuIGFzIGxpbmsgaGVhZGVycywgJm5ic3A7YnV0IHRoYXQgaXMgdGhlIGxhcmdlc3Qg
ZGlmZmVyZW5jZSBiZXR3ZWVuIHdoYXQNCiBOYXQgYW5kIEkgYXJlIHNheWluZyB3aXRoIHJlc3Bl
Y3QgdG8gcmVzb3VyY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoYXQgaXMgdGhlIGNvcmUgb2YgbXkgcHJvYmxlbSB3aXRoIFBoaWzigJlz
IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIGd1ZXNzIHdlIHdpbGwgbmVlZCB0byBoYXZlIGEgbG9uZyBjb252ZXJzYXRpb24gaW4g
QkEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAxMywgMjAxNiwgYXQgODoxMiBQTSwgUGhp
bCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVu
dEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IGlzIGEgcHJvcG9zZWQgYWx0ZXJuYXRlIHByb3Bv
c2FsIGZvciBkcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS4gJm5ic3A7QXMgc3VjaCwgaXQgY29u
dGFpbnMgdGhlIHNhbWUgcmVnaXN0cnkgZm9yIE9BdXRoIENvbmZpZyBNZXRhZGF0YSBhcyB0aGUg
YXV0aG9ycyBiZWxpZXZlIHRoYXQgYm90aCBzb2x1dGlvbnMgYXJlIG5vdCByZXF1aXJlZCwgb3Ig
ZGVwZW5kaW5nIG9uIFdHIGRpc2N1c3Npb24gdGhleQ0KIHdpbGwgYmUgbWVyZ2VkLiBUaGUgaW50
ZW50IGlzIHRvIHByb3ZpZGUgYSBzaW1wbGUgY29tcGxldGUgZHJhZnQgZm9yIGNvbnNpZGVyYXRp
b24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgaXQg
d29ya3MuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkdpdmVuIHRoYXQgYSBjbGllbnQgaGFzIHByZXZpb3VzbHkgZGlzY292ZXJlZCBhbiBPQXV0
aCBwcm90ZWN0ZWQgcmVzb3VyY2UsIHRoZSBib3VuZCBjb25maWd1cmF0aW9uIG1ldGhvZCBhbGxv
d3MgYSBjbGllbnQgdG8gcmV0dXJuIHRoZSBjb25maWd1cmF0aW9uIGZvciBhbiBvYXV0aCBhdXRo
b3JpemF0aW9uIHNlcnZlciB0aGF0IGNhbiBpc3N1ZSB0b2tlbnMgZm9yIHRoZSByZXNvdXJjZSBV
Ukkgc3BlY2lmaWVkDQogYnkgdGhlIGNsaWVudC4gJm5ic3A7VGhlIEFTIGlzIG5vdCByZXF1aXJl
ZCB0byBiZSBpbiB0aGUgc2FtZSBkb21haW4uICZuYnNwO1RoZSBBUyBpcyBob3dldmVyIHJlcXVp
cmVkIHRvIGtub3cgaWYgaXQgY2FuIGlzc3VlIHRva2VucyBmb3IgYSByZXNvdXJjZSBzZXJ2aWNl
ICh3aGljaCBwcmVzdW1lcyBzb21lIGFncmVlbWVudCBleGlzdHMgb24gdG9rZW5zIGV0YykuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBk
cmFmdCBkb2VzIG5vdCByZXF1aXJlIHRoYXQgdGhlIHJlc291cmNlIGV4aXN0IChlLmcuIGZvciB1
bmNvbmZpZ3VyZWQgb3IgbmV3IHVzZXIgYmFzZWQgcmVzb3VyY2VzKS4gSXQgb25seSByZXF1aXJl
cyB0aGF0IHRoZSBBUyBzZXJ2aWNlIHByb3ZpZGVyIGFncmVlcyBpdCBjYW4gaXNzdWUgdG9rZW5z
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G
cm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIHJldHVybmluZyB0aGUgT0F1dGggc2VydmljZSBj
b25maWd1cmF0aW9uIGZvciBhIHNwZWNpZmllZCByZXNvdXJjZSBVUkkgc2VydmVzIHRvIGNvbmZp
cm0gdGhlIGNsaWVudCBpcyBpbiBwb3NzZXNzaW9uIG9mIGEgdmFsaWQgcmVzb3VyY2UgVVJJIGVu
c3VyaW5nIHRoZSBjbGllbnQgaGFzIHJlY2VpdmVkIGEgdmFsaWQgc2V0IG9mIGVuZHBvaW50cyBm
b3IgdGhlDQogcmVzb3VyY2UgYW5kIHRoZSBhc3NvY2lhdGVkIG9hdXRoIHNlcnZpY2VzLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHByb3Bv
c2UgdGhhdCB0aGUgV0cgY29uc2lkZXIgdGhlIGFsdGVybmF0ZSBkcmFmdCBjYXJlZnVsbHkgYXMg
d2VsbCBhcyBvdGhlciBzdWJtaXNzaW9ucyBhbmQgZXZhbHVhdGUgdGhlIGJyb2FkZXIgZGlzY292
ZXJ5IHByb2JsZW0gYmVmb3JlIHByb2NlZWRpbmcgd2l0aCBXR0xDIG9uIE9BdXRoIERpc2NvdmVy
eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv
bi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaW5kZXBlbmRlbnRpZC5jb20lMmYm
YW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNTgyODRiMjAwZThm
NDM5MzBiZjcwOGQzNGJjOThjYTAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3
YzEmYW1wO3NkYXRhPXdZWDFidm1haXdGVVRuUWZSNG1jSGNtell0TkE5SzE5dlZ3Z1BYJTJmRmtp
NCUzZCI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWls
dG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVnaW4gZm9yd2FyZGVkIG1l
c3NhZ2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTog
PC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+
aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDogTmV3IFZlcnNpb24g
Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0wMC50eHQ8L3Nw
YW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5EYXRlOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NYXJjaCAxMywgMjAxNiBhdCAzOjUzOjM3IFBN
IFBEVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+VG86IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90O1BoaWwgSHVudCZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEB5YWhvby5jb20iPnBoaWwuaHVudEB5YWhvby5jb208
L2E+Jmd0OywgJnF1b3Q7QW50aG9ueSBOYWRhbGluJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86
dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OywgJnF1
b3Q7VG9ueSBOYWRhbGluJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3Nv
ZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1bnQtb2F1dGgtYm91bmQt
Y29uZmlnLTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGhp
bCBIdW50IGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4N
Ck5hbWU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu
PmRyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9
ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgPC9zcGFuPjAwPGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPk9BdXRoIDIuMCBCb3VuZCBDb25m
aWd1cmF0aW9uIExvb2t1cDxicj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRh
Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgPC9zcGFuPjIwMTYtMDMtMTM8YnI+DQpHcm91cDo8c3BhbiBjbGFzcz0iYXBwbGUtdGFi
LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0K
UGFnZXM6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PC9zcGFuPjIyPGJyPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxp
bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9y
ZyUyZmludGVybmV0LWRyYWZ0cyUyZmRyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwLnR4
dCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M1ODI4NGIyMDBl
OGY0MzkzMGJmNzA4ZDM0YmM5OGNhMCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3
JTdjMSZhbXA7c2RhdGE9VUI4bDdpdUNLaUtsQkdQYzhGV3dWR3VYMHNMMzB1dHdvR2tIZG5FUDNk
ZyUzZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1bnQtb2F1
dGgtYm91bmQtY29uZmlnLTAwLnR4dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl
bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZGF0YXRyYWNr
ZXIuaWV0Zi5vcmclMmZkb2MlMmZkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZyUyZiZhbXA7
ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M1ODI4NGIyMDBlOGY0Mzkz
MGJmNzA4ZDM0YmM5OGNhMCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh
bXA7c2RhdGE9aFJ3Wnc0YXQ1bE1EbnZ4TVFTOTk4aG9hZHR6bVV1b21TSm53NVdjQ05LOCUzZCI+
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1j
b25maWcvPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWh1bnQt
b2F1dGgtYm91bmQtY29uZmlnLTAwJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9z
b2Z0LmNvbSU3YzU4Mjg0YjIwMGU4ZjQzOTMwYmY3MDhkMzRiYzk4Y2EwJTdjNzJmOTg4YmY4NmYx
NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1meHJPRVhyS09sJTJiZVh3YSUyZm5N
JTJmRWZIYVJVWFVJc0hYY3UzcmZEM29mRlFNJTNkIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0K
QWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBt
ZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgb2YgYW4gT0F1dGggMi4wPGJyPg0KJm5ic3A7Jm5ic3A7
cHJvdGVjdGVkIHJlc291cmNlIHNlcnZpY2UgdG8gb2J0YWluIHRoZSBjb25maWd1cmF0aW9uIGRl
dGFpbHMgb2YgYW48YnI+DQombmJzcDsmbmJzcDtPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBzZXJ2
ZXIgdGhhdCBpcyBjYXBhYmxlIG9mIGF1dGhvcml6aW5nIGFjY2Vzczxicj4NCiZuYnNwOyZuYnNw
O3RvIGEgc3BlY2lmaWMgcmVzb3VyY2Ugc2VydmljZS4gJm5ic3A7VGhlIGluZm9ybWF0aW9uIGlu
Y2x1ZGVzIHRoZSBPQXV0aDxicj4NCiZuYnNwOyZuYnNwOzIuMCBjb21wb25lbnQgZW5kcG9pbnQg
bG9jYXRpb24gVVJJcyBhbmQgYXMgd2VsbCBhcyBhdXRob3JpemF0aW9uPGJyPg0KJm5ic3A7Jm5i
c3A7c2VydmVyIGNhcGFiaWxpdGllcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVh
c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt
ZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg
YXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmYmYW1wO2Rh
dGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNTgyODRiMjAwZThmNDM5MzBi
ZjcwOGQzNGJjOThjYTAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1w
O3NkYXRhPTRGN3NPMEpnelF2QmUzSHhVeU9waEx1ODVYRzdVNmhsM1lUQ3J4a3g4T1klM2QiPg0K
dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0
aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAx
LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cu
aWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdj
dG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M1ODI4NGIyMDBlOGY0MzkzMGJmNzA4ZDM0YmM5OGNh
MCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9aUpra29H
NktkMk5Ga3ZBdHdmWml5RTRSQkZOb1NaaHJQcnh0bWpaOWZvRSUzZCI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BN3PR0301MB12349A7F3F134F560F08137CA6880BN3PR0301MB1234_--


From nobody Mon Mar 14 08:18:07 2016
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 7A91C12DCE6 for ; Mon, 14 Mar 2016 08:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 zzYT7hqKu1k8 for ; Mon, 14 Mar 2016 08:18:04 -0700 (PDT)
Received: from omr-a010e.mx.aol.com (omr-a010e.mx.aol.com [204.29.186.54]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF77C12DC01 for ; Mon, 14 Mar 2016 08:07:50 -0700 (PDT)
Received: from mtaout-mba01.mx.aol.com (mtaout-mba01.mx.aol.com [172.26.133.109]) by omr-a010e.mx.aol.com (Outbound Mail Relay) with ESMTP id E30FA38000CD; Mon, 14 Mar 2016 11:07:49 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mba01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1755E38000088; Mon, 14 Mar 2016 11:07:46 -0400 (EDT)
To: Mike Schwartz , oauth@ietf.org
References:  <0dfa1c46a1a3a9267864dd3265a5c0eb@gluu.org>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E6D3C0.2000202@aol.com>
Date: Mon, 14 Mar 2016 11:07:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <0dfa1c46a1a3a9267864dd3265a5c0eb@gluu.org>
Content-Type: multipart/alternative; boundary="------------060801040008060508090502"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1457968069; bh=j6GxmDQp8Bg3LWNtBvcocPS/LncdxRaScxzGKNHc87U=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=N2Aob3XiBEksxmoLdQVrgKeLjHNidkmrXdUXgEoLEzkTcyYvyX19mC9RbLJPutNdg H2cGVp77TlZpKyiCjz6FJ4x27c7k4LHpNpJpP+Vm0OwsXY1d8r4NCsgDpo4mLPSdEv 3hUIec9559U7nYrA/j5f9YlGw5f0uxXZzCuIJzsw=
x-aol-sid: 3039ac1a856d56e6d3c2136e
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 15:18:06 -0000

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

For what it's worth, we deployed such a system in 2011 using signed 
JWTs, symmetric keys and supporting key rotation via the kid JWT header 
field. The body of the JWT includes 'iss', 'exp', 'uid' (for the user), 
'access_token' (AS specific opaque blob), and 'validation_url' (where to 
validate the AS specific opaque blob).

The issuing AS would generate this JWT and sign it. The RS, then 
validates the signature. If necessary, the RS then also validates the 
opaque token with the issuing AS.

Of course, using encrypted JWTs may be a better solution these days:)

Thanks,
George

On 3/13/16 4:44 PM, Mike Schwartz wrote:
> I like the idea of an encrypted JWT... I guess if there are multiple 
> AS's, how would you know which key to use? Cycle through each key? Are 
> you suggesting maybe use a non-encrypted JWT that contains an 
> encrypted JWT as a value? Something like
>
> {"iss": "https://example.com",
>  "token": "fjbfgy5Fdx8ybx0.."
> }
>
> Are there any OAuth2 profiles to standardize this approach?
>
> - Mike
>
>
> --------------------------
>
> Michael Schwartz
> Gluu
> Founder / CEO
> mike@gluu.org
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


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


  
    
  
  
    For what it's worth, we
      deployed such a system in 2011 using signed JWTs, symmetric keys
      and supporting key rotation via the kid JWT header field. The body
      of the JWT includes 'iss', 'exp', 'uid' (for the user),
      'access_token' (AS specific opaque blob), and 'validation_url'
      (where to validate the AS specific opaque blob). 
    
      
    
      The issuing AS would generate this JWT and sign it. The RS, then
      validates the signature. If necessary, the RS then also validates
      the opaque token with the issuing AS.
    
      
    
      Of course, using encrypted JWTs may be a better solution these
      days:)
    
      
    
      Thanks,
    
      George
    
      
    
        
    
    On 3/13/16 4:44 PM, Mike Schwartz
      wrote:
    
    
    
    
    I like the idea of an encrypted JWT... I guess if
      there are multiple AS's, how would you know which key to use?
      Cycle through each key? Are you suggesting maybe use a
      non-encrypted JWT that contains an encrypted JWT as a value?
      Something like
      
    
      
    
      {"iss": "https://example.com",
      
    
       "token": "fjbfgy5Fdx8ybx0.."
      
    
      }
      
    
      
    
      Are there any OAuth2 profiles to standardize this approach?
      
    
      
    
      - Mike
      
    
      
    
      
    
      --------------------------
      
    
      
    
      Michael Schwartz
      
    
      Gluu
      
    
      Founder / CEO
      
    
      mike@gluu.org
      
    
      
    
      _______________________________________________
      
    
      OAuth mailing list
      
    
      OAuth@ietf.org
      
    
      https://www.ietf.org/mailman/listinfo/oauth
      
    
      
    
    
    
    
    
  


--------------060801040008060508090502--


From nobody Mon Mar 14 09:12:30 2016
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 85A3612DDB6; Fri, 11 Mar 2016 15:05:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.16.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160311230528.15028.93116.idtracker@ietfa.amsl.com>
Date: Fri, 11 Mar 2016 15:05:28 -0800
Archived-At: 
X-Mailman-Approved-At: Mon, 14 Mar 2016 09:12:29 -0700
Cc: oauth@ietf.org
Subject: [OAUTH-WG] oauth - Requested session has been scheduled for IETF 95
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Mar 2016 23:05:28 -0000

Dear Hannes Tschofenig,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

oauth Session 1 (2:00:00)
    Wednesday, Morning Session I 1000-1230
    Room Name: Buen Ayre B size: 125
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Hannes Tschofenig

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: ace saag cfrg tls core lwig




Special Requests:
  Please avoid conflict with sec area BoFs.
---------------------------------------------------------


From nobody Mon Mar 14 09:17:14 2016
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 573E112DB45 for ; Mon, 14 Mar 2016 09:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org
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 yVaJLlZznk-Q for ; Mon, 14 Mar 2016 09:17:11 -0700 (PDT)
Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75AB612DAE3 for ; Mon, 14 Mar 2016 09:17:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id 72455B4182 for ; Mon, 14 Mar 2016 16:16:45 +0000 (UTC)
Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1457972205; x=1458836206; bh=chLnF+9ycm AdUv9oskmtDxHMae8SEqDm1OWe+JUgS+s=; b=wDUXKtgnOfa+JlLwuk27HeGcL0 9FquD4UYSUh1H9btukVOpnNTCtdzWhVVr6MwL7W6jYdgzJ4XcFb5aHSW+vVo8rd5 S7Ie0w0z/Oct0RqSD8r0VoDIDEgBDkwNN7m2fKMGKTmMTP5yMVGOUV9bwmJImBuQ uVeRpFOIRxdxdf5Iw=
Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkdMqOUJc3-4 for ; Mon, 14 Mar 2016 16:16:45 +0000 (UTC)
Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 15661B40E6; Mon, 14 Mar 2016 16:16:45 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 14 Mar 2016 11:16:45 -0500
From: Mike Schwartz 
To: George Fletcher 
Organization: Gluu
In-Reply-To: <56E6D3C0.2000202@aol.com>
References:  <0dfa1c46a1a3a9267864dd3265a5c0eb@gluu.org> <56E6D3C0.2000202@aol.com>
Message-ID: 
X-Sender: mike@gluu.org
User-Agent: Roundcube Webmail
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 16:17:13 -0000

This was the original requirement:

" multiple authorization servers that can issue access tokens for one 
resource server, when the resource server receives an access token from 
a client application, as the first step, the resource server has to 
determine which authorization server to use for access token 
introspection."

Not sure we're all on the same page after numerous responses...

So the fact that the token is an encrypted JWT is great... the question 
is: who issued it? That's why I was thinking of a url encoded JWT with 
the issuer + the encrypted token, such as {"iss": 
"https://as.example.com", "token": "(encrypted JTW)"}

- Mike



From nobody Mon Mar 14 11:56:41 2016
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 5F97D12DC93 for ; Mon, 14 Mar 2016 11:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 M_Xs_CFqSdTz for ; Mon, 14 Mar 2016 11:56:28 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 4788E12DC81 for ; Mon, 14 Mar 2016 11:56:23 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2EIuLh8015123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Mar 2016 18:56:22 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2EIuLAk019056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 14 Mar 2016 18:56:21 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2EIuKsQ009588; Mon, 14 Mar 2016 18:56:21 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Mar 2016 11:56:19 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_90A698B6-6A90-45D8-A478-DD8B75DF0444"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Mon, 14 Mar 2016 11:56:17 -0700
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com> 
To: Mike Jones , John Bradley 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 18:56:40 -0000

--Apple-Mail=_90A698B6-6A90-45D8-A478-DD8B75DF0444
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks to Mike and John for their feedback.  I=E2=80=99ll take each in =
turn:

Mike,

Regarding your suggested amendments

Item 1: Returning the config URL would create two problems. One,it makes =
bound discovery a two-step process - that adds complexity.  It seems far =
simpler to mandate TLS (which I think it already does in the security =
considerations). =20

The two-step process allows the current discovery process to continue. I =
disagree with this. This is why I put forward an =E2=80=9Calternate" =
draft that is almost the same but simply adds the check before returning =
the configuration data.  I worry that  developers would have no =
incentive to do the two-step approach. They would just start at step 2 =
which in turn puts AS=E2=80=99s at risk of exposing tokens because it =
works. This makes OAuth promiscuous.

Regarding existing implementations. Most of those implementations are =
for OIDC.  I think it makes sense for OIDF to continue use of OIDC's =
discovery spec because the UserInfo endpoint is well defined and the =
likelihood of a client mis-informed about the resource endpoint is not =
there.  IMO This does not apply to the broader OAuth community.

Item 2:  It may be appropriate to have a separate configuration registry =
specification, but I think we should hold off until we have a complete =
solution and then make the decision what drafts should exist and how =
many pieces.  A big concern is the perceived complexity of multiple =
solutions and multiple drafts.

As to John Bradley=E2=80=99s comments:

Re: Discovery is the wrong place to mitigate threats.=20
I=E2=80=99m confused by this.  Our mandate was to solve a security =
threat by having a discovery specification to prevent clients being =
mis-lead about endpoints (of which resource service is one) in an oauth =
protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?

Re: Your proposal for MITM mitigation
You propose that instead the resource endpoint check should be in the =
oauth protocol itself.  The difference is that validation is transferred =
back to the client to get it right. As well, without the client =
informing the AS, I can=E2=80=99t see a way for the AS to know what =
endpoint the client is using.  The webfinger approach does this once and =
only requires that the host name be checked in many cases.

As a principle, the members have discussed many times that the AS =
service should do validation when possible =E2=80=94 this was =
particularly true at the Germany meeting when this came up. This is why =
I prefer the client tell the service provider what it intends to do and =
the service provider can fail that request immediately if necessary. We =
don=E2=80=99t have to depend on the developer getting the spec correct =
to fail the correct way.

I worry that adding more parameters to the authz and token protocol =
flows increases complexity and attack surface. It also means per =
authorization validation has to take place vs. a one-time validation at =
config time.  Placing it in the configuration lookup phase (whether via =
web finger or just a special OAuth endpoint) seems more appropriate and =
far less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D

That said, it may be that when we consider all the use cases, some =
combination of AS protocol and discovery may be both needed. I=E2=80=99m =
not ready to make conclusions about this.  The current oauth-discovery =
spec seems to put future generic clients at risk and that is my primary =
concern.

Best Regards,

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 13, 2016, at 10:28 PM, Mike Jones  =
wrote:
>=20
> Thanks for posting this, Phil.  It provides a concrete example of a =
way that protected resource discovery could be added to authorization =
server metadata discovery, and as such, should provide useful input for =
working group discussions on this topic.  It=E2=80=99s always great when =
someone takes the time to write an actual draft that can be examined and =
implemented, and I appreciate you doing that.
> =20
> The content of your draft points out that there appears to be complete =
agreement on what the authorization server metadata format should be, =
which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests that the =
authorization server metadata definitions in draft-ietf-oauth-discovery =
(which is now the whole normative content of the draft) are clearly =
ready for standardization, since even your alternative proposal includes =
them verbatim.
> =20
> Reading your draft, the problem I have with it is that you are =
returning the AS metadata only as a WebFinger response, rather than as =
an https-protected resource published by the authorization server.  The =
choice to only return this via WebFinger makes your draft incompatible =
with most deployed implementations of OAuth metadata, including the 22 =
implementations using it listed athttp://openid.net/certification/ =
 (see the =E2=80=9COP Config=E2=80=9D =
column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D library, which uses the metadata path for client =
configuration.=C2=A0 Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do. <>
> =20
> Therefore, I would request that you make these minor revisions to your =
draft and republish, so as to provide a unified way forward that is =
compatible with all known existing OAuth Discovery deployments:
> 1.       Modify your section 2 =E2=80=9CAuthorization Server WebFinger =
Discovery=E2=80=9D to have the WebFinger request return the issuer =
identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D =
value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
> 2.       Reference the metadata definitions from Section 2 of =
draft-ietf-oauth-discovery, rather than duplicating them in your Section =
3.
> =20
> That would have the advantage of paring your draft down to only the =
new things that it proposes, enabling them to be more clearly understood =
and evaluated on their own merits.  I look forward to the discussions of =
ways of performing additional kinds of OAuth discovery, and consider =
your draft a valuable input to those discussions.
> =20
>                                                           Best wishes,
>                                                           -- Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Sunday, March 13, 2016 6:45 PM
> To: Phil Hunt 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
> =20
> As I have told Phil off list. =20
> =20
> Discovery is the wrong place to try and provide security against man =
in the middle attacks on the RS.
> =20
> This requires the client to know what the RS URI is before retrieving =
the information on the AS Configuration.
> =20
> The proposal Mike and I have been working on requires the client to =
have a notion of what API it is looking for and retrieve the .well-known =
file for that API from the issuer.   That allows a protocol like Connect =
to register its own config file that can point to the RS.  =20
> =20
> If the API specific well known is not available the client can try the =
default oauth-server one.
> =20
> That then allows us to deal with restricting where AT are presented as =
part of the protocol rather then dragging discovery in as a requirement.
> =20
> In my opinion the resource the token is targeted to should be =
separated from the scope and returned as part of the meta-data about the =
AT along with scopes granted and expiry time.   We should also have a =
input parameter for resources so that a client can restrict tokens =
issued to a subset of the ones granted by the refresh token.   It would =
then also be possible to ask a AS for a token for a unregistered RS and =
have the AS produce a JWT access token with the resource as an audience =
if policy allows.
> =20
> That however was supposed to be dealt with as part of the mixed up =
client set of mitigations. =20
> In that the goal was to mitigate the attacks by returning meta-data =
about the tokens, and not to require discovery.
> =20
> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=9D=
 for the code, and I intend to discuss at the F2F returning resource for =
AT as well.
> =20
> Those mitigate the attack. =20
> =20
> I will continue to resist mixing up discovery of configuration =
meta-data with mitigation of the attacks.
> =20
> We return meta-data about the tokens now, because AT are opaque to the =
client, we neglected to include some of the information for the client =
needs to be secure.   We just need to add that in to the existing flows.
> =20
> While Phil=E2=80=99s proposal is easier for the AS to implement as an =
add on, it puts more of a burden on the client needing to potentially =
change how it stores the relationships between AS and RS to prevent =
compromise, I think the solution should be biased towards simplicity on =
the client side.
> =20
> If we return the resources as part of the existing meta data the =
client checks that against the resource it intends to send the token to =
and if it is not in the list then it can=E2=80=99t send the token.  =
Simple check every time it gets a new AT, no optionality.
> =20
> I am not saying anything new Nat has been advocating basically this =
for some time, and dis submit a draft.   I prefer to return the info in =
the existing format rather than as link headers,  but that is the =
largest difference between what Nat and I are saying with respect to =
resource.
> =20
> That is the core of my problem with Phil=E2=80=99s draft.
> =20
> I guess we will need to have a long conversation in BA.
> =20
> Regards
> John B.
> =20
> On Mar 13, 2016, at 8:12 PM, Phil Hunt > wrote:
> =20
> This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry for =
OAuth Config Metadata as the authors believe that both solutions are not =
required, or depending on WG discussion they will be merged. The intent =
is to provide a simple complete draft for consideration.
> =20
> How it works...
> Given that a client has previously discovered an OAuth protected =
resource, the bound configuration method allows a client to return the =
configuration for an oauth authorization server that can issue tokens =
for the resource URI specified by the client.  The AS is not required to =
be in the same domain.  The AS is however required to know if it can =
issue tokens for a resource service (which presumes some agreement =
exists on tokens etc).
> =20
> The draft does not require that the resource exist (e.g. for =
unconfigured or new user based resources). It only requires that the AS =
service provider agrees it can issue tokens.
> =20
> =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.
> =20
> I propose that the WG consider the alternate draft carefully as well =
as other submissions and evaluate the broader discovery problem before =
proceeding with WGLC on OAuth Discovery.
> =20
> Thanks!
> =20
> Phil
> =20
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
> =20
>=20
>=20
> Begin forwarded message:
> =20
> From: internet-drafts@ietf.org 
> Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
> Date: March 13, 2016 at 3:53:37 PM PDT
> To: "Phil Hunt" >, =
"Anthony Nadalin" >, "Tony Nadalin" >
> =20
>=20
> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
>=20
> Name:             draft-hunt-oauth-bound-config
> Revision:         00
> Title:               OAuth 2.0 Bound Configuration Lookup
> Document date:          2016-03-13
> Group:             Individual Submission
> Pages:              22
> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =

> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =

>=20
>=20
> Abstract:
>   This specification defines a mechanism for the client of an OAuth =
2.0
>   protected resource service to obtain the configuration details of an
>   OAuth 2.0 authorization server that is capable of authorizing access
>   to a specific resource service.  The information includes the OAuth
>   2.0 component endpoint location URIs and as well as authorization
>   server capabilities.
>=20
>=20
>=20
>=20
> 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 =
.
>=20
> The IETF Secretariat
>=20
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_90A698B6-6A90-45D8-A478-DD8B75DF0444
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


    Thanks to Mike and John for their feedback. =
 I=E2=80=99ll take each in turn:

    Mike,

    Regarding your suggested amendments

    Item 1: Returning the config URL would =
create two problems. One,it makes bound discovery a two-step process - =
that adds complexity.  It seems far simpler to mandate TLS (which I =
think it already does in the security considerations).  

    The two-step process =
allows the current discovery process to continue. I disagree with this. =
This is why I put forward an =E2=80=9Calternate" draft that is almost =
the same but simply adds the check before returning the configuration =
data.  I worry that  developers would have no incentive to do =
the two-step approach. They would just start at step 2 which in turn =
puts AS=E2=80=99s at risk of exposing tokens because it works. This =
makes OAuth promiscuous.

    Regarding existing implementations. Most of those =
implementations are for OIDC.  I think it makes sense for OIDF to =
continue use of OIDC's discovery spec because the UserInfo endpoint is =
well defined and the likelihood of a client mis-informed about the =
resource endpoint is not there.  IMO This does not apply to the =
broader OAuth community.

    Item 2:  It may be appropriate to have a separate =
configuration registry specification, but I think we should hold off =
until we have a complete solution and then make the decision what drafts =
should exist and how many pieces.  A big concern is the perceived =
complexity of multiple solutions and multiple drafts.

    As to John Bradley=E2=80=99=
s comments:

    Re: =
Discovery is the wrong place to mitigate threats. 
    I=E2=80=99m confused by this.  Our mandate was to solve =
a security threat by having a discovery specification to prevent clients =
being mis-lead about endpoints (of which resource service is one) in an =
oauth protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?

    Re: Your proposal for MITM mitigation
    You =
propose that instead the resource endpoint check should be in the oauth =
protocol itself.  The difference is that validation is transferred =
back to the client to get it right. As well, without the client =
informing the AS, I can=E2=80=99t see a way for the AS to know what =
endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many =
cases.

    As a =
principle, the members have discussed many times that the AS service =
should do validation when possible =E2=80=94 this was particularly true =
at the Germany meeting when this came up. This is why I prefer the =
client tell the service provider what it intends to do and the service =
provider can fail that request immediately if necessary. We don=E2=80=99t =
have to depend on the developer getting the spec correct to fail the =
correct way.

    I =
worry that adding more parameters to the authz and token protocol flows =
increases complexity and attack surface. It also means per authorization =
validation has to take place vs. a one-time validation at config time. =
 Placing it in the configuration lookup phase (whether via web =
finger or just a special OAuth endpoint) seems more appropriate and far =
less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D

    That said, it may be that when we =
consider all the use cases, some combination of AS protocol and =
discovery may be both needed. I=E2=80=99m not ready to make conclusions =
about this.  The current oauth-discovery spec seems to put future =
generic clients at risk and that is my primary concern.

    Best Regards,

    


    

    

    On Mar 13, 2016, at 10:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

    Thanks for posting this, Phil.  It provides a concrete =
example of a way that protected resource discovery could be added to =
authorization server metadata discovery, and as such, should provide =
useful input for working group discussions on this topic.  It=E2=80=99=
s always great when someone takes the time to write an actual draft that =
can be examined and implemented, and I appreciate you doing that.
     
    The =
content of your draft points out that there appears to be complete =
agreement on what the authorization server metadata format should be, =
which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests =
that the authorization server metadata definitions in =
draft-ietf-oauth-discovery (which is now the whole normative content of =
the draft) are clearly ready for standardization, since even your =
alternative proposal includes them verbatim.
     
    Reading your draft, the problem I have with it is that you =
are returning the AS metadata only as a WebFinger response, rather than =
as an https-protected resource published by the authorization =
server.  The choice to only return this via WebFinger makes your =
draft incompatible with most deployed implementations of OAuth metadata, =
including the 22 implementations using it listed athttp://openid.net/certification/ (see the =E2=80=9COP =
Config=E2=80=9D column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CADAL=E2=
=80=9D library, which uses the metadata path for client =
configuration.  Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do.
     
    Therefore, I =
would request that you make these minor revisions to your draft and =
republish, so as to provide a unified way forward that is compatible =
with all known existing OAuth Discovery deployments:
    1.       Modify your section 2 =E2=80=9CAuthorization =
Server WebFinger Discovery=E2=80=9D to have the WebFinger request return =
the issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=
=80=9D value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
    2.       Reference the metadata definitions from =
Section 2 of draft-ietf-oauth-discovery, rather than duplicating them in =
your Section 3.
     
    That would have the advantage of paring your draft down to =
only the new things that it proposes, enabling them to be more clearly =
understood and evaluated on their own merits.  I look forward to =
the discussions of ways of performing additional kinds of OAuth =
discovery, and consider your draft a valuable input to those =
discussions.
     
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          Best =
wishes,
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
    Sent: Sunday, March 13, 2016 6:45 =
PM
    To: Phil Hunt <phil.hunt@oracle.com>
    Cc: oauth=
 <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    As I have told Phil off list.  
     
    Discovery is the wrong place to try and =
provide security against man in the middle attacks on the RS.
     
    This requires the client to know what the =
RS URI is before retrieving the information on the AS Configuration.
     
    The proposal Mike and I have been working =
on requires the client to have a notion of what API it is looking for =
and retrieve the .well-known file for that API from the issuer.   =
That allows a protocol like Connect to register its own config file that =
can point to the RS.   
     
    If the API specific well known is not available the =
client can try the default oauth-server one.
     
    That then allows us to deal with =
restricting where AT are presented as part of the protocol rather then =
dragging discovery in as a requirement.
     
    In my opinion the resource the token is =
targeted to should be separated from the scope and returned as part of =
the meta-data about the AT along with scopes granted and expiry time. =
  We should also have a input parameter for resources so that a =
client can restrict tokens issued to a subset of the ones granted by the =
refresh token.   It would then also be possible to ask a AS for a =
token for a unregistered RS and have the AS produce a JWT access token =
with the resource as an audience if policy allows.
     
    That however was supposed to be dealt =
with as part of the mixed up client set of mitigations.  
    In that the goal was to mitigate the attacks by returning =
meta-data about the tokens, and not to require discovery.
     
    We intend to return =E2=80=9Ciss=E2=80=9D =
and =E2=80=9Ccleint_id=E2=80=9D for the code, and I intend to discuss at =
the F2F returning resource for AT as well.
     
    Those mitigate the attack.  
     
    I will continue to resist mixing up =
discovery of configuration meta-data with mitigation of the attacks.
     
    We return meta-data about the tokens now, =
because AT are opaque to the client, we neglected to include some of the =
information for the client needs to be secure.   We just need to =
add that in to the existing flows.
     
    While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add on, it puts more of a burden on the client needing =
to potentially change how it stores the relationships between AS and RS =
to prevent compromise, I think the solution should be biased towards =
simplicity on the client side.
     
    If we return the resources as part of the existing =
meta data the client checks that against the resource it intends to send =
the token to and if it is not in the list then it can=E2=80=99t send the =
token.  Simple check every time it gets a new AT, no =
optionality.
     
    I am not saying anything new Nat has been advocating =
basically this for some time, and dis submit a draft.   I prefer to =
return the info in the existing format rather than as link headers, =
 but that is the largest difference between what Nat and I are =
saying with respect to resource.
     
    That is the core of my problem with Phil=E2=80=99s =
draft.
     
    I guess we will need to have a long conversation in =
BA.
     
    Regards
    John B.
     
    On =
Mar 13, 2016, at 8:12 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
     
    This draft is a =
proposed alternate proposal for draft-ietf-oauth-discovery.  As =
such, it contains the same registry for OAuth Config Metadata as the =
authors believe that both solutions are not required, or depending on WG =
discussion they will be merged. The intent is to provide a simple =
complete draft for consideration.
     
    How it works...
    Given that a client =
has previously discovered an OAuth protected resource, the bound =
configuration method allows a client to return the configuration for an =
oauth authorization server that can issue tokens for the resource URI =
specified by the client.  The AS is not required to be in the same =
domain.  The AS is however required to know if it can issue tokens =
for a resource service (which presumes some agreement exists on tokens =
etc).
     
    The draft does not require that the resource exist =
(e.g. for unconfigured or new user based resources). It only requires =
that the AS service provider agrees it can issue tokens.
     
    =46rom a security perspective, returning =
the OAuth service configuration for a specified resource URI serves to =
confirm the client is in possession of a valid resource URI ensuring the =
client has received a valid set of endpoints for the resource and the =
associated oauth services.
     
    I propose that the WG consider the alternate draft =
carefully as well as other submissions and evaluate the broader =
discovery problem before proceeding with WGLC on OAuth Discovery.
     
    Thanks!
     
    Phil
     
    @independentid
    www.independentid.com
     


    Begin forwarded message:
     
    Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
    Date: March 13, 2016 =
at 3:53:37 PM PDT
    To: "Phil Hunt" =
<phil.hunt@yahoo.com>, =
"Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>
     

    A new version of =
I-D, draft-hunt-oauth-bound-config-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:        &=
nbsp;    draft-hunt-oauth-bound=
-config
    Revision:        <=
span class=3D"Apple-converted-space"> 00
    Title:        &=
nbsp;      OAuth 2.0 Bound =
Configuration Lookup
    Document date:        &=
nbsp; 2016-03-13
    Group:        &=
nbsp;    Individual =
Submission
    Pages:        &=
nbsp;     22
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

    Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


    Abstract:
      This specification defines a mechanism for the =
client of an OAuth 2.0
      protected resource =
service to obtain the configuration details of an
      OAuth 2.0 authorization server that is capable of =
authorizing access
      to a specific resource =
service.  The information includes the OAuth
      2.0 component endpoint location URIs and as well =
as authorization
      server capabilities.




    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.

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

    =

--Apple-Mail=_90A698B6-6A90-45D8-A478-DD8B75DF0444--


From nobody Mon Mar 14 12:04:47 2016
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 AAD5512D736 for ; Mon, 14 Mar 2016 12:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 DXfYm6yfI8vw for ; Mon, 14 Mar 2016 12:04:43 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 83ABE12D555 for ; Mon, 14 Mar 2016 12:04:43 -0700 (PDT)
Received: by mail-qg0-x236.google.com with SMTP id t4so162383722qge.0 for ; Mon, 14 Mar 2016 12:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=IqnEewEi+J90Yq7EAZAQAMfy1L0skJ27kpyBLoAbrxE=; b=qsCPiENOAZWMVS9/4JOmwX/P1O3ibNZVFC/Hlbu2OutXTBeJHKR17XHByIxRsfslu4 Kby9uONBT5fJg9H3ukIKB69h8+eXSc8luixjU1Jie6TXvtuPShZWMxsB34jBzKcJMG83 wSJcAZkR7ka6OBo6YhU52q/y7e4ts8LT/MR+T8Q1kg9VmgeMpOc/rsDaZq8IYsv6naga H94z5hW1fgsHB5cx+RaOIdfFNHUflFTpZqiZx8Er09h4Iia1KpH0BBzQHKLaZ2x411pA RCm9mX2rDMtN3p8XoKFoBq+rhHS4p6Uniq5O3e2eo/q2C4R4RlqB8blehRjGZGc+n4Yx 24QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IqnEewEi+J90Yq7EAZAQAMfy1L0skJ27kpyBLoAbrxE=; b=HGSPU2VeuG9SianETRUcyGpX0sBRse7VMtR0qrINxtw2cbsdrZeISJv+uI5nopl24g 88SIuqHebZEDI2YQUc8qTchKgZpfGJgrpihVZOqle6PS5/klIYzn+v51idr7amxhZMbr IYjQzX4jXb+lW9GY6sv3NicyQbQ0B4GVJhwaU3AkTSuRzpDx8VscZ0AUHuU1tBZjWRKd 25HCMZHUMz2WrfiO67nVTamudygYv1va/glHuv/XSsfkSlzukuuhsxgEyFDgtW5a71oG ZeoDEnrS0v8/LYoHqWKVHF1dGVGS5dx5S0sG54s0dU38CGl5aA/slDuOEt1ZKFgkHAQ0 2nbg==
X-Gm-Message-State: AD7BkJJlJzMahplWghHkIXQUZHGEV+zYtW4EzXTpZ6bJC5est9T4vRh5zPrvUozspaQstg==
X-Received: by 10.140.20.104 with SMTP id 95mr32092556qgi.40.1457982282514; Mon, 14 Mar 2016 12:04:42 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.161.145]) by smtp.gmail.com with ESMTPSA id d65sm10916568qgf.30.2016.03.14.12.04.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Mar 2016 12:04:41 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_CD024D83-BB07-4E17-BD88-DB2CFD8CECF9"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 14 Mar 2016 16:04:37 -0300
Message-Id: <8515CF13-6159-4F14-951F-66CC9FE4723D@ve7jtb.com>
References:  <0dfa1c46a1a3a9267864dd3265a5c0eb@gluu.org> <56E6D3C0.2000202@aol.com> 
To: Michael Schwartz 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 19:04:45 -0000

--Apple-Mail=_CD024D83-BB07-4E17-BD88-DB2CFD8CECF9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Sorry your first email didn=E2=80=99t mention introspection.

I answered assuming a JWT.

A JWE can have the issuer in the envelope, so the recipient just needs =
to base64url decode the envelope to see who it issuer was and from that =
determine where to introspect it.

However if you are introspecting the token why bother making it a JWE, =
just send a regular JWS with a reference claim in the body that can be =
looked up by the AS during introspection.   =20

If you are trying to do stateless introspection then just send a JWE =
access token containing the required claims and forget the =
introspection.

John B.

> On Mar 14, 2016, at 1:16 PM, Mike Schwartz  wrote:
>=20
> This was the original requirement:
>=20
> " multiple authorization servers that can issue access tokens for one =
resource server, when the resource server receives an access token from =
a client application, as the first step, the resource server has to =
determine which authorization server to use for access token =
introspection."
>=20
> Not sure we're all on the same page after numerous responses...
>=20
> So the fact that the token is an encrypted JWT is great... the =
question is: who issued it? That's why I was thinking of a url encoded =
JWT with the issuer + the encrypted token, such as {"iss": =
"https://as.example.com", "token": "(encrypted JTW)"}
>=20
> - Mike
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_CD024D83-BB07-4E17-BD88-DB2CFD8CECF9
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTQxOTA0MzhaMCMGCSqGSIb3DQEJBDEWBBRTQx0B+4V/ryvVVvefE2Si
AxE5HDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAjw/ul7g5LwcoKQjbmJk2fdj1SsJtGTsmVv6wtNr8xKq3k0YuxH50Q
NYcZxv00RZSuYldtpOIDeMOxcXHLJH5vg+xM36CTcIOdGZBiRHPPzM3ogiKT9voQ2OlsGPo0T1qW
+DaOKYitCy5paN4cPiNHst/b7G7x0l+v/3f0gWheH38sRqOeWyWhfa9oWw//4dM3UaM5QidSSh+O
KfDJvj5Sc2uayFmc3tqsG3sWKgfsg+bj3RGIYrPZKVl3txJh3zuhTjzPu+cHeAe7EQvJL2OEs4I/
KdN9t8aw16mCtpTZaZsh4owJq+6iHoWgb6JqMQp0WfABaFQwsBHqje+RF8AIAAAAAAAA
--Apple-Mail=_CD024D83-BB07-4E17-BD88-DB2CFD8CECF9--


From nobody Mon Mar 14 14:13:19 2016
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 9E39912D785 for ; Mon, 14 Mar 2016 14:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 bB-sPPKPKGNh for ; Mon, 14 Mar 2016 14:13:16 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 D10C812D76F for ; Mon, 14 Mar 2016 14:13:15 -0700 (PDT)
X-AuditID: 12074422-15bff7000000470c-cb-56e7296a6a5a
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 3E.18.18188.A6927E65; Mon, 14 Mar 2016 17:13:14 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u2ELDDaV014184; Mon, 14 Mar 2016 17:13:14 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2ELDBki020159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Mar 2016 17:13:12 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_FDA1EA28-9296-43B3-993D-FB7283B451E8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: 
Date: Mon, 14 Mar 2016 17:13:11 -0400
Message-Id: <6F0AA75E-93BA-45BE-8D71-15925F97407C@mit.edu>
References:  <56E4BC4D.9000806@mit.edu> 
To: Andrea Ceccanti 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYrdT0c3SfB5mcHSiosW3x2fZLbp6NjNZ nHz7is2B2WPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyviz6DNrwY+Aimn7DzE1MJ6362Lk 5JAQMJFYteMcE4gtJNDGJNG5ybiLkQvI3sgoMW3yMjYI5yGTxMFLk9lAqpgFEiRmT3/MCmLz CuhJvLp1GcwWFvCTmHXpHtgkNgFVielrWsBsToFAib83JzOD2CxA8ZM9N1kh5vhJ/N96kh1i jpXEhPmfmSGWbWCU2H5jDiNIQkRAX+LGhMXsEKfKSuz+/YhpAiP/LCR3zEJyB0RcW2LZwtfM ELamxP7u5SyY4hoSnd8msi5gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6qXm1mil5pSuokR HOQuSjsYJ/7zOsQowMGoxMM7Q+p5mBBrYllxZe4hRkkOJiVR3rXcQCG+pPyUyozE4oz4otKc 1OJDjBIczEoivB3SQDnelMTKqtSifJiUNAeLkjhvUOSxMCGB9MSS1OzU1ILUIpisDAeHkgTv aw2gRsGi1PTUirTMnBKENBMHJ8hwHqDhoSA1vMUFibnFmekQ+VOMilLivDtBEgIgiYzSPLhe UBJKeHvY9BWjONArwrzxIFU8wAQG1/0KaDAT0OCe8Gcgg0sSEVJSDYycp9UXq0wqtNLaWMfC wt3eVV10cbv3q6CzjC0vN6ZGG65YsqbXrjbbnuWRvGvpVJsrdwN3hDqvMrnpl+F1yp6Ly4yf 3Zvv1S3OQ393cdcwrL8jucW0s+BSiGnOrzamUxabjc52xOQsn9d+jKFJ7/DfBzUfBWsXrv5g s2T+y6B1RtwmaS+NZymxFGckGmoxFxUnAgD8ae5UHQMAAA==
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 21:13:18 -0000

--Apple-Mail=_FDA1EA28-9296-43B3-993D-FB7283B451E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

We don=E2=80=99t include the scopes or identity information in the token =
itself, so as to prevent it from leaking to parties that shouldn=E2=80=99t=
 need it.=20

The main benefit of introspection is liveness, but it also lets you =
reference data tied to the token that you don=E2=80=99t want to ship in =
the token itself.

At the end of the day, it=E2=80=99s a trade off as to what you want to =
put into the token and what you want attached as a reference. Good news =
is that you can do both together and use the strengths of each.

 =E2=80=94 Justin

> On Mar 13, 2016, at 10:36 PM, Andrea Ceccanti =
 wrote:
>=20
> Hello,
>=20
> interesting thread, thanks.
>=20
> Assuming the scopes are included in the token, the main purpose of =
call to the introspection endpoint is to ensure
> the token hasn't been revoked?
>=20
> We are considering a deployment where a RS can trust multiple AS, and =
having a JWT as access token, with
> issuer, scopes and basic identity information included seems to solve =
our issues.
>=20
> Thanks,
> Andrea
>=20
>=20
>=20
>=20
> 2016-03-13 9:03 GMT+08:00 Justin Richer >:
> What we've done in deployments is to combine JWT and introspection. =
You have all of your servers issue signed JWTs that include the "iss" =
(issuer) in the body, signed with the key of the AS. The tokens also =
include a random "jti" field. The RS submits the token to the =
introspection endpoint of the server identified in "iss", but only after =
validating the signature and other basic bits of information. If the =
introspection call comes back positive (and with the right scope, =
client, and resource owner information), the resource is served.
>=20
>  -- Justin
>=20
>=20
> On 3/11/2016 10:02 PM, Takahiko Kawasaki wrote:
>> Hello,
>>=20
>> I have a question.
>>=20
>> If there exist multiple authorization servers that can issue access =
tokens for one resource server, when the resource server receives an =
access token from a client application, as the first step, the resource =
server has to determine which authorization server to use for access =
token introspection.
>>=20
>> Is there any standard way to determine which authorization server to =
use?
>>=20
>> There may be several ways, for example:
>>=20
>> (1) Embed information about the access token issuer in the access =
token.
>> (2) Add a request parameter to identify the access token issuer.
>> (3) Separate protected resource endpoints for each authorization =
server.
>>=20
>> If there is a standard way, I'd like to know it.
>>=20
>> Best Regards,
>> Takahiko Kawasaki
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

>=20
>=20


--Apple-Mail=_FDA1EA28-9296-43B3-993D-FB7283B451E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

We don=E2=80=99t include the scopes or identity information =
in the token itself, so as to prevent it from leaking to parties that =
shouldn=E2=80=99t need it. 

    The main benefit of introspection is liveness, but it also =
lets you reference data tied to the token that you don=E2=80=99t want to =
ship in the token itself.

    At the end of the day, it=E2=80=99s a trade off as to what =
you want to put into the token and what you want attached as a =
reference. Good news is that you can do both together and use the =
strengths of each.

     =E2=80=94 Justin

    On =
Mar 13, 2016, at 10:36 PM, Andrea Ceccanti <andrea.ceccanti@gmail.com> wrote:

    Hello,

    interesting thread, thanks.

    Assuming the scopes are =
included in the token, the main purpose of call to the introspection =
endpoint is to ensure
    the token hasn't been =
revoked?

    We =
are considering a deployment where a RS can trust multiple AS, and =
having a JWT as access token, with
    issuer, scopes =
and basic identity information included seems to solve our =
issues.

    Thanks,
    Andrea




    2016-03-13 9:03 GMT+08:00 Justin Richer <jricher@mit.edu>:
    
 =20
   =20
 =20
  
    
    What we've done in deployments is to combine JWT and introspection.
    You have all of your servers issue signed JWTs that include the
    "iss" (issuer) in the body, signed with the key of the AS. The
    tokens also include a random "jti" field. The RS submits the token
    to the introspection endpoint of the server identified in "iss", but
    only after validating the signature and other basic bits of
    information. If the introspection call comes back positive (and with
    the right scope, client, and resource owner information), the
    resource is served.
    
    
    
     -- Justin

    
    
    
    
    On 3/11/2016 10:02 PM, Takahiko
      Kawasaki wrote:
    
    
    
    
    
     =20
      
    
        
    
          
    
            
    
              
    
                
    
                  
    
                    
    
                      
    
                        
    Hello,
    
                          
    
                        
    
                        I have a question.
    
                        
    
                        If there exist multiple authorization servers
                        that can issue access tokens for one resource
                        server, when the resource server receives an
                        access token from a client application, as the
                        first step, the resource server has to determine
                        which authorization server to use for access
                        token introspection.
    
                        
    
                      
    
                      Is there any standard way to determine which
                      authorization server to use?
    
                      
    
                    
    
                    There may be several ways, for example:
    =

                    
    
                  
    
                  (1) Embed information about the access token issuer in
                  the access token.
    
                
    
                (2) Add a request parameter to identify the access token
                issuer.
    
              
    
              (3) Separate protected resource endpoints for each
              authorization server.
    
              
    
            
    
            If there is a standard way, I'd like to know it.
    
            
    
          
    
          Best Regards,
    
        
    
        Takahiko Kawasaki
    
        
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
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
    


    


    =

--Apple-Mail=_FDA1EA28-9296-43B3-993D-FB7283B451E8--


From nobody Mon Mar 14 14:14:02 2016
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 83C5412D6C4 for ; Mon, 14 Mar 2016 14:14:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 WYNlELTyE4Y5 for ; Mon, 14 Mar 2016 14:13:57 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 0571712D789 for ; Mon, 14 Mar 2016 14:13:56 -0700 (PDT)
Received: by mail-qg0-x22a.google.com with SMTP id w104so165675280qge.1 for ; Mon, 14 Mar 2016 14:13:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=E9JvKwioSkP7Tlwn3eizpxXXSCDn6jF8XaJnhlgDeCs=; b=0qmmqknIe2W1rWTypGKnTX7G8ipwTx+ktBeiyFUtOrndBHhKAj5+cOZZ2/bCrv/R+o Wdp5yHKt9Xznz1ib4UC2h9N2OW2sWyoeKmPjmHIWouV0pEfQ8gwporYnU8Z8kxvcfGd2 f25MuSP4XJC+AqJgRbQyY8aWui5d4JQJMbHtNSSwhRzTVN5mQvTed3aa6bmDdCDuL+1B 2gqt4afcnSctDe8WvWWjVcGVPhQ5rvOkCXgOYPVXPzRg5294ju5RMJaeF34aCn4kXAUo Fi6DsEoUmlEglf84z739bO9IORr5d+Ny0pEDGfj3IOxBjk2BQjzUEJ+sbDrN7pC3Jciy z2RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=E9JvKwioSkP7Tlwn3eizpxXXSCDn6jF8XaJnhlgDeCs=; b=hQr6K0E+Vjy2pZtyZI9/a9KZ4AR6JYdiWqT0msZnatpJQriMSuSRKKBUwPq2trs5v1 wPwURtcTOnE7Hf5EYLiWmb+09MpbbgG0Tz1IgwUKsszY41OE9KgQbNo2BMd3DFJlsnX1 WUcmtMARr8FOJLOrd4WULomPRoykSnaATZCEue4xCA6EIemkxkx5D8WmHQ783VGszzvs e+NVODH1jlsYYMjsfI8GgrCuukc8qWIr0jIMBvJNMp4oIyD+Ldp+kqqwTX+CMRyttgj0 1TyqcJX/oQkMiOvaCNZQfCGhl4y37hABRLrkphJT866cbSt+/wFgg31lAlNztJuIGmik daMg==
X-Gm-Message-State: AD7BkJJvOttiy5v+FvEKWPJqV2KwahzwbGKlOHe/fTzLTPDDWrWS6VI+EztzaXBvBuCeEQ==
X-Received: by 10.140.18.163 with SMTP id 32mr32889707qgf.11.1457990035016; Mon, 14 Mar 2016 14:13:55 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.161.145]) by smtp.gmail.com with ESMTPSA id z130sm11124131qhc.28.2016.03.14.14.13.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Mar 2016 14:13:53 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_8A29B652-381E-4E63-AFC0-BFC9DD7A18D3"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 14 Mar 2016 18:13:49 -0300
Message-Id: <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>  
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 21:14:01 -0000

--Apple-Mail=_8A29B652-381E-4E63-AFC0-BFC9DD7A18D3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E2BAB3FA-4E08-4F65-A9C8-0529133E75AA"


--Apple-Mail=_E2BAB3FA-4E08-4F65-A9C8-0529133E75AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

We had two mandates.  One was to provide a spec for AS metadata.   The =
other was to mitigate the client mixup attack.  The request was to do =
the latter without requiring the former for clients that don=E2=80=99t =
otherwise need discovery.

Returning the issuer and client_id from the authorization endpoint and =
the client checking them can be done by the client without discovery.=20

Any client that has the resource and issuer hard coded probably =
doesn=E2=80=99t need discovery. =20
One of the things that a client will need discovery for is to find the =
RS, so requiring the client to know the RS URI before getting the AS =
config seems backwards to me.=20

Unless the client tells the AS where it intends to use the token we will =
be leaving a security hole because the bearer tokens will have too loose =
an audience if they have one at all.

True you are telling the AS (Webfinger service) what the RS is but that =
is not at a place that is useful in the token production process.

I also think there are use cases where the AS doesn=E2=80=99t know all =
the possible RS.   That is not something that a out of band check can =
address.
There are also cases where a token might be good at multiple RS =
endpoints intentionally.  In your solution the client would need to make =
a discovery request for each endpoint.
Those requests lack the context of who the client and resource owner =
are.  I think that will be a problem in some use cases.=20

If this is added to the token endpoint it would be checked when code or =
refresh are exchanged, not every time the token is used.  =20
With a out of band check the client would never know if a RS was =
removed/revoked.  =20

I don=E2=80=99t see checking when refreshing a token as something that =
is a huge burden.

If the server wants to do the check on it=E2=80=99s side then we could =
require the client to send the RS URI in the token request. that way you =
really know the client is not going to get a token for the wrong RS =
endpoint.
If you check out of band in discovery you really have no idea if the =
client is checking.

John B.
=20


> On Mar 14, 2016, at 3:56 PM, Phil Hunt  wrote:
>=20
> Thanks to Mike and John for their feedback.  I=E2=80=99ll take each in =
turn:
>=20
> Mike,
>=20
> Regarding your suggested amendments
>=20
> Item 1: Returning the config URL would create two problems. One,it =
makes bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations). =20
>=20
> The two-step process allows the current discovery process to continue. =
I disagree with this. This is why I put forward an =E2=80=9Calternate" =
draft that is almost the same but simply adds the check before returning =
the configuration data.  I worry that  developers would have no =
incentive to do the two-step approach. They would just start at step 2 =
which in turn puts AS=E2=80=99s at risk of exposing tokens because it =
works. This makes OAuth promiscuous.
>=20
> Regarding existing implementations. Most of those implementations are =
for OIDC.  I think it makes sense for OIDF to continue use of OIDC's =
discovery spec because the UserInfo endpoint is well defined and the =
likelihood of a client mis-informed about the resource endpoint is not =
there.  IMO This does not apply to the broader OAuth community.
>=20
> Item 2:  It may be appropriate to have a separate configuration =
registry specification, but I think we should hold off until we have a =
complete solution and then make the decision what drafts should exist =
and how many pieces.  A big concern is the perceived complexity of =
multiple solutions and multiple drafts.
>=20
> As to John Bradley=E2=80=99s comments:
>=20
> Re: Discovery is the wrong place to mitigate threats.=20
> I=E2=80=99m confused by this.  Our mandate was to solve a security =
threat by having a discovery specification to prevent clients being =
mis-lead about endpoints (of which resource service is one) in an oauth =
protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?
>=20
> Re: Your proposal for MITM mitigation
> You propose that instead the resource endpoint check should be in the =
oauth protocol itself.  The difference is that validation is transferred =
back to the client to get it right. As well, without the client =
informing the AS, I can=E2=80=99t see a way for the AS to know what =
endpoint the client is using.  The webfinger approach does this once and =
only requires that the host name be checked in many cases.
>=20
> As a principle, the members have discussed many times that the AS =
service should do validation when possible =E2=80=94 this was =
particularly true at the Germany meeting when this came up. This is why =
I prefer the client tell the service provider what it intends to do and =
the service provider can fail that request immediately if necessary. We =
don=E2=80=99t have to depend on the developer getting the spec correct =
to fail the correct way.
>=20
> I worry that adding more parameters to the authz and token protocol =
flows increases complexity and attack surface. It also means per =
authorization validation has to take place vs. a one-time validation at =
config time.  Placing it in the configuration lookup phase (whether via =
web finger or just a special OAuth endpoint) seems more appropriate and =
far less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D
>=20
> That said, it may be that when we consider all the use cases, some =
combination of AS protocol and discovery may be both needed. I=E2=80=99m =
not ready to make conclusions about this.  The current oauth-discovery =
spec seems to put future generic clients at risk and that is my primary =
concern.
>=20
> Best Regards,
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 13, 2016, at 10:28 PM, Mike Jones > wrote:
>>=20
>> Thanks for posting this, Phil.  It provides a concrete example of a =
way that protected resource discovery could be added to authorization =
server metadata discovery, and as such, should provide useful input for =
working group discussions on this topic.  It=E2=80=99s always great when =
someone takes the time to write an actual draft that can be examined and =
implemented, and I appreciate you doing that.
>> =20
>> The content of your draft points out that there appears to be =
complete agreement on what the authorization server metadata format =
should be, which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests that the =
authorization server metadata definitions in draft-ietf-oauth-discovery =
(which is now the whole normative content of the draft) are clearly =
ready for standardization, since even your alternative proposal includes =
them verbatim.
>> =20
>> Reading your draft, the problem I have with it is that you are =
returning the AS metadata only as a WebFinger response, rather than as =
an https-protected resource published by the authorization server.  The =
choice to only return this via WebFinger makes your draft incompatible =
with most deployed implementations of OAuth metadata, including the 22 =
implementations using it listed athttp://openid.net/certification/ =
 (see the =E2=80=9COP Config=E2=80=9D =
column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D library, which uses the metadata path for client =
configuration.=C2=A0 Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do. <>
>> =20
>> Therefore, I would request that you make these minor revisions to =
your draft and republish, so as to provide a unified way forward that is =
compatible with all known existing OAuth Discovery deployments:
>> 1.       Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D to have the WebFinger request return the =
issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D=
 value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
>> 2.       Reference the metadata definitions from Section 2 of =
draft-ietf-oauth-discovery, rather than duplicating them in your Section =
3.
>> =20
>> That would have the advantage of paring your draft down to only the =
new things that it proposes, enabling them to be more clearly understood =
and evaluated on their own merits.  I look forward to the discussions of =
ways of performing additional kinds of OAuth discovery, and consider =
your draft a valuable input to those discussions.
>> =20
>>                                                           Best =
wishes,
>>                                                           -- Mike
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of John Bradley
>> Sent: Sunday, March 13, 2016 6:45 PM
>> To: Phil Hunt >
>> Cc: oauth >
>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>> =20
>> As I have told Phil off list. =20
>> =20
>> Discovery is the wrong place to try and provide security against man =
in the middle attacks on the RS.
>> =20
>> This requires the client to know what the RS URI is before retrieving =
the information on the AS Configuration.
>> =20
>> The proposal Mike and I have been working on requires the client to =
have a notion of what API it is looking for and retrieve the .well-known =
file for that API from the issuer.   That allows a protocol like Connect =
to register its own config file that can point to the RS.  =20
>> =20
>> If the API specific well known is not available the client can try =
the default oauth-server one.
>> =20
>> That then allows us to deal with restricting where AT are presented =
as part of the protocol rather then dragging discovery in as a =
requirement.
>> =20
>> In my opinion the resource the token is targeted to should be =
separated from the scope and returned as part of the meta-data about the =
AT along with scopes granted and expiry time.   We should also have a =
input parameter for resources so that a client can restrict tokens =
issued to a subset of the ones granted by the refresh token.   It would =
then also be possible to ask a AS for a token for a unregistered RS and =
have the AS produce a JWT access token with the resource as an audience =
if policy allows.
>> =20
>> That however was supposed to be dealt with as part of the mixed up =
client set of mitigations. =20
>> In that the goal was to mitigate the attacks by returning meta-data =
about the tokens, and not to require discovery.
>> =20
>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=9D=
 for the code, and I intend to discuss at the F2F returning resource for =
AT as well.
>> =20
>> Those mitigate the attack. =20
>> =20
>> I will continue to resist mixing up discovery of configuration =
meta-data with mitigation of the attacks.
>> =20
>> We return meta-data about the tokens now, because AT are opaque to =
the client, we neglected to include some of the information for the =
client needs to be secure.   We just need to add that in to the existing =
flows.
>> =20
>> While Phil=E2=80=99s proposal is easier for the AS to implement as an =
add on, it puts more of a burden on the client needing to potentially =
change how it stores the relationships between AS and RS to prevent =
compromise, I think the solution should be biased towards simplicity on =
the client side.
>> =20
>> If we return the resources as part of the existing meta data the =
client checks that against the resource it intends to send the token to =
and if it is not in the list then it can=E2=80=99t send the token.  =
Simple check every time it gets a new AT, no optionality.
>> =20
>> I am not saying anything new Nat has been advocating basically this =
for some time, and dis submit a draft.   I prefer to return the info in =
the existing format rather than as link headers,  but that is the =
largest difference between what Nat and I are saying with respect to =
resource.
>> =20
>> That is the core of my problem with Phil=E2=80=99s draft.
>> =20
>> I guess we will need to have a long conversation in BA.
>> =20
>> Regards
>> John B.
>> =20
>> On Mar 13, 2016, at 8:12 PM, Phil Hunt > wrote:
>> =20
>> This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry for =
OAuth Config Metadata as the authors believe that both solutions are not =
required, or depending on WG discussion they will be merged. The intent =
is to provide a simple complete draft for consideration.
>> =20
>> How it works...
>> Given that a client has previously discovered an OAuth protected =
resource, the bound configuration method allows a client to return the =
configuration for an oauth authorization server that can issue tokens =
for the resource URI specified by the client.  The AS is not required to =
be in the same domain.  The AS is however required to know if it can =
issue tokens for a resource service (which presumes some agreement =
exists on tokens etc).
>> =20
>> The draft does not require that the resource exist (e.g. for =
unconfigured or new user based resources). It only requires that the AS =
service provider agrees it can issue tokens.
>> =20
>> =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.
>> =20
>> I propose that the WG consider the alternate draft carefully as well =
as other submissions and evaluate the broader discovery problem before =
proceeding with WGLC on OAuth Discovery.
>> =20
>> Thanks!
>> =20
>> Phil
>> =20
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>> =20
>>=20
>>=20
>> Begin forwarded message:
>> =20
>> From: internet-drafts@ietf.org 
>> Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>> Date: March 13, 2016 at 3:53:37 PM PDT
>> To: "Phil Hunt" >, =
"Anthony Nadalin" >, "Tony Nadalin" >
>> =20
>>=20
>> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>> has been successfully submitted by Phil Hunt and posted to the
>> IETF repository.
>>=20
>> Name:             draft-hunt-oauth-bound-config
>> Revision:         00
>> Title:               OAuth 2.0 Bound Configuration Lookup
>> Document date:          2016-03-13
>> Group:             Individual Submission
>> Pages:              22
>> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =

>> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =

>>=20
>>=20
>> Abstract:
>>   This specification defines a mechanism for the client of an OAuth =
2.0
>>   protected resource service to obtain the configuration details of =
an
>>   OAuth 2.0 authorization server that is capable of authorizing =
access
>>   to a specific resource service.  The information includes the OAuth
>>   2.0 component endpoint location URIs and as well as authorization
>>   server capabilities.
>>=20
>>=20
>>=20
>>=20
>> 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 =
.
>>=20
>> The IETF Secretariat
>>=20
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =



--Apple-Mail=_E2BAB3FA-4E08-4F65-A9C8-0529133E75AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

We had two mandates.  One was to provide a spec for AS =
metadata.   The other was to mitigate the client mixup attack. =
 The request was to do the latter without requiring the former for =
clients that don=E2=80=99t otherwise need discovery.

    Returning the issuer and client_id from =
the authorization endpoint and the client checking them can be done by =
the client without discovery. 

    Any client that has the resource and =
issuer hard coded probably doesn=E2=80=99t need discovery. =
 
    One of the things that a client will need =
discovery for is to find the RS, so requiring the client to know the RS =
URI before getting the AS config seems backwards to me. 

    Unless the client tells =
the AS where it intends to use the token we will be leaving a security =
hole because the bearer tokens will have too loose an audience if they =
have one at all.

    True you are telling the AS (Webfinger service) what the RS =
is but that is not at a place that is useful in the token production =
process.

    I =
also think there are use cases where the AS doesn=E2=80=99t know all the =
possible RS.   That is not something that a out of band check can =
address.
    There are also cases where a token might =
be good at multiple RS endpoints intentionally.  In your solution =
the client would need to make a discovery request for each =
endpoint.
    Those requests lack the context of who =
the client and resource owner are.  I think that will be a problem =
in some use cases. 

    If this is added to the token endpoint it would be checked =
when code or refresh are exchanged, not every time the token is used. =
  
    With a out of band check the client =
would never know if a RS was removed/revoked.   

    I don=E2=80=99t see =
checking when refreshing a token as something that is a huge =
burden.

    If the =
server wants to do the check on it=E2=80=99s side then we could require =
the client to send the RS URI in the token request. that way you really =
know the client is not going to get a token for the wrong RS =
endpoint.
    If you check out of band in discovery you =
really have no idea if the client is checking.

    John B.
     


    On Mar 14, 2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    Thanks to Mike and John for their feedback.  I=E2=80=99ll =
take each in turn:

    Mike,

    Regarding your suggested =
amendments

    Item =
1: Returning the config URL would create two problems. One,it makes =
bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations).  

    The two-step process allows the current =
discovery process to continue. I disagree with this. This is why I put =
forward an =E2=80=9Calternate" draft that is almost the same but simply =
adds the check before returning the configuration data.  I worry =
that  developers would have no incentive to do the two-step =
approach. They would just start at step 2 which in turn puts AS=E2=80=99s =
at risk of exposing tokens because it works. This makes OAuth =
promiscuous.

    Regarding existing implementations. Most of those =
implementations are for OIDC.  I think it makes sense for OIDF to =
continue use of OIDC's discovery spec because the UserInfo endpoint is =
well defined and the likelihood of a client mis-informed about the =
resource endpoint is not there.  IMO This does not apply to the =
broader OAuth community.

    Item 2:  It may be appropriate to have a separate =
configuration registry specification, but I think we should hold off =
until we have a complete solution and then make the decision what drafts =
should exist and how many pieces.  A big concern is the perceived =
complexity of multiple solutions and multiple drafts.

    As to John Bradley=E2=80=99=
s comments:

    Re: =
Discovery is the wrong place to mitigate threats. 
    I=E2=80=99m confused by this.  Our mandate was to solve =
a security threat by having a discovery specification to prevent clients =
being mis-lead about endpoints (of which resource service is one) in an =
oauth protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?

    Re: Your proposal for MITM mitigation
    You =
propose that instead the resource endpoint check should be in the oauth =
protocol itself.  The difference is that validation is transferred =
back to the client to get it right. As well, without the client =
informing the AS, I can=E2=80=99t see a way for the AS to know what =
endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many =
cases.

    As a =
principle, the members have discussed many times that the AS service =
should do validation when possible =E2=80=94 this was particularly true =
at the Germany meeting when this came up. This is why I prefer the =
client tell the service provider what it intends to do and the service =
provider can fail that request immediately if necessary. We don=E2=80=99t =
have to depend on the developer getting the spec correct to fail the =
correct way.

    I =
worry that adding more parameters to the authz and token protocol flows =
increases complexity and attack surface. It also means per authorization =
validation has to take place vs. a one-time validation at config time. =
 Placing it in the configuration lookup phase (whether via web =
finger or just a special OAuth endpoint) seems more appropriate and far =
less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D

    That said, it may be that when we =
consider all the use cases, some combination of AS protocol and =
discovery may be both needed. I=E2=80=99m not ready to make conclusions =
about this.  The current oauth-discovery spec seems to put future =
generic clients at risk and that is my primary concern.

    Best Regards,

    




    

    

    On Mar 13, 2016, at 10:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

    Thanks for posting this, Phil.  It provides a concrete =
example of a way that protected resource discovery could be added to =
authorization server metadata discovery, and as such, should provide =
useful input for working group discussions on this topic.  It=E2=80=99=
s always great when someone takes the time to write an actual draft that =
can be examined and implemented, and I appreciate you doing that.
     
    The =
content of your draft points out that there appears to be complete =
agreement on what the authorization server metadata format should be, =
which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests =
that the authorization server metadata definitions in =
draft-ietf-oauth-discovery (which is now the whole normative content of =
the draft) are clearly ready for standardization, since even your =
alternative proposal includes them verbatim.
     
    Reading your draft, the problem I have with it is that you =
are returning the AS metadata only as a WebFinger response, rather than =
as an https-protected resource published by the authorization =
server.  The choice to only return this via WebFinger makes your =
draft incompatible with most deployed implementations of OAuth metadata, =
including the 22 implementations using it listed athttp://openid.net/certification/ (see the =E2=80=9COP =
Config=E2=80=9D column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CADAL=E2=
=80=9D library, which uses the metadata path for client =
configuration.  Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do.
     
    Therefore, I =
would request that you make these minor revisions to your draft and =
republish, so as to provide a unified way forward that is compatible =
with all known existing OAuth Discovery deployments:
    1.       Modify your section 2 =E2=80=9CAuthorization =
Server WebFinger Discovery=E2=80=9D to have the WebFinger request return =
the issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=
=80=9D value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
    2.       Reference the metadata definitions from =
Section 2 of draft-ietf-oauth-discovery, rather than duplicating them in =
your Section 3.
     
    That would have the advantage of paring your draft down to =
only the new things that it proposes, enabling them to be more clearly =
understood and evaluated on their own merits.  I look forward to =
the discussions of ways of performing additional kinds of OAuth =
discovery, and consider your draft a valuable input to those =
discussions.
     
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          Best =
wishes,
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
    Sent: Sunday, March 13, 2016 6:45 =
PM
    To: Phil Hunt <phil.hunt@oracle.com>
    Cc: oauth=
 <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    As I have told Phil off list.  
     
    Discovery is the wrong place to try and =
provide security against man in the middle attacks on the RS.
     
    This requires the client to know what the =
RS URI is before retrieving the information on the AS Configuration.
     
    The proposal Mike and I have been working =
on requires the client to have a notion of what API it is looking for =
and retrieve the .well-known file for that API from the issuer.   =
That allows a protocol like Connect to register its own config file that =
can point to the RS.   
     
    If the API specific well known is not available the =
client can try the default oauth-server one.
     
    That then allows us to deal with =
restricting where AT are presented as part of the protocol rather then =
dragging discovery in as a requirement.
     
    In my opinion the resource the token is =
targeted to should be separated from the scope and returned as part of =
the meta-data about the AT along with scopes granted and expiry time. =
  We should also have a input parameter for resources so that a =
client can restrict tokens issued to a subset of the ones granted by the =
refresh token.   It would then also be possible to ask a AS for a =
token for a unregistered RS and have the AS produce a JWT access token =
with the resource as an audience if policy allows.
     
    That however was supposed to be dealt =
with as part of the mixed up client set of mitigations.  
    In that the goal was to mitigate the attacks by returning =
meta-data about the tokens, and not to require discovery.
     
    We intend to return =E2=80=9Ciss=E2=80=9D =
and =E2=80=9Ccleint_id=E2=80=9D for the code, and I intend to discuss at =
the F2F returning resource for AT as well.
     
    Those mitigate the attack.  
     
    I will continue to resist mixing up =
discovery of configuration meta-data with mitigation of the attacks.
     
    We return meta-data about the tokens now, =
because AT are opaque to the client, we neglected to include some of the =
information for the client needs to be secure.   We just need to =
add that in to the existing flows.
     
    While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add on, it puts more of a burden on the client needing =
to potentially change how it stores the relationships between AS and RS =
to prevent compromise, I think the solution should be biased towards =
simplicity on the client side.
     
    If we return the resources as part of the existing =
meta data the client checks that against the resource it intends to send =
the token to and if it is not in the list then it can=E2=80=99t send the =
token.  Simple check every time it gets a new AT, no =
optionality.
     
    I am not saying anything new Nat has been advocating =
basically this for some time, and dis submit a draft.   I prefer to =
return the info in the existing format rather than as link headers, =
 but that is the largest difference between what Nat and I are =
saying with respect to resource.
     
    That is the core of my problem with Phil=E2=80=99s =
draft.
     
    I guess we will need to have a long conversation in =
BA.
     
    Regards
    John B.
     
    On =
Mar 13, 2016, at 8:12 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
     
    This draft is a =
proposed alternate proposal for draft-ietf-oauth-discovery.  As =
such, it contains the same registry for OAuth Config Metadata as the =
authors believe that both solutions are not required, or depending on WG =
discussion they will be merged. The intent is to provide a simple =
complete draft for consideration.
     
    How it works...
    Given that a client =
has previously discovered an OAuth protected resource, the bound =
configuration method allows a client to return the configuration for an =
oauth authorization server that can issue tokens for the resource URI =
specified by the client.  The AS is not required to be in the same =
domain.  The AS is however required to know if it can issue tokens =
for a resource service (which presumes some agreement exists on tokens =
etc).
     
    The draft does not require that the resource exist =
(e.g. for unconfigured or new user based resources). It only requires =
that the AS service provider agrees it can issue tokens.
     
    =46rom a security perspective, returning =
the OAuth service configuration for a specified resource URI serves to =
confirm the client is in possession of a valid resource URI ensuring the =
client has received a valid set of endpoints for the resource and the =
associated oauth services.
     
    I propose that the WG consider the alternate draft =
carefully as well as other submissions and evaluate the broader =
discovery problem before proceeding with WGLC on OAuth Discovery.
     
    Thanks!
     
    Phil
     
    @independentid
    www.independentid.com
     


    Begin forwarded message:
     
    Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
    Date: March 13, 2016 =
at 3:53:37 PM PDT
    To: "Phil Hunt" =
<phil.hunt@yahoo.com>, =
"Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>
     

    A new version of =
I-D, draft-hunt-oauth-bound-config-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:        &=
nbsp;    draft-hunt-oauth-bound=
-config
    Revision:        <=
span class=3D"Apple-converted-space"> 00
    Title:        &=
nbsp;      OAuth 2.0 Bound =
Configuration Lookup
    Document date:        &=
nbsp; 2016-03-13
    Group:        &=
nbsp;    Individual =
Submission
    Pages:        &=
nbsp;     22
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

    Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


    Abstract:
      This specification defines a mechanism for the =
client of an OAuth 2.0
      protected resource =
service to obtain the configuration details of an
      OAuth 2.0 authorization server that is capable of =
authorizing access
      to a specific resource =
service.  The information includes the OAuth
      2.0 component endpoint location URIs and as well =
as authorization
      server capabilities.




    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.

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


    =

--Apple-Mail=_E2BAB3FA-4E08-4F65-A9C8-0529133E75AA--

--Apple-Mail=_8A29B652-381E-4E63-AFC0-BFC9DD7A18D3
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTQyMTEzNTBaMCMGCSqGSIb3DQEJBDEWBBTmUtVqJc5uhYoI2X216Ri8
dJdqBjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBuNKAo4kvzmc+C+4mdTA7hkYHX2Cvp2gKIcs9YykCkmaCa6lJea0M0
pz0QJZM7IzEk3Kt7gJIeToftFPMxTtTJxpy9iQTJi7XQtU8JHfokju+q8I4TiwP03kOFC1tX69za
ElQyezhA0WHrHUhz/Xz2LjF84Q+5F0Ult9iQ7YLtbty8q4WKCT6mRWp8lxIcPHrGeKvaWmRC83nV
xfh6ioVCDE/IWfBaYIpngjKA0BDhyyrXoC1ohP85mCxOCwxyr3TgtZ3/ur2orTnPYf3Vmq7WHQVO
V69YLFWfDAhieIBJpkNTJ205kB2Jdd/r1AcKlsYuMOmWfwNuYFzrdvDiYEjAAAAAAAAA
--Apple-Mail=_8A29B652-381E-4E63-AFC0-BFC9DD7A18D3--


From nobody Mon Mar 14 15:17:26 2016
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 C1C3112D7AA for ; Mon, 14 Mar 2016 15:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 yIV0hmJYjix3 for ; Mon, 14 Mar 2016 15:17:20 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 ED50F12D6BC for ; Mon, 14 Mar 2016 15:17:19 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2EMHHQ6012609 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Mar 2016 22:17:18 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2EMHH4C006593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Mar 2016 22:17:17 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2EMHEZa011923; Mon, 14 Mar 2016 22:17:15 GMT
Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Mar 2016 15:17:13 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-84288AA3-CFA8-449C-AE75-53E0FC95FF3B
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>
Date: Mon, 14 Mar 2016 15:17:11 -0700
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>
To: John Bradley 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 22:17:24 -0000

--Apple-Mail-84288AA3-CFA8-449C-AE75-53E0FC95FF3B
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Inline

Phil

> On Mar 14, 2016, at 14:13, John Bradley  wrote:
>=20
> We had two mandates.  One was to provide a spec for AS metadata.   The oth=
er was to mitigate the client mixup attack.  The request was to do the latte=
r without requiring the former for clients that don=E2=80=99t otherwise need=
 discovery.
There is no mandate for any of this. See http://tools.ietf.org/wg/oauth/char=
ters?item=3Dcharter-oauth-2016-01-22.txt
>=20
> Returning the issuer and client_id from the authorization endpoint and the=
 client checking them can be done by the client without discovery.=20

How does this address the issue of whether the client is talking to the wron=
g endpoint?
>=20
> Any client that has the resource and issuer hard coded probably doesn=E2=80=
=99t need discovery. =20
We agree


> One of the things that a client will need discovery for is to find the RS,=
 so requiring the client to know the RS URI before getting the AS config see=
ms backwards to me.=20
How can you make an assumption on order? You seem to be conflating authentic=
ation with authorization by assuming the identity drives what the resource i=
s.=20

There are lots of applications that require user rights but are not identify=
 centric. For example a document service.=20
>=20
> Unless the client tells the AS where it intends to use the token we will b=
e leaving a security hole because the bearer tokens will have too loose an a=
udience if they have one at all.
This is the biggest risk we have IMHO.=20
>=20
> True you are telling the AS (Webfinger service) what the RS is but that is=
 not at a place that is useful in the token production process.

This has nothing to do with token production.=20

What we want to ensure is whether an honest client is correctly configured a=
nd has not been mislead - eg by a phishing page.=20
>=20
> I also think there are use cases where the AS doesn=E2=80=99t know all the=
 possible RS.   That is not something that a out of band check can address.

May be. Lets identify them.=20

> There are also cases where a token might be good at multiple RS endpoints i=
ntentionally.

>  In your solution the client would need to make a discovery request for ea=
ch endpoint.
Sure. Otherwise how would it know if there is one AS or a pool of AS servers=
 assigned to each instance?
> Those requests lack the context of who the client and resource owner are. =
 I think that will be a problem in some use cases.=20

Not sure I agree. This is about discovering a valid set of endpoints. For mi=
tm, we mainly want to check the hostname is correct. If a client chooses evi=
l.com the cert can be valid and TLS will pass. How does it otherwise know it=
 is supposed to talk to res.example.com?
>=20
> If this is added to the token endpoint it would be checked when code or re=
fresh are exchanged, not every time the token is used.  =20
Your proposal requires rhe client to check. I am not clear how the AS can kn=
ow the exact uri. It is far easier to validate than to lookup since as you s=
ay the client may be authorized to use multiple ASs.=20
> With a out of band check the client would never know if a RS was removed/r=
evoked. =20

Not sure that is in scope.=20

None of the current proposals address this issue.=20
> =20
>=20
> I don=E2=80=99t see checking when refreshing a token as something that is a=
 huge burden.

Still its a lot more than once.=20

Why don't you draft another alternative?
>=20
> If the server wants to do the check on it=E2=80=99s side then we could req=
uire the client to send the RS URI in the token request. that way you really=
 know the client is not going to get a token for the wrong RS endpoint.
> If you check out of band in discovery you really have no idea if the clien=
t is checking.

In the new webfinger draft, the client isn't checking. The service provider s=
imply does not disclose oauth information to misconfigured clients.=20
>=20
> John B.
> =20
>=20
>=20
>> On Mar 14, 2016, at 3:56 PM, Phil Hunt  wrote:
>>=20
>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take each in tu=
rn:
>>=20
>> Mike,
>>=20
>> Regarding your suggested amendments
>>=20
>> Item 1: Returning the config URL would create two problems. One,it makes b=
ound discovery a two-step process - that adds complexity.  It seems far simp=
ler to mandate TLS (which I think it already does in the security considerat=
ions). =20
>>=20
>> The two-step process allows the current discovery process to continue. I d=
isagree with this. This is why I put forward an =E2=80=9Calternate" draft th=
at is almost the same but simply adds the check before returning the configu=
ration data.  I worry that  developers would have no incentive to do the two=
-step approach. They would just start at step 2 which in turn puts AS=E2=80=99=
s at risk of exposing tokens because it works. This makes OAuth promiscuous.=

>>=20
>> Regarding existing implementations. Most of those implementations are for=
 OIDC.  I think it makes sense for OIDF to continue use of OIDC's discovery s=
pec because the UserInfo endpoint is well defined and the likelihood of a cl=
ient mis-informed about the resource endpoint is not there.  IMO This does n=
ot apply to the broader OAuth community.
>>=20
>> Item 2:  It may be appropriate to have a separate configuration registry s=
pecification, but I think we should hold off until we have a complete soluti=
on and then make the decision what drafts should exist and how many pieces. =
 A big concern is the perceived complexity of multiple solutions and multipl=
e drafts.
>>=20
>> As to John Bradley=E2=80=99s comments:
>>=20
>> Re: Discovery is the wrong place to mitigate threats.=20
>> I=E2=80=99m confused by this.  Our mandate was to solve a security threat=
 by having a discovery specification to prevent clients being mis-lead about=
 endpoints (of which resource service is one) in an oauth protected exchange=
.  Maybe what you mean is we should not use .well-known of any kind and we s=
hould just create a =E2=80=9C/Config=E2=80=9D endpoint to OAuth?
>>=20
>> Re: Your proposal for MITM mitigation
>> You propose that instead the resource endpoint check should be in the oau=
th protocol itself.  The difference is that validation is transferred back t=
o the client to get it right. As well, without the client informing the AS, I=
 can=E2=80=99t see a way for the AS to know what endpoint the client is usin=
g.  The webfinger approach does this once and only requires that the host na=
me be checked in many cases.
>>=20
>> As a principle, the members have discussed many times that the AS service=
 should do validation when possible =E2=80=94 this was particularly true at t=
he Germany meeting when this came up. This is why I prefer the client tell t=
he service provider what it intends to do and the service provider can fail t=
hat request immediately if necessary. We don=E2=80=99t have to depend on the=
 developer getting the spec correct to fail the correct way.
>>=20
>> I worry that adding more parameters to the authz and token protocol flows=
 increases complexity and attack surface. It also means per authorization va=
lidation has to take place vs. a one-time validation at config time.  Placin=
g it in the configuration lookup phase (whether via web finger or just a spe=
cial OAuth endpoint) seems more appropriate and far less complex - as the re=
quest itself is simple and has only one parameter. Here we are not considere=
d about legitimacy of the client. we=E2=80=99re just concerned with the issu=
e "has the client been correctly informed?=E2=80=9D
>>=20
>> That said, it may be that when we consider all the use cases, some combin=
ation of AS protocol and discovery may be both needed. I=E2=80=99m not ready=
 to make conclusions about this.  The current oauth-discovery spec seems to p=
ut future generic clients at risk and that is my primary concern.
>>=20
>> Best Regards,
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 13, 2016, at 10:28 PM, Mike Jones  w=
rote:
>>>=20
>>> Thanks for posting this, Phil.  It provides a concrete example of a way t=
hat protected resource discovery could be added to authorization server meta=
data discovery, and as such, should provide useful input for working group d=
iscussions on this topic.  It=E2=80=99s always great when someone takes the t=
ime to write an actual draft that can be examined and implemented, and I app=
reciate you doing that.
>>> =20
>>> The content of your draft points out that there appears to be complete a=
greement on what the authorization server metadata format should be, which i=
s great!  I=E2=80=99ll note that Section 3 of draft-hunt-oauth-bound-config-=
00 titled =E2=80=9CAuthorization Server Metadata=E2=80=9D is an exact copy o=
f Section 2 of draft-ietf-oauth-discovery-01 (with the same title), modulo a=
pplying a correction suggested by the working group.  To me this suggests th=
at the authorization server metadata definitions in draft-ietf-oauth-discove=
ry (which is now the whole normative content of the draft) are clearly ready=
 for standardization, since even your alternative proposal includes them ver=
batim.
>>> =20
>>> Reading your draft, the problem I have with it is that you are returning=
 the AS metadata only as a WebFinger response, rather than as an https-prote=
cted resource published by the authorization server.  The choice to only ret=
urn this via WebFinger makes your draft incompatible with most deployed impl=
ementations of OAuth metadata, including the 22 implementations using it lis=
ted athttp://openid.net/certification/ (see the =E2=80=9COP Config=E2=80=9D c=
olumn in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=
=9CADAL=E2=80=9D library, which uses the metadata path for client configurat=
ion.  Without having ASs provide the metadata as an https-protected resource=
, implementations such as ADAL can=E2=80=99t use it for client configuration=
 as the currently do.
>>> =20
>>> Therefore, I would request that you make these minor revisions to your d=
raft and republish, so as to provide a unified way forward that is compatibl=
e with all known existing OAuth Discovery deployments:
>>> 1.       Modify your section 2 =E2=80=9CAuthorization Server WebFinger D=
iscovery=E2=80=9D to have the WebFinger request return the issuer identifier=
 for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, rather th=
an returning the metadata values by value as the =E2=80=9Cproperties=E2=80=9D=
 value.
>>> 2.       Reference the metadata definitions from Section 2 of draft-ietf=
-oauth-discovery, rather than duplicating them in your Section 3.
>>> =20
>>> That would have the advantage of paring your draft down to only the new t=
hings that it proposes, enabling them to be more clearly understood and eval=
uated on their own merits.  I look forward to the discussions of ways of per=
forming additional kinds of OAuth discovery, and consider your draft a valua=
ble input to those discussions.
>>> =20
>>>                                                           Best wishes,
>>>                                                           -- Mike
>>> =20
>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
>>> Sent: Sunday, March 13, 2016 6:45 PM
>>> To: Phil Hunt 
>>> Cc: oauth 
>>> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bo=
und-config-00.txt
>>> =20
>>> As I have told Phil off list. =20
>>> =20
>>> Discovery is the wrong place to try and provide security against man in t=
he middle attacks on the RS.
>>> =20
>>> This requires the client to know what the RS URI is before retrieving th=
e information on the AS Configuration.
>>> =20
>>> The proposal Mike and I have been working on requires the client to have=
 a notion of what API it is looking for and retrieve the .well-known file fo=
r that API from the issuer.   That allows a protocol like Connect to registe=
r its own config file that can point to the RS.  =20
>>> =20
>>> If the API specific well known is not available the client can try the d=
efault oauth-server one.
>>> =20
>>> That then allows us to deal with restricting where AT are presented as p=
art of the protocol rather then dragging discovery in as a requirement.
>>> =20
>>> In my opinion the resource the token is targeted to should be separated f=
rom the scope and returned as part of the meta-data about the AT along with s=
copes granted and expiry time.   We should also have a input parameter for r=
esources so that a client can restrict tokens issued to a subset of the ones=
 granted by the refresh token.   It would then also be possible to ask a AS f=
or a token for a unregistered RS and have the AS produce a JWT access token w=
ith the resource as an audience if policy allows.
>>> =20
>>> That however was supposed to be dealt with as part of the mixed up clien=
t set of mitigations. =20
>>> In that the goal was to mitigate the attacks by returning meta-data abou=
t the tokens, and not to require discovery.
>>> =20
>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=9D=
 for the code, and I intend to discuss at the F2F returning resource for AT a=
s well.
>>> =20
>>> Those mitigate the attack. =20
>>> =20
>>> I will continue to resist mixing up discovery of configuration meta-data=
 with mitigation of the attacks.
>>> =20
>>> We return meta-data about the tokens now, because AT are opaque to the c=
lient, we neglected to include some of the information for the client needs t=
o be secure.   We just need to add that in to the existing flows.
>>> =20
>>> While Phil=E2=80=99s proposal is easier for the AS to implement as an ad=
d on, it puts more of a burden on the client needing to potentially change h=
ow it stores the relationships between AS and RS to prevent compromise, I th=
ink the solution should be biased towards simplicity on the client side.
>>> =20
>>> If we return the resources as part of the existing meta data the client c=
hecks that against the resource it intends to send the token to and if it is=
 not in the list then it can=E2=80=99t send the token.  Simple check every t=
ime it gets a new AT, no optionality.
>>> =20
>>> I am not saying anything new Nat has been advocating basically this for s=
ome time, and dis submit a draft.   I prefer to return the info in the exist=
ing format rather than as link headers,  but that is the largest difference b=
etween what Nat and I are saying with respect to resource.
>>> =20
>>> That is the core of my problem with Phil=E2=80=99s draft.
>>> =20
>>> I guess we will need to have a long conversation in BA.
>>> =20
>>> Regards
>>> John B.
>>> =20
>>> On Mar 13, 2016, at 8:12 PM, Phil Hunt  wrote:
>>> =20
>>> This draft is a proposed alternate proposal for draft-ietf-oauth-discove=
ry.  As such, it contains the same registry for OAuth Config Metadata as the=
 authors believe that both solutions are not required, or depending on WG di=
scussion they will be merged. The intent is to provide a simple complete dra=
ft for consideration.
>>> =20
>>> How it works...
>>> Given that a client has previously discovered an OAuth protected resourc=
e, the bound configuration method allows a client to return the configuratio=
n for an oauth authorization server that can issue tokens for the resource U=
RI specified by the client.  The AS is not required to be in the same domain=
.  The AS is however required to know if it can issue tokens for a resource s=
ervice (which presumes some agreement exists on tokens etc).
>>> =20
>>> The draft does not require that the resource exist (e.g. for unconfigure=
d or new user based resources). It only requires that the AS service provide=
r agrees it can issue tokens.
>>> =20
>>> =46rom a security perspective, returning the OAuth service configuration=
 for a specified resource URI serves to confirm the client is in possession o=
f a valid resource URI ensuring the client has received a valid set of endpo=
ints for the resource and the associated oauth services.
>>> =20
>>> I propose that the WG consider the alternate draft carefully as well as o=
ther submissions and evaluate the broader discovery problem before proceedin=
g with WGLC on OAuth Discovery.
>>> =20
>>> Thanks!
>>> =20
>>> Phil
>>> =20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>> =20
>>>=20
>>>=20
>>> Begin forwarded message:
>>> =20
>>> From: internet-drafts@ietf.org
>>> Subject: New Version Notification for draft-hunt-oauth-bound-config-00.t=
xt
>>> Date: March 13, 2016 at 3:53:37 PM PDT
>>> To: "Phil Hunt" , "Anthony Nadalin" , "Tony Nadalin" 
>>> =20
>>>=20
>>> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>>> has been successfully submitted by Phil Hunt and posted to the
>>> IETF repository.
>>>=20
>>> Name:             draft-hunt-oauth-bound-config
>>> Revision:         00
>>> Title:               OAuth 2.0 Bound Configuration Lookup
>>> Document date:          2016-03-13
>>> Group:             Individual Submission
>>> Pages:              22
>>> URL:            https://www.ietf.org/internet-drafts/draft-hunt-oauth-bo=
und-config-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-=
config/
>>> Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-confi=
g-00
>>>=20
>>>=20
>>> Abstract:
>>>   This specification defines a mechanism for the client of an OAuth 2.0
>>>   protected resource service to obtain the configuration details of an
>>>   OAuth 2.0 authorization server that is capable of authorizing access
>>>   to a specific resource service.  The information includes the OAuth
>>>   2.0 component endpoint location URIs and as well as authorization
>>>   server capabilities.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of submis=
sion
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> The IETF Secretariat
>>>=20
>>> =20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-84288AA3-CFA8-449C-AE75-53E0FC95FF3B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Inline

    Phil

    On Ma=
r 14, 2016, at 14:13, John Bradley <=
ve7jtb@ve7jtb.com> wrote:

    We h=
ad two mandates.  One was to provide a spec for AS metadata.   The=
 other was to mitigate the client mixup attack.  The request was to do t=
he latter without requiring the former for clients that don=E2=80=99t otherw=
ise need discovery.
    There is no mandate for any of this. S=
ee http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-o=
auth-2016-01-22.txt
    Returning the issuer and client_id from t=
he authorization endpoint and the client checking them can be done by the cl=
ient without discovery. 

    How doe=
s this address the issue of whether the client is talking to the wrong endpo=
int?

    =

    Any client that has the resource and issuer hard coded proba=
bly doesn=E2=80=99t need discovery.  
    We agree<=
div>

    One of=
 the things that a client will need discovery for is to find the RS, so requ=
iring the client to know the RS URI before getting the AS config seems backw=
ards to me. 
    How can you make an assumption on o=
rder? You seem to be conflating authentication with authorization by assumin=
g the identity drives what the resource is. 

    T=
here are lots of applications that require user rights but are not identify c=
entric. For example a document service. 
    <=
div>

    Unless the client t=
ells the AS where it intends to use the token we will be leaving a security h=
ole because the bearer tokens will have too loose an audience if they have o=
ne at all.
    This is the biggest risk we have IMHO.&nb=
sp;

    <=
div class=3D"">True you are telling the AS (Webfinger service) what the RS i=
s but that is not at a place that is useful in the token production process.=


    This has nothing to do with token pr=
oduction. 

    What we want to ensure is whether a=
n honest client is correctly configured and has not been mislead - eg by a p=
hishing page. 

    I also think there are use cases where the AS=
 doesn=E2=80=99t know all the possible RS.   That is not something that=
 a out of band check can address.

    May be. Lets i=
dentify them. 

    There are also cases where a token might be good at multiple RS endpoints=
 intentionally.

    <=
div class=3D""> In your solution the client would need to make a discov=
ery request for each endpoint.
    Sure. Otherwise how w=
ould it know if there is one AS or a pool of AS servers assigned to each ins=
tance?
    Those requests lack=
 the context of who the client and resource owner are.  I think that wi=
ll be a problem in some use cases. 

    Not sure I agree. This is about discovering a valid set of endpoints. Fo=
r mitm, we mainly want to check the hostname is correct. If a client chooses=
 evil.com the cert can be valid and TLS will=
 pass. How does it otherwise know it is supposed to talk to res.example.com?

    If this is added to the t=
oken endpoint it would be checked when code or refresh are exchanged, not ev=
ery time the token is used.   
    Your propos=
al requires rhe client to check. I am not clear how the AS can know the exac=
t uri. It is far easier to validate than to lookup since as you say the clie=
nt may be authorized to use multiple ASs. 
    With a out of band check the client would never know i=
f a RS was removed/revoked.  

    No=
t sure that is in scope. 

    None of the current p=
roposals address this issue. 
     

    I d=
on=E2=80=99t see checking when refreshing a token as something that is a hug=
e burden.

    Still its a lot more than o=
nce. 

    Why don't you draft another alternative?=


    If the server wants to do the check on it=E2=80=99s side then we=
 could require the client to send the RS URI in the token request. that way y=
ou really know the client is not going to get a token for the wrong RS endpo=
int.
    If you check out of band in discovery you really h=
ave no idea if the client is checking.

    In the new webfinger draft, the client isn't checking. The serv=
ice provider simply does not disclose oauth information to misconfigured cli=
ents. 

    John B.
     


    On Mar 14, 2016, at 3:56 PM, Phi=
l Hunt <phil.hunt@orac=
le.com> wrote:

    Thanks t=
o Mike and John for their feedback.  I=E2=80=99ll take each in turn:

    Mike,

    =

    Regarding your suggested amendments

    Item 1: Returning the config URL wou=
ld create two problems. One,it makes bound discovery a two-step process - th=
at adds complexity.  It seems far simpler to mandate TLS (which I think=
 it already does in the security considerations).  

    The two-step process allows the curre=
nt discovery process to continue. I disagree with this. This is why I put fo=
rward an =E2=80=9Calternate" draft that is almost the same but simply adds t=
he check before returning the configuration data.  I worry that  d=
evelopers would have no incentive to do the two-step approach. They would ju=
st start at step 2 which in turn puts AS=E2=80=99s at risk of exposing token=
s because it works. This makes OAuth promiscuous.

    Regarding existing implementations. Most of t=
hose implementations are for OIDC.  I think it makes sense for OIDF to c=
ontinue use of OIDC's discovery spec because the UserInfo endpoint is well d=
efined and the likelihood of a client mis-informed about the resource endpoi=
nt is not there.  IMO This does not apply to the broader OAuth communit=
y.

    Item 2:  I=
t may be appropriate to have a separate configuration registry specification=
, but I think we should hold off until we have a complete solution and then m=
ake the decision what drafts should exist and how many pieces.  A big c=
oncern is the perceived complexity of multiple solutions and multiple drafts=
.

    As to John Bradl=
ey=E2=80=99s comments:

    Re: Discovery is the wrong place to mitigate threats. 
    I=E2=80=99m confused by this.  Our mandate was to solve a secur=
ity threat by having a discovery specification to prevent clients being mis-=
lead about endpoints (of which resource service is one) in an oauth protecte=
d exchange.  Maybe what you mean is we should not use .well-known of an=
y kind and we should just create a =E2=80=9C/Config=E2=80=9D endpoint to OAu=
th?

    Re: Your propo=
sal for MITM mitigation
    You propose that instead the re=
source endpoint check should be in the oauth protocol itself.  The diff=
erence is that validation is transferred back to the client to get it right.=
 As well, without the client informing the AS, I can=E2=80=99t see a way for=
 the AS to know what endpoint the client is using.  The webfinger appro=
ach does this once and only requires that the host name be checked in many c=
ases.

    As a princip=
le, the members have discussed many times that the AS service should do vali=
dation when possible =E2=80=94 this was particularly true at the Germany mee=
ting when this came up. This is why I prefer the client tell the service pro=
vider what it intends to do and the service provider can fail that request i=
mmediately if necessary. We don=E2=80=99t have to depend on the developer ge=
tting the spec correct to fail the correct way.

    I worry that adding more parameters to the aut=
hz and token protocol flows increases complexity and attack surface. It also=
 means per authorization validation has to take place vs. a one-time validat=
ion at config time.  Placing it in the configuration lookup phase (whet=
her via web finger or just a special OAuth endpoint) seems more appropriate a=
nd far less complex - as the request itself is simple and has only one param=
eter. Here we are not considered about legitimacy of the client. we=E2=80=99=
re just concerned with the issue "has the client been correctly informed?=E2=
=80=9D

    That said, i=
t may be that when we consider all the use cases, some combination of AS pro=
tocol and discovery may be both needed. I=E2=80=99m not ready to make conclu=
sions about this.  The current oauth-discovery spec seems to put future=
 generic clients at risk and that is my primary concern.

    Best Regards,
    

    Phil
    <=
br class=3D"">
    @independentid
    www.independentid.com
    phil.hunt@oracle.com




    

    

    On Mar 13, 2016, at 10:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote=
:

    Thanks for posting this, Phil.  It provides a concrete exampl=
e of a way that protected resource discovery could be added to authorization=
 server metadata discovery, and as such, should provide useful input for wor=
king group discussions on this topic.  It=E2=80=99s always great when s=
omeone takes the time to write an actual draft that can be examined and impl=
emented, and I appreciate you doing that.
    =

    &nb=
sp;
    The content of your draft points out that there appears to be complete ag=
reement on what the authorization server metadata format should be, which is=
 great!  I=E2=80=99ll note that Section 3 of draft-hunt-oauth-bound-con=
fig-00 titled =E2=80=9CAuthorization Server Metadata=E2=80=9D is an exact co=
py of Section 2 of draft-ietf-oauth-discovery-01 (with the same title), modu=
lo applying a correction suggested by the working group.  To me this su=
ggests that the authorization server metadata definitions in draft-ietf-oaut=
h-discovery (which is now the whole normative content of the draft) are clea=
rly ready for standardization, since even your alternative proposal includes=
 them verbatim.
     
    Reading your draft, the pro=
blem I have with it is that you are returning the AS metadata only as a WebFi=
nger response, rather than as an https-protected resource published by the a=
uthorization server.  The choice to only return this via WebFinger make=
s your draft incompatible with most deployed implementations of OAuth metada=
ta, including the 22 implementations using it listed athttp://openid.net/certification/ (see the =E2=80=9COP Config=E2=80=9D column in the ta=
ble) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=
=9CADAL=E2=80=9D library, which uses the metadata path for client configurat=
ion.  Without having ASs provide the metadata as an https-protected res=
ource, implementations such as ADAL can=E2=80=99t use it for client configur=
ation as the currently do.
    =
 
    Therefore, I would request that you make these mi=
nor revisions to your draft and republish, so as to provide a unified way fo=
rward that is compatible with all known existing OAuth Discovery deployments=
:
    1.       Mo=
dify your section 2 =E2=80=9CAuthorization Server WebFinger Discovery=E2=80=9D=
 to have the WebFinger request return the issuer identifier for the AS as th=
e =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, rather than returning the m=
etadata values by value as the =E2=80=9Cproperties=E2=80=9D value.
    2=
.       Reference t=
he metadata definitions from Section 2 of draft-ietf-oauth-discovery, rather=
 than duplicating them in your Section 3.
     
    That would have the advanta=
ge of paring your draft down to only the new things that it proposes, enabli=
ng them to be more clearly understood and evaluated on their own merits.&nbs=
p; I look forward to the discussions of ways of performing additional kinds o=
f OAuth discovery, and consider your draft a valuable input to those discuss=
ions.
     
              &=
nbsp;            =
;            &nb=
sp;            &=
nbsp;         Best wishes,
            &=
nbsp;            =
;            &nb=
sp;            &=
nbsp;           -- Mike
     
    From: OAuth [mailto:oauth-b=
ounces@ietf.org] On Behalf Of =
John Bradley
    Sent: Sunday, March 13, 2016 6:45 PM
    To: Phil Hunt &=
lt;phil.hunt@oracle.com>
    Cc: oauth <    oaut=
h@ietf.org>
    Subject: Re: [OAUTH-WG] New Version Notification fo=
r draft-hunt-oauth-bound-config-00.txt
     
    <=
div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times N=
ew Roman', serif;" class=3D"">As I have told Phil off list.  
     
    Discovery is the wrong place to try and provide security against man in the=
 middle attacks on the RS.
    =

     
    This requires the client to know=
 what the RS URI is before retrieving the information on the AS Configuratio=
n.
     
    The proposal Mike and I have been working on requires the c=
lient to have a notion of what API it is looking for and retrieve the .well-=
known file for that API from the issuer.   That allows a protocol like C=
onnect to register its own config file that can point to the RS.   =
;
     
    If the API specific well known is not available the client=
 can try the default oauth-server one.
     
    That then allows us t=
o deal with restricting where AT are presented as part of the protocol rathe=
r then dragging discovery in as a requirement.
     
    In my opinio=
n the resource the token is targeted to should be separated from the scope a=
nd returned as part of the meta-data about the AT along with scopes granted a=
nd expiry time.   We should also have a input parameter for resources s=
o that a client can restrict tokens issued to a subset of the ones granted b=
y the refresh token.   It would then also be possible to ask a AS for a=
 token for a unregistered RS and have the AS produce a JWT access token with=
 the resource as an audience if policy allows.
     
    That however=
 was supposed to be dealt with as part of the mixed up client set of mitigat=
ions.  
    In that the goal was to mitigate the attacks by returning m=
eta-data about the tokens, and not to require discovery.
     
    We=
 intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=9D for t=
he code, and I intend to discuss at the F2F returning resource for AT as wel=
l.
     
    Those mitigate the attack.  
    &nbs=
p;
    I will co=
ntinue to resist mixing up discovery of configuration meta-data with mitigat=
ion of the attacks.
     
    We return meta-data about the tokens now,=
 because AT are opaque to the client, we neglected to include some of the in=
formation for the client needs to be secure.   We just need to add that=
 in to the existing flows.
    =

     
    While Phil=E2=80=99s proposal is=
 easier for the AS to implement as an add on, it puts more of a burden on th=
e client needing to potentially change how it stores the relationships betwe=
en AS and RS to prevent compromise, I think the solution should be biased to=
wards simplicity on the client side.
     
    =

    If we return the resou=
rces as part of the existing meta data the client checks that against the re=
source it intends to send the token to and if it is not in the list then it c=
an=E2=80=99t send the token.  Simple check every time it gets a new AT,=
 no optionality.
    I am not saying anything new Nat has been a=
dvocating basically this for some time, and dis submit a draft.   I pre=
fer to return the info in the existing format rather than as link headers, &=
nbsp;but that is the largest difference between what Nat and I are saying wi=
th respect to resource.
     
    That is the core of my problem with=
 Phil=E2=80=99s draft.
     
    I guess we will need to have a long c=
onversation in BA.
     
    Regards
    =

    John B.
     
     
    =

    This draft i=
s a proposed alternate proposal for draft-ietf-oauth-discovery.  As suc=
h, it contains the same registry for OAuth Config Metadata as the authors be=
lieve that both solutions are not required, or depending on WG discussion th=
ey will be merged. The intent is to provide a simple complete draft for cons=
ideration.
     
    How it works...
    Given that a client has previously di=
scovered an OAuth protected resource, the bound configuration method allows a=
 client to return the configuration for an oauth authorization server that c=
an issue tokens for the resource URI specified by the client.  The AS i=
s not required to be in the same domain.  The AS is however required to=
 know if it can issue tokens for a resource service (which presumes some agr=
eement exists on tokens etc).
     
    <=
div class=3D"">
    The draft does not require th=
at the resource exist (e.g. for unconfigured or new user based resources). I=
t only requires that the AS service provider agrees it can issue tokens.
     
    =46rom a security perspective, returning the OAuth service conf=
iguration for a specified resource URI serves to confirm the client is in po=
ssession of a valid resource URI ensuring the client has received a valid se=
t of endpoints for the resource and the associated oauth services.
     
    I propose that the WG consider the alternate draft carefully as well=
 as other submissions and evaluate the broader discovery problem before proc=
eeding with WGLC on OAuth Discovery.
     
    =

    Thanks!
     
    Phil<=
/o:p>
     
    @=
independentid
    www.independentid.com
    phil.hunt@oracle.com
     


    Begin forwarded message:
     <=
/o:p>
    From: intern=
et-drafts@ietf.org
    Subject: New Version Notification for dr=
aft-hunt-oauth-bound-config-00.txt
    Date: March 13, 2016 at 3:53:37 PM PDT
    To:=
 "Phil Hunt" <phil.hunt@yahoo.com>, "Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>
     =

    A new version of I-D, draft-hunt-oauth-bound-config-00.txt
    has been successfully submitted by Phil Hunt and posted to the
    IETF repository.

    Name:          =
   draft-=
hunt-oauth-bound-config
    Revision:         00
    Title:           =
    =
OAuth 2.0 Bound Configuration Lookup
    Document date:          2016-03-13
    Group:      =
      &n=
bsp;Individual Submission
    Pages:          &=
nbsp;   2=
2
    URL:          &=
nbsp; https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-=
00.txt
    Status:        &=
nbsp;https:/=
/datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
    H=
tmlized:       https://tools.ietf.org/html/draft-hunt-oauth-b=
ound-config-00


    Abstract:
      This specification defines a mechanism for the client o=
f an OAuth 2.0
      protected resource service to obtai=
n the configuration details of an
      OAuth 2.0 author=
ization server that is capable of authorizing access
     &nb=
sp;to a specific resource service.  The information includes the OAuth<=
br class=3D"">  2.0 component endpoint location URIs and as well a=
s authorization
      server capabilities.




    Please note tha=
t it may take a couple of minutes from the time of submission
    =
until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat
    <=
/div>
    &nbs=
p;
    __________________=
_____________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    <=
/div>

    =

    =

--Apple-Mail-84288AA3-CFA8-449C-AE75-53E0FC95FF3B--


From nobody Mon Mar 14 15:26:10 2016
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 541FF12D7A4 for ; Mon, 14 Mar 2016 15:26: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=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 uXfg_eYWALaD for ; Mon, 14 Mar 2016 15:26:07 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 8F3C512D769 for ; Mon, 14 Mar 2016 15:26:07 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id l68so128120827wml.0 for ; Mon, 14 Mar 2016 15:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=DZYAisoVNuO1Pa/gNLf1v/Eb8sxvFWYclzsgicbWqY0=; b=a8zxMc6wSEkRhyY06Qifl7o6EcUael3eXheFLMi40jJsUsmL6F/x5k7mp2AIrZmkPt VVjVXBHF1IoXlbZydZ2V/n76qq9ohmkppawAZWDQOxCi/SrKNGOycfwEpPtVdSDhZ4ix 0Ts4ppSv8PhfztCE/R8styIzndFq6u3xzalcM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DZYAisoVNuO1Pa/gNLf1v/Eb8sxvFWYclzsgicbWqY0=; b=isWKJKtuE7NBQ4dykEgVcFrm9FdWPZuK8dDrRwEhH4DhS1Z+35i0c2fWt1I1l3JQDr q9DziVf7sExabk8M7kLnpznwBYghgEzovBq4PJ+55bgkHp6DD1tnxLL0MqjWdDAiqNXQ fKvNRExTI2pUTYis5h+20FKnOTWRXCZ99eFMUVXHQwei4uk9hkofMqjHYnDYExSK0YL6 LWQTbMQEvAFjO1XY10Qj0E7i5qh+Be5Pnqm23PXyWGC6LjlCZvF5angd1Kq7XqkTcnSc xNv0IYGoQ6wAoEmH4RPuRG/n/i0TtLuLro9vbwCExBPIYNnR/V6+ppLXylVegB/uLodC LDjw==
X-Gm-Message-State: AD7BkJKFr8rzlIm9ZvMBvytTKOm3A4t7SA6guPP2mJtishGr2VNEi2d9q8QhjNrt9TKY+/hh
X-Received: by 10.28.213.142 with SMTP id m136mr20921699wmg.24.1457994366156;  Mon, 14 Mar 2016 15:26:06 -0700 (PDT)
Received: from [10.125.54.45] ([81.145.221.186]) by smtp.gmail.com with ESMTPSA id g203sm17965061wmf.23.2016.03.14.15.26.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 15:26:05 -0700 (PDT)
To: "Phil Hunt (IDM)" , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com> 
From: Hans Zandbelt 
Message-ID: <56E73A7C.3040405@pingidentity.com>
Date: Mon, 14 Mar 2016 22:26:04 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 22:26:09 -0000

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:

> On Mar 14, 2016, at 14:13, John Bradley  > wrote:
>> Any client that has the resource and issuer hard coded probably
>> doesn’t need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each 
other, regardless of the fact that a Discovery solution *could* solve 
the IDP mixup attack as well.

Hans.

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Mon Mar 14 15:26:48 2016
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 2CBD512D7AD for ; Mon, 14 Mar 2016 15:26:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 6U8F6KaQCzXp for ; Mon, 14 Mar 2016 15:26:41 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 1A30012D7B4 for ; Mon, 14 Mar 2016 15:26:41 -0700 (PDT)
Received: by mail-qg0-x22f.google.com with SMTP id w104so167141818qge.1 for ; Mon, 14 Mar 2016 15:26:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QHQMRiQO5uBD9tty4jZ94TKxiG1MnHkHriPcNSlsfeQ=; b=wujBbmBjz/ZuJJd52fnDhmVDQEW9t9luMS9WUDYy+jAH/akg2kdE+TZU+oNDqbewU1 Y4/xfDXWF+2N+AwKWFxtPHNWIEDzshp5+rm6W8FrsoYPhPxym7LW3NeYd3Srxq9V9Nhj oE2hmYLqGd7KX1EDWSsNfJ6IIF9R2nqFcWqN1+0WWO1khwuMB1k6uUvhZktq/+XV/+/3 jZt3snrMbWr4hTIx7D5W5PWoUOoKqBtz/AZSWXAhBv15IWXTjtHYEkqebea8ogH7w8G2 Lv9npZxOHFNnHXhUFLD2tG/ZvKpOBltUCO4vFVf1NZP09JKn3ngX8WGhrVNV9pBIBPlV 2Ubg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QHQMRiQO5uBD9tty4jZ94TKxiG1MnHkHriPcNSlsfeQ=; b=e80QCzH9PaYXkYkIRVY8VldaQOrowF5e6Wzpyw4EvRhgb6SwvjQpgTTDG8wPPEw13m TRXS5PlRdBBwLo7DVuWms4ZsSI+b06kZ8SHZlZq0uiTaVM/i2/4ZhGhO479koOzyXWA8 YT0KuNAyar+sm4wSNCOlwcfZhNdSKn0KT46X9Bw65C/tbdtgqITXe38Mu30rnzZDn0CQ WgMmA8aDVgmoUbYCGKSad6kynIYsJqlBRXfq7wpatQyKaUCJhtCGWR4j6P3kzS1ik63Y Ft+KK5KYh2iPop4CsKH8WawgIgJEwIC1U8JKXpBmAm1mIyLWVDFdwpUmn8KqRD0Zfo6F 3oCA==
X-Gm-Message-State: AD7BkJKgnxLHLE2GwqCtBuvXG22k6KxVRxbbXFsoPn5RSKnAKqkur1wDlgz+mZIu+m1FlA==
X-Received: by 10.140.239.66 with SMTP id k63mr35924616qhc.11.1457994400166; Mon, 14 Mar 2016 15:26:40 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.161.145]) by smtp.gmail.com with ESMTPSA id 64sm11291061qgy.34.2016.03.14.15.26.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Mar 2016 15:26:38 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_595E4D12-3983-4175-A443-C886E39437BB"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 14 Mar 2016 19:26:34 -0300
Message-Id: <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com> 
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 22:26:46 -0000

--Apple-Mail=_595E4D12-3983-4175-A443-C886E39437BB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DA7BF3DE-95AC-4BAC-9101-336F52A22C16"


--Apple-Mail=_DA7BF3DE-95AC-4BAC-9101-336F52A22C16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes I will work on another proposal for allowing clients to specify what =
resource they want a token for and providing the meta-data to the client =
about the resources that a token is valid for.

We have part of it in the POP key distribution spec and talked about =
separating it, as it is used more places than just for assigning keys.  =20=

I know some AS use different token formats for different RS so are =
all-ready needing to pass the resource in the request to avoid making a =
mess of scopes.

John B.





> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)  =
wrote:
>=20
> Inline
>=20
> Phil
>=20
> On Mar 14, 2016, at 14:13, John Bradley > wrote:
>=20
>> We had two mandates.  One was to provide a spec for AS metadata.   =
The other was to mitigate the client mixup attack.  The request was to =
do the latter without requiring the former for clients that don=E2=80=99t =
otherwise need discovery.
> There is no mandate for any of this. See =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =

>>=20
>> Returning the issuer and client_id from the authorization endpoint =
and the client checking them can be done by the client without =
discovery.=20
>=20
> How does this address the issue of whether the client is talking to =
the wrong endpoint?
>>=20
>> Any client that has the resource and issuer hard coded probably =
doesn=E2=80=99t need discovery. =20
> We agree
>=20
>=20
>> One of the things that a client will need discovery for is to find =
the RS, so requiring the client to know the RS URI before getting the AS =
config seems backwards to me.=20
> How can you make an assumption on order? You seem to be conflating =
authentication with authorization by assuming the identity drives what =
the resource is.=20
>=20
> There are lots of applications that require user rights but are not =
identify centric. For example a document service.=20
>>=20
>> Unless the client tells the AS where it intends to use the token we =
will be leaving a security hole because the bearer tokens will have too =
loose an audience if they have one at all.
> This is the biggest risk we have IMHO.=20
>>=20
>> True you are telling the AS (Webfinger service) what the RS is but =
that is not at a place that is useful in the token production process.
>=20
> This has nothing to do with token production.=20
>=20
> What we want to ensure is whether an honest client is correctly =
configured and has not been mislead - eg by a phishing page.=20
>>=20
>> I also think there are use cases where the AS doesn=E2=80=99t know =
all the possible RS.   That is not something that a out of band check =
can address.
>=20
> May be. Lets identify them.=20
>=20
>> There are also cases where a token might be good at multiple RS =
endpoints intentionally.
>=20
>>  In your solution the client would need to make a discovery request =
for each endpoint.
> Sure. Otherwise how would it know if there is one AS or a pool of AS =
servers assigned to each instance?
>> Those requests lack the context of who the client and resource owner =
are.  I think that will be a problem in some use cases.=20
>=20
> Not sure I agree. This is about discovering a valid set of endpoints. =
For mitm, we mainly want to check the hostname is correct. If a client =
chooses evil.com  the cert can be valid and TLS will =
pass. How does it otherwise know it is supposed to talk to =
res.example.com ?
>>=20
>> If this is added to the token endpoint it would be checked when code =
or refresh are exchanged, not every time the token is used.  =20
> Your proposal requires rhe client to check. I am not clear how the AS =
can know the exact uri. It is far easier to validate than to lookup =
since as you say the client may be authorized to use multiple ASs.=20
>> With a out of band check the client would never know if a RS was =
removed/revoked. =20
>=20
> Not sure that is in scope.=20
>=20
> None of the current proposals address this issue.=20
>> =20
>>=20
>> I don=E2=80=99t see checking when refreshing a token as something =
that is a huge burden.
>=20
> Still its a lot more than once.=20
>=20
> Why don't you draft another alternative?
>>=20
>> If the server wants to do the check on it=E2=80=99s side then we =
could require the client to send the RS URI in the token request. that =
way you really know the client is not going to get a token for the wrong =
RS endpoint.
>> If you check out of band in discovery you really have no idea if the =
client is checking.
>=20
> In the new webfinger draft, the client isn't checking. The service =
provider simply does not disclose oauth information to misconfigured =
clients.=20
>>=20
>> John B.
>> =20
>>=20
>>=20
>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt > wrote:
>>>=20
>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take each =
in turn:
>>>=20
>>> Mike,
>>>=20
>>> Regarding your suggested amendments
>>>=20
>>> Item 1: Returning the config URL would create two problems. One,it =
makes bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations). =20
>>>=20
>>> The two-step process allows the current discovery process to =
continue. I disagree with this. This is why I put forward an =
=E2=80=9Calternate" draft that is almost the same but simply adds the =
check before returning the configuration data.  I worry that  developers =
would have no incentive to do the two-step approach. They would just =
start at step 2 which in turn puts AS=E2=80=99s at risk of exposing =
tokens because it works. This makes OAuth promiscuous.
>>>=20
>>> Regarding existing implementations. Most of those implementations =
are for OIDC.  I think it makes sense for OIDF to continue use of OIDC's =
discovery spec because the UserInfo endpoint is well defined and the =
likelihood of a client mis-informed about the resource endpoint is not =
there.  IMO This does not apply to the broader OAuth community.
>>>=20
>>> Item 2:  It may be appropriate to have a separate configuration =
registry specification, but I think we should hold off until we have a =
complete solution and then make the decision what drafts should exist =
and how many pieces.  A big concern is the perceived complexity of =
multiple solutions and multiple drafts.
>>>=20
>>> As to John Bradley=E2=80=99s comments:
>>>=20
>>> Re: Discovery is the wrong place to mitigate threats.=20
>>> I=E2=80=99m confused by this.  Our mandate was to solve a security =
threat by having a discovery specification to prevent clients being =
mis-lead about endpoints (of which resource service is one) in an oauth =
protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?
>>>=20
>>> Re: Your proposal for MITM mitigation
>>> You propose that instead the resource endpoint check should be in =
the oauth protocol itself.  The difference is that validation is =
transferred back to the client to get it right. As well, without the =
client informing the AS, I can=E2=80=99t see a way for the AS to know =
what endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many cases.
>>>=20
>>> As a principle, the members have discussed many times that the AS =
service should do validation when possible =E2=80=94 this was =
particularly true at the Germany meeting when this came up. This is why =
I prefer the client tell the service provider what it intends to do and =
the service provider can fail that request immediately if necessary. We =
don=E2=80=99t have to depend on the developer getting the spec correct =
to fail the correct way.
>>>=20
>>> I worry that adding more parameters to the authz and token protocol =
flows increases complexity and attack surface. It also means per =
authorization validation has to take place vs. a one-time validation at =
config time.  Placing it in the configuration lookup phase (whether via =
web finger or just a special OAuth endpoint) seems more appropriate and =
far less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D
>>>=20
>>> That said, it may be that when we consider all the use cases, some =
combination of AS protocol and discovery may be both needed. I=E2=80=99m =
not ready to make conclusions about this.  The current oauth-discovery =
spec seems to put future generic clients at risk and that is my primary =
concern.
>>>=20
>>> Best Regards,
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com =
phil.hunt@oracle.com =

>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones =
> =
wrote:
>>>>=20
>>>> Thanks for posting this, Phil.  It provides a concrete example of a =
way that protected resource discovery could be added to authorization =
server metadata discovery, and as such, should provide useful input for =
working group discussions on this topic.  It=E2=80=99s always great when =
someone takes the time to write an actual draft that can be examined and =
implemented, and I appreciate you doing that.
>>>> =20
>>>> The content of your draft points out that there appears to be =
complete agreement on what the authorization server metadata format =
should be, which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests that the =
authorization server metadata definitions in draft-ietf-oauth-discovery =
(which is now the whole normative content of the draft) are clearly =
ready for standardization, since even your alternative proposal includes =
them verbatim.
>>>> =20
>>>> Reading your draft, the problem I have with it is that you are =
returning the AS metadata only as a WebFinger response, rather than as =
an https-protected resource published by the authorization server.  The =
choice to only return this via WebFinger makes your draft incompatible =
with most deployed implementations of OAuth metadata, including the 22 =
implementations using it listed athttp://openid.net/certification/ =
 (see the =E2=80=9COP Config=E2=80=9D =
column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D library, which uses the metadata path for client =
configuration.=C2=A0 Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do. <>
>>>> =20
>>>> Therefore, I would request that you make these minor revisions to =
your draft and republish, so as to provide a unified way forward that is =
compatible with all known existing OAuth Discovery deployments:
>>>> 1.       Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D to have the WebFinger request return the =
issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D=
 value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
>>>> 2.       Reference the metadata definitions from Section 2 of =
draft-ietf-oauth-discovery, rather than duplicating them in your Section =
3.
>>>> =20
>>>> That would have the advantage of paring your draft down to only the =
new things that it proposes, enabling them to be more clearly understood =
and evaluated on their own merits.  I look forward to the discussions of =
ways of performing additional kinds of OAuth discovery, and consider =
your draft a valuable input to those discussions.
>>>> =20
>>>>                                                           Best =
wishes,
>>>>                                                           -- Mike
>>>> =20
>>>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of John Bradley
>>>> Sent: Sunday, March 13, 2016 6:45 PM
>>>> To: Phil Hunt >
>>>> Cc: oauth >
>>>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>>> =20
>>>> As I have told Phil off list. =20
>>>> =20
>>>> Discovery is the wrong place to try and provide security against =
man in the middle attacks on the RS.
>>>> =20
>>>> This requires the client to know what the RS URI is before =
retrieving the information on the AS Configuration.
>>>> =20
>>>> The proposal Mike and I have been working on requires the client to =
have a notion of what API it is looking for and retrieve the .well-known =
file for that API from the issuer.   That allows a protocol like Connect =
to register its own config file that can point to the RS.  =20
>>>> =20
>>>> If the API specific well known is not available the client can try =
the default oauth-server one.
>>>> =20
>>>> That then allows us to deal with restricting where AT are presented =
as part of the protocol rather then dragging discovery in as a =
requirement.
>>>> =20
>>>> In my opinion the resource the token is targeted to should be =
separated from the scope and returned as part of the meta-data about the =
AT along with scopes granted and expiry time.   We should also have a =
input parameter for resources so that a client can restrict tokens =
issued to a subset of the ones granted by the refresh token.   It would =
then also be possible to ask a AS for a token for a unregistered RS and =
have the AS produce a JWT access token with the resource as an audience =
if policy allows.
>>>> =20
>>>> That however was supposed to be dealt with as part of the mixed up =
client set of mitigations. =20
>>>> In that the goal was to mitigate the attacks by returning meta-data =
about the tokens, and not to require discovery.
>>>> =20
>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=
=9D for the code, and I intend to discuss at the F2F returning resource =
for AT as well.
>>>> =20
>>>> Those mitigate the attack. =20
>>>> =20
>>>> I will continue to resist mixing up discovery of configuration =
meta-data with mitigation of the attacks.
>>>> =20
>>>> We return meta-data about the tokens now, because AT are opaque to =
the client, we neglected to include some of the information for the =
client needs to be secure.   We just need to add that in to the existing =
flows.
>>>> =20
>>>> While Phil=E2=80=99s proposal is easier for the AS to implement as =
an add on, it puts more of a burden on the client needing to potentially =
change how it stores the relationships between AS and RS to prevent =
compromise, I think the solution should be biased towards simplicity on =
the client side.
>>>> =20
>>>> If we return the resources as part of the existing meta data the =
client checks that against the resource it intends to send the token to =
and if it is not in the list then it can=E2=80=99t send the token.  =
Simple check every time it gets a new AT, no optionality.
>>>> =20
>>>> I am not saying anything new Nat has been advocating basically this =
for some time, and dis submit a draft.   I prefer to return the info in =
the existing format rather than as link headers,  but that is the =
largest difference between what Nat and I are saying with respect to =
resource.
>>>> =20
>>>> That is the core of my problem with Phil=E2=80=99s draft.
>>>> =20
>>>> I guess we will need to have a long conversation in BA.
>>>> =20
>>>> Regards
>>>> John B.
>>>> =20
>>>> On Mar 13, 2016, at 8:12 PM, Phil Hunt > wrote:
>>>> =20
>>>> This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry for =
OAuth Config Metadata as the authors believe that both solutions are not =
required, or depending on WG discussion they will be merged. The intent =
is to provide a simple complete draft for consideration.
>>>> =20
>>>> How it works...
>>>> Given that a client has previously discovered an OAuth protected =
resource, the bound configuration method allows a client to return the =
configuration for an oauth authorization server that can issue tokens =
for the resource URI specified by the client.  The AS is not required to =
be in the same domain.  The AS is however required to know if it can =
issue tokens for a resource service (which presumes some agreement =
exists on tokens etc).
>>>> =20
>>>> The draft does not require that the resource exist (e.g. for =
unconfigured or new user based resources). It only requires that the AS =
service provider agrees it can issue tokens.
>>>> =20
>>>> =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.
>>>> =20
>>>> I propose that the WG consider the alternate draft carefully as =
well as other submissions and evaluate the broader discovery problem =
before proceeding with WGLC on OAuth Discovery.
>>>> =20
>>>> Thanks!
>>>> =20
>>>> Phil
>>>> =20
>>>> @independentid
>>>> www.independentid.com 
>>>> phil.hunt@oracle.com 
>>>> =20
>>>>=20
>>>>=20
>>>> Begin forwarded message:
>>>> =20
>>>> From: internet-drafts@ietf.org 
>>>> Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>>> Date: March 13, 2016 at 3:53:37 PM PDT
>>>> To: "Phil Hunt" >, =
"Anthony Nadalin" >, "Tony Nadalin" >
>>>> =20
>>>>=20
>>>> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>>>> has been successfully submitted by Phil Hunt and posted to the
>>>> IETF repository.
>>>>=20
>>>> Name:             draft-hunt-oauth-bound-config
>>>> Revision:         00
>>>> Title:               OAuth 2.0 Bound Configuration Lookup
>>>> Document date:          2016-03-13
>>>> Group:             Individual Submission
>>>> Pages:              22
>>>> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =

>>>> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =

>>>>=20
>>>>=20
>>>> Abstract:
>>>>   This specification defines a mechanism for the client of an OAuth =
2.0
>>>>   protected resource service to obtain the configuration details of =
an
>>>>   OAuth 2.0 authorization server that is capable of authorizing =
access
>>>>   to a specific resource service.  The information includes the =
OAuth
>>>>   2.0 component endpoint location URIs and as well as authorization
>>>>   server capabilities.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> 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 =
.
>>>>=20
>>>> The IETF Secretariat
>>>>=20
>>>> =20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth =

>>=20


--Apple-Mail=_DA7BF3DE-95AC-4BAC-9101-336F52A22C16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes I will work on another proposal for allowing clients to =
specify what resource they want a token for and providing the meta-data =
to the client about the resources that a token is valid for.

    We have part of it in =
the POP key distribution spec and talked about separating it, as it is =
used more places than just for assigning keys.   
    I know some AS use different token formats for different RS =
so are all-ready needing to pass the resource in the request to avoid =
making a mess of scopes.

    John B.





    On =
Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    Inline

    Phil

    On =
Mar 14, 2016, at 14:13, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    We had two mandates. =
 One was to provide a spec for AS metadata.   The other was to =
mitigate the client mixup attack.  The request was to do the latter =
without requiring the former for clients that don=E2=80=99t otherwise =
need discovery.
    There is no mandate for any of this. =
See http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt

    Returning =
the issuer and client_id from the authorization endpoint and the client =
checking them can be done by the client without =
discovery. 

    How does this address the issue of whether the client =
is talking to the wrong endpoint?

    Any client that has the resource and issuer hard coded =
probably doesn=E2=80=99t need discovery. =
 
    We agree


    One of the things that a =
client will need discovery for is to find the RS, so requiring the =
client to know the RS URI before getting the AS config seems backwards =
to me. 
    How can you make an assumption on =
order? You seem to be conflating authentication with authorization by =
assuming the identity drives what the resource is. 

    There are lots of =
applications that require user rights but are not identify centric. For =
example a document service. 

    Unless the client tells the AS where it intends to use the =
token we will be leaving a security hole because the bearer tokens will =
have too loose an audience if they have one at =
all.
    This is the biggest risk we have =
IMHO. 

    True you =
are telling the AS (Webfinger service) what the RS is but that is not at =
a place that is useful in the token production =
process.

    This=
 has nothing to do with token production. 

    What we want to ensure is whether an =
honest client is correctly configured and has not been mislead - eg by a =
phishing page. 

    I also think there are use cases where the AS doesn=E2=80=99t =
know all the possible RS.   That is not something that a out of =
band check can address.

    May be. =
Lets identify them. 

    There are also =
cases where a token might be good at multiple RS endpoints =
intentionally.

     In your =
solution the client would need to make a discovery request for each =
endpoint.
    Sure. Otherwise how would it know if =
there is one AS or a pool of AS servers assigned to each instance?
    Those requests lack the context of who the client and =
resource owner are.  I think that will be a problem in some use =
cases. 

    Not sure I agree. This is about discovering a valid set =
of endpoints. For mitm, we mainly want to check the hostname is correct. =
If a client chooses evil.com =
the cert can be valid and TLS will pass. How does it otherwise know it =
is supposed to talk to res.example.com?

    If this is added to the token endpoint it would be checked =
when code or refresh are exchanged, not every time the token is used. =
  
    Your proposal requires rhe client =
to check. I am not clear how the AS can know the exact uri. It is far =
easier to validate than to lookup since as you say the client may be =
authorized to use multiple ASs. 
    With a out of =
band check the client would never know if a RS was removed/revoked. =
 

    Not =
sure that is in scope. 

    None of the current proposals address =
this issue. 
     

    I don=E2=80=99t see checking when =
refreshing a token as something that is a huge =
burden.

    Still=
 its a lot more than once. 

    Why don't you draft another =
alternative?

    If the =
server wants to do the check on it=E2=80=99s side then we could require =
the client to send the RS URI in the token request. that way you really =
know the client is not going to get a token for the wrong RS =
endpoint.
    If you check out of band in discovery you =
really have no idea if the client is =
checking.

    In the new webfinger draft, the =
client isn't checking. The service provider simply does not disclose =
oauth information to misconfigured clients. 

    John B.
     


    On Mar 14, 2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    Thanks to Mike and John for their feedback.  I=E2=80=99ll =
take each in turn:

    Mike,

    Regarding your suggested =
amendments

    Item =
1: Returning the config URL would create two problems. One,it makes =
bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations).  

    The two-step process allows the current =
discovery process to continue. I disagree with this. This is why I put =
forward an =E2=80=9Calternate" draft that is almost the same but simply =
adds the check before returning the configuration data.  I worry =
that  developers would have no incentive to do the two-step =
approach. They would just start at step 2 which in turn puts AS=E2=80=99s =
at risk of exposing tokens because it works. This makes OAuth =
promiscuous.

    Regarding existing implementations. Most of those =
implementations are for OIDC.  I think it makes sense for OIDF to =
continue use of OIDC's discovery spec because the UserInfo endpoint is =
well defined and the likelihood of a client mis-informed about the =
resource endpoint is not there.  IMO This does not apply to the =
broader OAuth community.

    Item 2:  It may be appropriate to have a separate =
configuration registry specification, but I think we should hold off =
until we have a complete solution and then make the decision what drafts =
should exist and how many pieces.  A big concern is the perceived =
complexity of multiple solutions and multiple drafts.

    As to John Bradley=E2=80=99=
s comments:

    Re: =
Discovery is the wrong place to mitigate threats. 
    I=E2=80=99m confused by this.  Our mandate was to solve =
a security threat by having a discovery specification to prevent clients =
being mis-lead about endpoints (of which resource service is one) in an =
oauth protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?

    Re: Your proposal for MITM mitigation
    You =
propose that instead the resource endpoint check should be in the oauth =
protocol itself.  The difference is that validation is transferred =
back to the client to get it right. As well, without the client =
informing the AS, I can=E2=80=99t see a way for the AS to know what =
endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many =
cases.

    As a =
principle, the members have discussed many times that the AS service =
should do validation when possible =E2=80=94 this was particularly true =
at the Germany meeting when this came up. This is why I prefer the =
client tell the service provider what it intends to do and the service =
provider can fail that request immediately if necessary. We don=E2=80=99t =
have to depend on the developer getting the spec correct to fail the =
correct way.

    I =
worry that adding more parameters to the authz and token protocol flows =
increases complexity and attack surface. It also means per authorization =
validation has to take place vs. a one-time validation at config time. =
 Placing it in the configuration lookup phase (whether via web =
finger or just a special OAuth endpoint) seems more appropriate and far =
less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D

    That said, it may be that when we =
consider all the use cases, some combination of AS protocol and =
discovery may be both needed. I=E2=80=99m not ready to make conclusions =
about this.  The current oauth-discovery spec seems to put future =
generic clients at risk and that is my primary concern.

    Best Regards,

    




    

    

    On Mar 13, 2016, at 10:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

    Thanks for posting this, Phil.  It provides a concrete =
example of a way that protected resource discovery could be added to =
authorization server metadata discovery, and as such, should provide =
useful input for working group discussions on this topic.  It=E2=80=99=
s always great when someone takes the time to write an actual draft that =
can be examined and implemented, and I appreciate you doing that.
     
    The =
content of your draft points out that there appears to be complete =
agreement on what the authorization server metadata format should be, =
which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests =
that the authorization server metadata definitions in =
draft-ietf-oauth-discovery (which is now the whole normative content of =
the draft) are clearly ready for standardization, since even your =
alternative proposal includes them verbatim.
     
    Reading your draft, the problem I have with it is that you =
are returning the AS metadata only as a WebFinger response, rather than =
as an https-protected resource published by the authorization =
server.  The choice to only return this via WebFinger makes your =
draft incompatible with most deployed implementations of OAuth metadata, =
including the 22 implementations using it listed athttp://openid.net/certification/ (see the =E2=80=9COP =
Config=E2=80=9D column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CADAL=E2=
=80=9D library, which uses the metadata path for client =
configuration.  Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do.
     
    Therefore, I =
would request that you make these minor revisions to your draft and =
republish, so as to provide a unified way forward that is compatible =
with all known existing OAuth Discovery deployments:
    1.       Modify your section 2 =E2=80=9CAuthorization =
Server WebFinger Discovery=E2=80=9D to have the WebFinger request return =
the issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=
=80=9D value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
    2.       Reference the metadata definitions from =
Section 2 of draft-ietf-oauth-discovery, rather than duplicating them in =
your Section 3.
     
    That would have the advantage of paring your draft down to =
only the new things that it proposes, enabling them to be more clearly =
understood and evaluated on their own merits.  I look forward to =
the discussions of ways of performing additional kinds of OAuth =
discovery, and consider your draft a valuable input to those =
discussions.
     
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          Best =
wishes,
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
    Sent: Sunday, March 13, 2016 6:45 =
PM
    To: Phil Hunt <phil.hunt@oracle.com>
    Cc: oauth=
 <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    As I have told Phil off list.  
     
    Discovery is the wrong place to try and =
provide security against man in the middle attacks on the RS.
     
    This requires the client to know what the =
RS URI is before retrieving the information on the AS Configuration.
     
    The proposal Mike and I have been working =
on requires the client to have a notion of what API it is looking for =
and retrieve the .well-known file for that API from the issuer.   =
That allows a protocol like Connect to register its own config file that =
can point to the RS.   
     
    If the API specific well known is not available the =
client can try the default oauth-server one.
     
    That then allows us to deal with =
restricting where AT are presented as part of the protocol rather then =
dragging discovery in as a requirement.
     
    In my opinion the resource the token is =
targeted to should be separated from the scope and returned as part of =
the meta-data about the AT along with scopes granted and expiry time. =
  We should also have a input parameter for resources so that a =
client can restrict tokens issued to a subset of the ones granted by the =
refresh token.   It would then also be possible to ask a AS for a =
token for a unregistered RS and have the AS produce a JWT access token =
with the resource as an audience if policy allows.
     
    That however was supposed to be dealt =
with as part of the mixed up client set of mitigations.  
    In that the goal was to mitigate the attacks by returning =
meta-data about the tokens, and not to require discovery.
     
    We intend to return =E2=80=9Ciss=E2=80=9D =
and =E2=80=9Ccleint_id=E2=80=9D for the code, and I intend to discuss at =
the F2F returning resource for AT as well.
     
    Those mitigate the attack.  
     
    I will continue to resist mixing up =
discovery of configuration meta-data with mitigation of the attacks.
     
    We return meta-data about the tokens now, =
because AT are opaque to the client, we neglected to include some of the =
information for the client needs to be secure.   We just need to =
add that in to the existing flows.
     
    While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add on, it puts more of a burden on the client needing =
to potentially change how it stores the relationships between AS and RS =
to prevent compromise, I think the solution should be biased towards =
simplicity on the client side.
     
    If we return the resources as part of the existing =
meta data the client checks that against the resource it intends to send =
the token to and if it is not in the list then it can=E2=80=99t send the =
token.  Simple check every time it gets a new AT, no =
optionality.
     
    I am not saying anything new Nat has been advocating =
basically this for some time, and dis submit a draft.   I prefer to =
return the info in the existing format rather than as link headers, =
 but that is the largest difference between what Nat and I are =
saying with respect to resource.
     
    That is the core of my problem with Phil=E2=80=99s =
draft.
     
    I guess we will need to have a long conversation in =
BA.
     
    Regards
    John B.
     
    On =
Mar 13, 2016, at 8:12 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
     
    This draft is a =
proposed alternate proposal for draft-ietf-oauth-discovery.  As =
such, it contains the same registry for OAuth Config Metadata as the =
authors believe that both solutions are not required, or depending on WG =
discussion they will be merged. The intent is to provide a simple =
complete draft for consideration.
     
    How it works...
    Given that a client =
has previously discovered an OAuth protected resource, the bound =
configuration method allows a client to return the configuration for an =
oauth authorization server that can issue tokens for the resource URI =
specified by the client.  The AS is not required to be in the same =
domain.  The AS is however required to know if it can issue tokens =
for a resource service (which presumes some agreement exists on tokens =
etc).
     
    The draft does not require that the resource exist =
(e.g. for unconfigured or new user based resources). It only requires =
that the AS service provider agrees it can issue tokens.
     
    =46rom a security perspective, returning =
the OAuth service configuration for a specified resource URI serves to =
confirm the client is in possession of a valid resource URI ensuring the =
client has received a valid set of endpoints for the resource and the =
associated oauth services.
     
    I propose that the WG consider the alternate draft =
carefully as well as other submissions and evaluate the broader =
discovery problem before proceeding with WGLC on OAuth Discovery.
     
    Thanks!
     
    Phil
     
    @independentid
    www.independentid.com
     


    Begin forwarded message:
     
    Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
    Date: March 13, 2016 =
at 3:53:37 PM PDT
    To: "Phil Hunt" =
<phil.hunt@yahoo.com>, =
"Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>
     

    A new version of =
I-D, draft-hunt-oauth-bound-config-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:        &=
nbsp;    draft-hunt-oauth-bound=
-config
    Revision:        <=
span class=3D"Apple-converted-space"> 00
    Title:        &=
nbsp;      OAuth 2.0 Bound =
Configuration Lookup
    Document date:        &=
nbsp; 2016-03-13
    Group:        &=
nbsp;    Individual =
Submission
    Pages:        &=
nbsp;     22
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

    Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


    Abstract:
      This specification defines a mechanism for the =
client of an OAuth 2.0
      protected resource =
service to obtain the configuration details of an
      OAuth 2.0 authorization server that is capable of =
authorizing access
      to a specific resource =
service.  The information includes the OAuth
      2.0 component endpoint location URIs and as well =
as authorization
      server capabilities.




    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.

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


    <=
br class=3D"">
    =

--Apple-Mail=_DA7BF3DE-95AC-4BAC-9101-336F52A22C16--

--Apple-Mail=_595E4D12-3983-4175-A443-C886E39437BB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTQyMjI2MzVaMCMGCSqGSIb3DQEJBDEWBBTky8qsmyaw5XcYoD9rzei3
zU/cUzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBffcLIDYyWV3EbglFgJE4tX6N1KFKwtTEAGNOAMvp8syjCaJzET1O0
WvyY+fpau4VgLQ+s3NzQsog2BBEUM72J2+T4UxRuSBBFAgXvRZr/r5vntRKfzFIepwoFHBwCbuUf
KR/j36G42VGZf4FxGapiqkQhoajt6SiXJa0MzK5PQyhiGhaLlVaGIdj+7hh96gpDEYRkJGungM3i
evonFTp/wcssMP1Do77hVLoTdW02Z9+pUcKPnYnMGiKGtTKMJcejW9HTD3yTRUP2/pea3oxtcHhn
MbDrTo+RE5bShcrS1UyM/IpZCWPceBYWS12BLdKCd2HYZdiXhbK5SQ7rGgnDAAAAAAAA
--Apple-Mail=_595E4D12-3983-4175-A443-C886E39437BB--


From nobody Mon Mar 14 15:30:01 2016
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 4C6A712D7C1 for ; Mon, 14 Mar 2016 15:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 HrC3N9LN5bxr for ; Mon, 14 Mar 2016 15:29:58 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1939812D7B6 for ; Mon, 14 Mar 2016 15:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2rMm/JdG8UnxM8W5YphGchhsE1ljxRuk6kwV6/+G+Ic=; b=Aj57w/CMJfcduwjxRMe3YjSM2zMvW90l5UAuNfqqr+56347UDE7WJD93ejsM0g6+y/BQnpVG+uYe55GqJOtfFctDaQXtjbfCD6X8PVTzW+S7FGWCuRN3QnfMMOHpYslSyBgvjdFKGugYqu38AuETYW8zX1QkxTBGLWB0t8aNFJ8=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (10.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 14 Mar 2016 22:29:55 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0434.016; Mon, 14 Mar 2016 22:29:55 +0000
From: Anthony Nadalin 
To: Hans Zandbelt , "Phil Hunt (IDM)" , John Bradley 
Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
Thread-Index: AQHRfXsw7VgGJE45rUO1dQJbaliLD59YAM+WgAAqlwCAAD5oAIAA4ZyAgAAmbYCAABG0gIAAAnwAgAAAr7A=
Date: Mon, 14 Mar 2016 22:29:55 +0000
Message-ID: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <56E73A7C.3040405@pingidentity.com>
In-Reply-To: <56E73A7C.3040405@pingidentity.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:8::46d]
x-ms-office365-filtering-correlation-id: b8f97abe-21ae-43f3-2074-08d34c582b62
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 5:OcoQ6WWD9vG9NU2abcIV+iyGDz4TMZgBmtivvScXTbgXq7kq7NQ7ebZ8ZUDWRFEE4q/lCiwCmh1SzkazERMwboPqjbCTxYSUQaYIrA+0Qpitepd5uMewYyxIdH6QSnMqvCdWoXi5sJPTwdNiUyFqgQ==; 24:yKftw4WfMYG4TfWmXpVscQdr5DoZYNhv9drUz/b6UsnkCGNsT2mWcXKq0nVF0W++XfNPOXvczEBjOqxwxjOEDIjYmbcw/HDz5eMoILuxpa0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; 
x-forefront-prvs: 0881A7A935
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(13464003)(24454002)(377454003)(87936001)(74316001)(10090500001)(19580405001)(5001770100001)(77096005)(19580395003)(50986999)(2950100001)(5003600100002)(81166005)(3280700002)(1220700001)(86362001)(6116002)(230783001)(2900100001)(15975445007)(2906002)(5005710100001)(99286002)(3660700001)(10400500002)(102836003)(586003)(8990500004)(10290500002)(11100500001)(76176999)(92566002)(5002640100001)(33656002)(122556002)(54356999)(5008740100001)(1096002)(15650500001)(106116001)(76576001)(189998001)(4326007)(93886004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2016 22:29:55.6181 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 22:30:00 -0000

I would really like to see a comprehensive solution not this piece work, so=
 we know what we are solving and what we are not.

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) ; John Bradley 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound=
-config-00.txt

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:

> On Mar 14, 2016, at 14:13, John Bradley  > wrote:
>> Any client that has the resource and issuer hard coded probably=20
>> doesn't need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need di=
scovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each other,=
 regardless of the fact that a Discovery solution *could* solve the IDP mix=
up attack as well.

Hans.

--=20
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf=
.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.com%=
7c8cd9a8b2e020444382a708d34c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1&s=
data=3D1dsstJfhduQ3mZERUx6%2fO3OE241RK7ataalg6RY6JmA%3d


From nobody Mon Mar 14 15:44:47 2016
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 A700B12D74A for ; Mon, 14 Mar 2016 15:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 wXHei4aNvbsB for ; Mon, 14 Mar 2016 15:44:41 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 7F24212D714 for ; Mon, 14 Mar 2016 15:44:40 -0700 (PDT)
X-AuditID: 12074422-16fff7000000470c-6c-56e73ed6c6fb
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id F2.CD.18188.6DE37E65; Mon, 14 Mar 2016 18:44:38 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u2EMib5t025545; Mon, 14 Mar 2016 18:44:38 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2EMiZZU017741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Mar 2016 18:44:36 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1FD2BF43-D8F1-44AE-8A0A-F70301EE10CB"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer 
In-Reply-To: <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com>
Date: Mon, 14 Mar 2016 18:44:34 -0400
Message-Id: <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEKsWRmVeSWpSXmKPExsUixG6nonvN7nmYQcdVFYuTb1+xWSyY38hu sfruXzYHZo8lS34yeXx8eovF4/btjSwBzFFcNimpOZllqUX6dglcGa8mtDIVbDnPUrG15SdT A+PZX8xdjBwcEgImElefFXQxcnEICbQxSUyZ1ckO4WxklLi/9jQbhPOQSWLb5l2MXYycHMIC kRLvtuxiArF5BfQkXt26zApSxCwwhVFiy/kHTBBjpSRm7BcAqWETUJWYvqYFrJ5TwE5iyZpb YDYLUHxB3wUWEJtZwFPi0/TpLBAzrSQWXLsDtfggs8TUU8+ZQRIiAioS+/Y9AjtCQkBWYvfv R0wTGAVmIbljFrI7ZoENTpJYtG8JI4StLbFs4WtmCFtTYn/3chZMcQ2Jzm8TWSFseYntb+dA xS0lFs+8AVVvK3GrbwHUfDuJR9MWsS5g5F7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6qXm1mi l5pSuokRHIUuSjsYJ/7zOsQowMGoxMM7Q+p5mBBrYllxZe4hRkkOJiVR3rXcQCG+pPyUyozE 4oz4otKc1OJDjCpAux5tWH2BUYolLz8vVUmEV9kWqI43JbGyKrUoH6ZMmoNFSZw3KPJYmJBA emJJanZqakFqEUxWhoNDSYJ3LUijYFFqempFWmZOCUKaiYPzEKMEBw/Q8ANgw4sLEnOLM9Mh 8qcYdTmOzb2xlkkI7AIpcd4qkCIBkKKM0jy4OaCkmvD2sOkrRnGgF4V5Z4JU8QATMtykV0BL mICW9IQ/A1lSkoiQkmpg5GtPZ3l4d3v7thKLez5meqrR3eXfzjQcOWajYxXloTY92LJ14lz9 CemMHKpKqiH5nNrPHx2ce+DB/fRdyvZTP6zhPhwVfuLFtqlrpOq/XdS+vm0jy6/JF+4+N2dO 9I/waPc0X2PB71ssVnLZMtDT64HLA6NZQltTfx7KZ+mfalHdpcR8TahZiaU4I9FQi7moOBEA XOT3QoUDAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 22:44:45 -0000

--Apple-Mail=_1FD2BF43-D8F1-44AE-8A0A-F70301EE10CB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A2611D24-357E-487F-B593-19DDC71555CA"


--Apple-Mail=_A2611D24-357E-487F-B593-19DDC71555CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree that this is valuable, and not just for PoP. In all honesty, =
it=E2=80=99s not even really required for PoP to function in many cases =
=E2=80=94 it=E2=80=99s just an optimization for one particular kind of =
key distribution mechanism in that case.

In the years of deployment experience with OAuth 2, I think we=E2=80=99ve =
really got three different kinds of things that currently get folded =
into =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:


 - What things do I want to access? (photos, profile)
 - What actions do I want to take on these things? (read, write, delete)
 - How long do I want these tokens to work? =
(offline_access/refresh_token, one time use, next hour, etc)


I think the first one is close to the audience/resource parameters that =
have been bandied about a few times, including in the current token =
exchange document. We should be consistent across drafts in that regard. =
The second is more traditional scope-ish. The third has been patched in =
with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.

Just another vector to think about if we=E2=80=99re going to be adding =
things like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.

 =E2=80=94 Justin


> On Mar 14, 2016, at 6:26 PM, John Bradley  wrote:
>=20
> Yes I will work on another proposal for allowing clients to specify =
what resource they want a token for and providing the meta-data to the =
client about the resources that a token is valid for.
>=20
> We have part of it in the POP key distribution spec and talked about =
separating it, as it is used more places than just for assigning keys.
> I know some AS use different token formats for different RS so are =
all-ready needing to pass the resource in the request to avoid making a =
mess of scopes.
>=20
> John B.
>=20
>=20
>=20
>=20
>=20
>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) > wrote:
>>=20
>> Inline
>>=20
>> Phil
>>=20
>> On Mar 14, 2016, at 14:13, John Bradley > wrote:
>>=20
>>> We had two mandates.  One was to provide a spec for AS metadata.   =
The other was to mitigate the client mixup attack.  The request was to =
do the latter without requiring the former for clients that don=E2=80=99t =
otherwise need discovery.
>> There is no mandate for any of this. See =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =

>>>=20
>>> Returning the issuer and client_id from the authorization endpoint =
and the client checking them can be done by the client without =
discovery.
>>=20
>> How does this address the issue of whether the client is talking to =
the wrong endpoint?
>>>=20
>>> Any client that has the resource and issuer hard coded probably =
doesn=E2=80=99t need discovery.
>> We agree
>>=20
>>=20
>>> One of the things that a client will need discovery for is to find =
the RS, so requiring the client to know the RS URI before getting the AS =
config seems backwards to me.
>> How can you make an assumption on order? You seem to be conflating =
authentication with authorization by assuming the identity drives what =
the resource is.
>>=20
>> There are lots of applications that require user rights but are not =
identify centric. For example a document service.
>>>=20
>>> Unless the client tells the AS where it intends to use the token we =
will be leaving a security hole because the bearer tokens will have too =
loose an audience if they have one at all.
>> This is the biggest risk we have IMHO.
>>>=20
>>> True you are telling the AS (Webfinger service) what the RS is but =
that is not at a place that is useful in the token production process.
>>=20
>> This has nothing to do with token production.
>>=20
>> What we want to ensure is whether an honest client is correctly =
configured and has not been mislead - eg by a phishing page.
>>>=20
>>> I also think there are use cases where the AS doesn=E2=80=99t know =
all the possible RS.   That is not something that a out of band check =
can address.
>>=20
>> May be. Lets identify them.
>>=20
>>> There are also cases where a token might be good at multiple RS =
endpoints intentionally.
>>=20
>>>  In your solution the client would need to make a discovery request =
for each endpoint.
>> Sure. Otherwise how would it know if there is one AS or a pool of AS =
servers assigned to each instance?
>>> Those requests lack the context of who the client and resource owner =
are.  I think that will be a problem in some use cases.
>>=20
>> Not sure I agree. This is about discovering a valid set of endpoints. =
For mitm, we mainly want to check the hostname is correct. If a client =
chooses evil.com  the cert can be valid and TLS will =
pass. How does it otherwise know it is supposed to talk to =
res.example.com ?
>>>=20
>>> If this is added to the token endpoint it would be checked when code =
or refresh are exchanged, not every time the token is used.
>> Your proposal requires rhe client to check. I am not clear how the AS =
can know the exact uri. It is far easier to validate than to lookup =
since as you say the client may be authorized to use multiple ASs.
>>> With a out of band check the client would never know if a RS was =
removed/revoked.
>>=20
>> Not sure that is in scope.
>>=20
>> None of the current proposals address this issue.
>>>=20
>>>=20
>>> I don=E2=80=99t see checking when refreshing a token as something =
that is a huge burden.
>>=20
>> Still its a lot more than once.
>>=20
>> Why don't you draft another alternative?
>>>=20
>>> If the server wants to do the check on it=E2=80=99s side then we =
could require the client to send the RS URI in the token request. that =
way you really know the client is not going to get a token for the wrong =
RS endpoint.
>>> If you check out of band in discovery you really have no idea if the =
client is checking.
>>=20
>> In the new webfinger draft, the client isn't checking. The service =
provider simply does not disclose oauth information to misconfigured =
clients.
>>>=20
>>> John B.
>>>=20
>>>=20
>>>=20
>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt > wrote:
>>>>=20
>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take each =
in turn:
>>>>=20
>>>> Mike,
>>>>=20
>>>> Regarding your suggested amendments
>>>>=20
>>>> Item 1: Returning the config URL would create two problems. One,it =
makes bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations).
>>>>=20
>>>> The two-step process allows the current discovery process to =
continue. I disagree with this. This is why I put forward an =
=E2=80=9Calternate" draft that is almost the same but simply adds the =
check before returning the configuration data.  I worry that  developers =
would have no incentive to do the two-step approach. They would just =
start at step 2 which in turn puts AS=E2=80=99s at risk of exposing =
tokens because it works. This makes OAuth promiscuous.
>>>>=20
>>>> Regarding existing implementations. Most of those implementations =
are for OIDC.  I think it makes sense for OIDF to continue use of OIDC's =
discovery spec because the UserInfo endpoint is well defined and the =
likelihood of a client mis-informed about the resource endpoint is not =
there.  IMO This does not apply to the broader OAuth community.
>>>>=20
>>>> Item 2:  It may be appropriate to have a separate configuration =
registry specification, but I think we should hold off until we have a =
complete solution and then make the decision what drafts should exist =
and how many pieces.  A big concern is the perceived complexity of =
multiple solutions and multiple drafts.
>>>>=20
>>>> As to John Bradley=E2=80=99s comments:
>>>>=20
>>>> Re: Discovery is the wrong place to mitigate threats.
>>>> I=E2=80=99m confused by this.  Our mandate was to solve a security =
threat by having a discovery specification to prevent clients being =
mis-lead about endpoints (of which resource service is one) in an oauth =
protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?
>>>>=20
>>>> Re: Your proposal for MITM mitigation
>>>> You propose that instead the resource endpoint check should be in =
the oauth protocol itself.  The difference is that validation is =
transferred back to the client to get it right. As well, without the =
client informing the AS, I can=E2=80=99t see a way for the AS to know =
what endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many cases.
>>>>=20
>>>> As a principle, the members have discussed many times that the AS =
service should do validation when possible =E2=80=94 this was =
particularly true at the Germany meeting when this came up. This is why =
I prefer the client tell the service provider what it intends to do and =
the service provider can fail that request immediately if necessary. We =
don=E2=80=99t have to depend on the developer getting the spec correct =
to fail the correct way.
>>>>=20
>>>> I worry that adding more parameters to the authz and token protocol =
flows increases complexity and attack surface. It also means per =
authorization validation has to take place vs. a one-time validation at =
config time.  Placing it in the configuration lookup phase (whether via =
web finger or just a special OAuth endpoint) seems more appropriate and =
far less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D
>>>>=20
>>>> That said, it may be that when we consider all the use cases, some =
combination of AS protocol and discovery may be both needed. I=E2=80=99m =
not ready to make conclusions about this.  The current oauth-discovery =
spec seems to put future generic clients at risk and that is my primary =
concern.
>>>>=20
>>>> Best Regards,
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones =
> =
wrote:
>>>>>=20
>>>>> Thanks for posting this, Phil.  It provides a concrete example of =
a way that protected resource discovery could be added to authorization =
server metadata discovery, and as such, should provide useful input for =
working group discussions on this topic.  It=E2=80=99s always great when =
someone takes the time to write an actual draft that can be examined and =
implemented, and I appreciate you doing that.
>>>>>=20
>>>>> The content of your draft points out that there appears to be =
complete agreement on what the authorization server metadata format =
should be, which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests that the =
authorization server metadata definitions in draft-ietf-oauth-discovery =
(which is now the whole normative content of the draft) are clearly =
ready for standardization, since even your alternative proposal includes =
them verbatim.
>>>>>=20
>>>>> Reading your draft, the problem I have with it is that you are =
returning the AS metadata only as a WebFinger response, rather than as =
an https-protected resource published by the authorization server.  The =
choice to only return this via WebFinger makes your draft incompatible =
with most deployed implementations of OAuth metadata, including the 22 =
implementations using it listed athttp://openid.net/certification/ =
 (see the =E2=80=9COP Config=E2=80=9D =
column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D library, which uses the metadata path for client =
configuration.=C2=A0 Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do. <>
>>>>>=20
>>>>> Therefore, I would request that you make these minor revisions to =
your draft and republish, so as to provide a unified way forward that is =
compatible with all known existing OAuth Discovery deployments:
>>>>> 1.       Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D to have the WebFinger request return the =
issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D=
 value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
>>>>> 2.       Reference the metadata definitions from Section 2 of =
draft-ietf-oauth-discovery, rather than duplicating them in your Section =
3.
>>>>>=20
>>>>> That would have the advantage of paring your draft down to only =
the new things that it proposes, enabling them to be more clearly =
understood and evaluated on their own merits.  I look forward to the =
discussions of ways of performing additional kinds of OAuth discovery, =
and consider your draft a valuable input to those discussions.
>>>>>=20
>>>>>                                                           Best =
wishes,
>>>>>                                                           -- Mike
>>>>>=20
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of John Bradley
>>>>> Sent: Sunday, March 13, 2016 6:45 PM
>>>>> To: Phil Hunt >
>>>>> Cc: oauth >
>>>>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>>>>=20
>>>>> As I have told Phil off list.
>>>>>=20
>>>>> Discovery is the wrong place to try and provide security against =
man in the middle attacks on the RS.
>>>>>=20
>>>>> This requires the client to know what the RS URI is before =
retrieving the information on the AS Configuration.
>>>>>=20
>>>>> The proposal Mike and I have been working on requires the client =
to have a notion of what API it is looking for and retrieve the =
.well-known file for that API from the issuer.   That allows a protocol =
like Connect to register its own config file that can point to the RS.
>>>>>=20
>>>>> If the API specific well known is not available the client can try =
the default oauth-server one.
>>>>>=20
>>>>> That then allows us to deal with restricting where AT are =
presented as part of the protocol rather then dragging discovery in as a =
requirement.
>>>>>=20
>>>>> In my opinion the resource the token is targeted to should be =
separated from the scope and returned as part of the meta-data about the =
AT along with scopes granted and expiry time.   We should also have a =
input parameter for resources so that a client can restrict tokens =
issued to a subset of the ones granted by the refresh token.   It would =
then also be possible to ask a AS for a token for a unregistered RS and =
have the AS produce a JWT access token with the resource as an audience =
if policy allows.
>>>>>=20
>>>>> That however was supposed to be dealt with as part of the mixed up =
client set of mitigations.
>>>>> In that the goal was to mitigate the attacks by returning =
meta-data about the tokens, and not to require discovery.
>>>>>=20
>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=
=9D for the code, and I intend to discuss at the F2F returning resource =
for AT as well.
>>>>>=20
>>>>> Those mitigate the attack.
>>>>>=20
>>>>> I will continue to resist mixing up discovery of configuration =
meta-data with mitigation of the attacks.
>>>>>=20
>>>>> We return meta-data about the tokens now, because AT are opaque to =
the client, we neglected to include some of the information for the =
client needs to be secure.   We just need to add that in to the existing =
flows.
>>>>>=20
>>>>> While Phil=E2=80=99s proposal is easier for the AS to implement as =
an add on, it puts more of a burden on the client needing to potentially =
change how it stores the relationships between AS and RS to prevent =
compromise, I think the solution should be biased towards simplicity on =
the client side.
>>>>>=20
>>>>> If we return the resources as part of the existing meta data the =
client checks that against the resource it intends to send the token to =
and if it is not in the list then it can=E2=80=99t send the token.  =
Simple check every time it gets a new AT, no optionality.
>>>>>=20
>>>>> I am not saying anything new Nat has been advocating basically =
this for some time, and dis submit a draft.   I prefer to return the =
info in the existing format rather than as link headers,  but that is =
the largest difference between what Nat and I are saying with respect to =
resource.
>>>>>=20
>>>>> That is the core of my problem with Phil=E2=80=99s draft.
>>>>>=20
>>>>> I guess we will need to have a long conversation in BA.
>>>>>=20
>>>>> Regards
>>>>> John B.
>>>>>=20
>>>>> On Mar 13, 2016, at 8:12 PM, Phil Hunt > wrote:
>>>>>=20
>>>>> This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry for =
OAuth Config Metadata as the authors believe that both solutions are not =
required, or depending on WG discussion they will be merged. The intent =
is to provide a simple complete draft for consideration.
>>>>>=20
>>>>> How it works...
>>>>> Given that a client has previously discovered an OAuth protected =
resource, the bound configuration method allows a client to return the =
configuration for an oauth authorization server that can issue tokens =
for the resource URI specified by the client.  The AS is not required to =
be in the same domain.  The AS is however required to know if it can =
issue tokens for a resource service (which presumes some agreement =
exists on tokens etc).
>>>>>=20
>>>>> The draft does not require that the resource exist (e.g. for =
unconfigured or new user based resources). It only requires that the AS =
service provider agrees it can issue tokens.
>>>>>=20
>>>>> =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.
>>>>>=20
>>>>> I propose that the WG consider the alternate draft carefully as =
well as other submissions and evaluate the broader discovery problem =
before proceeding with WGLC on OAuth Discovery.
>>>>>=20
>>>>> Thanks!
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Begin forwarded message:
>>>>>=20
>>>>> From: internet-drafts@ietf.org 
>>>>> Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>>>> Date: March 13, 2016 at 3:53:37 PM PDT
>>>>> To: "Phil Hunt" >, "Anthony Nadalin" >, "Tony Nadalin" >
>>>>>=20
>>>>>=20
>>>>> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>>>>> has been successfully submitted by Phil Hunt and posted to the
>>>>> IETF repository.
>>>>>=20
>>>>> Name:             draft-hunt-oauth-bound-config
>>>>> Revision:         00
>>>>> Title:               OAuth 2.0 Bound Configuration Lookup
>>>>> Document date:          2016-03-13
>>>>> Group:             Individual Submission
>>>>> Pages:              22
>>>>> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>>> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =

>>>>> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =

>>>>>=20
>>>>>=20
>>>>> Abstract:
>>>>>   This specification defines a mechanism for the client of an =
OAuth 2.0
>>>>>   protected resource service to obtain the configuration details =
of an
>>>>>   OAuth 2.0 authorization server that is capable of authorizing =
access
>>>>>   to a specific resource service.  The information includes the =
OAuth
>>>>>   2.0 component endpoint location URIs and as well as =
authorization
>>>>>   server capabilities.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> 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 .
>>>>>=20
>>>>> The IETF Secretariat
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_A2611D24-357E-487F-B593-19DDC71555CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I agree that this is valuable, and not just for PoP. In all =
honesty, it=E2=80=99s not even really required for PoP to function in =
many cases =E2=80=94 it=E2=80=99s just an optimization for one =
particular kind of key distribution mechanism in that case. 

    In the years of =
deployment experience with OAuth 2, I think we=E2=80=99ve really got =
three different kinds of things that currently get folded into =
=E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:


     - What things do I want to =
access? (photos, profile)
     - What actions do I =
want to take on these things? (read, write, delete)
     - How long do I want these tokens to work? =
(offline_access/refresh_token, one time use, next hour, etc)


    I think the first one is close to the audience/resource =
parameters that have been bandied about a few times, including in the =
current token exchange document. We should be consistent across drafts =
in that regard. The second is more traditional scope-ish. The third has =
been patched in with things like =E2=80=9Coffline_access=E2=80=9D in =
certain APIs.

    Just another vector to think about if we=E2=80=99re going to =
be adding things like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=
=9D or both to the token requests.

     =E2=80=94 Justin


    On =
Mar 14, 2016, at 6:26 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    Yes I will =
work on another proposal for allowing clients to specify what resource =
they want a token for and providing the meta-data to the client about =
the resources that a token is valid for.

    We have part of it in the POP key =
distribution spec and talked about separating it, as it is used more =
places than just for assigning keys.   
    I =
know some AS use different token formats for different RS so are =
all-ready needing to pass the resource in the request to avoid making a =
mess of scopes.

    John B.





    On Mar =
14, 2016, at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    Inline

    Phil

    On =
Mar 14, 2016, at 14:13, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    We had two mandates. =
 One was to provide a spec for AS metadata.   The other was to =
mitigate the client mixup attack.  The request was to do the latter =
without requiring the former for clients that don=E2=80=99t otherwise =
need discovery.
    There is no mandate for any of this. =
See http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt

    Returning =
the issuer and client_id from the authorization endpoint and the client =
checking them can be done by the client without =
discovery. 

    How does this address the issue of whether the client =
is talking to the wrong endpoint?

    Any client that has the resource and issuer hard coded =
probably doesn=E2=80=99t need discovery. =
 
    We agree


    One of the things that a =
client will need discovery for is to find the RS, so requiring the =
client to know the RS URI before getting the AS config seems backwards =
to me. 
    How can you make an assumption on =
order? You seem to be conflating authentication with authorization by =
assuming the identity drives what the resource is. 

    There are lots of =
applications that require user rights but are not identify centric. For =
example a document service. 

    Unless the client tells the AS where it intends to use the =
token we will be leaving a security hole because the bearer tokens will =
have too loose an audience if they have one at =
all.
    This is the biggest risk we have =
IMHO. 

    True you =
are telling the AS (Webfinger service) what the RS is but that is not at =
a place that is useful in the token production =
process.

    This=
 has nothing to do with token production. 

    What we want to ensure is whether an =
honest client is correctly configured and has not been mislead - eg by a =
phishing page. 

    I also think there are use cases where the AS doesn=E2=80=99t =
know all the possible RS.   That is not something that a out of =
band check can address.

    May be. =
Lets identify them. 

    There are also =
cases where a token might be good at multiple RS endpoints =
intentionally.

     In your =
solution the client would need to make a discovery request for each =
endpoint.
    Sure. Otherwise how would it know if =
there is one AS or a pool of AS servers assigned to each instance?
    Those requests lack the context of who the client and =
resource owner are.  I think that will be a problem in some use =
cases. 

    Not sure I agree. This is about discovering a valid set =
of endpoints. For mitm, we mainly want to check the hostname is correct. =
If a client chooses evil.com =
the cert can be valid and TLS will pass. How does it otherwise know it =
is supposed to talk to res.example.com?

    If this is added to the token endpoint it would be checked =
when code or refresh are exchanged, not every time the token is used. =
  
    Your proposal requires rhe client =
to check. I am not clear how the AS can know the exact uri. It is far =
easier to validate than to lookup since as you say the client may be =
authorized to use multiple ASs. 
    With a out of =
band check the client would never know if a RS was removed/revoked. =
 

    Not =
sure that is in scope. 

    None of the current proposals address =
this issue. 
     

    I don=E2=80=99t see checking when =
refreshing a token as something that is a huge =
burden.

    Still=
 its a lot more than once. 

    Why don't you draft another =
alternative?

    If the =
server wants to do the check on it=E2=80=99s side then we could require =
the client to send the RS URI in the token request. that way you really =
know the client is not going to get a token for the wrong RS =
endpoint.
    If you check out of band in discovery you =
really have no idea if the client is =
checking.

    In the new webfinger draft, the =
client isn't checking. The service provider simply does not disclose =
oauth information to misconfigured clients. 

    John B.
     


    On Mar 14, 2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    Thanks to Mike and John for their feedback.  I=E2=80=99ll =
take each in turn:

    Mike,

    Regarding your suggested =
amendments

    Item =
1: Returning the config URL would create two problems. One,it makes =
bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations).  

    The two-step process allows the current =
discovery process to continue. I disagree with this. This is why I put =
forward an =E2=80=9Calternate" draft that is almost the same but simply =
adds the check before returning the configuration data.  I worry =
that  developers would have no incentive to do the two-step =
approach. They would just start at step 2 which in turn puts AS=E2=80=99s =
at risk of exposing tokens because it works. This makes OAuth =
promiscuous.

    Regarding existing implementations. Most of those =
implementations are for OIDC.  I think it makes sense for OIDF to =
continue use of OIDC's discovery spec because the UserInfo endpoint is =
well defined and the likelihood of a client mis-informed about the =
resource endpoint is not there.  IMO This does not apply to the =
broader OAuth community.

    Item 2:  It may be appropriate to have a separate =
configuration registry specification, but I think we should hold off =
until we have a complete solution and then make the decision what drafts =
should exist and how many pieces.  A big concern is the perceived =
complexity of multiple solutions and multiple drafts.

    As to John Bradley=E2=80=99=
s comments:

    Re: =
Discovery is the wrong place to mitigate threats. 
    I=E2=80=99m confused by this.  Our mandate was to solve =
a security threat by having a discovery specification to prevent clients =
being mis-lead about endpoints (of which resource service is one) in an =
oauth protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?

    Re: Your proposal for MITM mitigation
    You =
propose that instead the resource endpoint check should be in the oauth =
protocol itself.  The difference is that validation is transferred =
back to the client to get it right. As well, without the client =
informing the AS, I can=E2=80=99t see a way for the AS to know what =
endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many =
cases.

    As a =
principle, the members have discussed many times that the AS service =
should do validation when possible =E2=80=94 this was particularly true =
at the Germany meeting when this came up. This is why I prefer the =
client tell the service provider what it intends to do and the service =
provider can fail that request immediately if necessary. We don=E2=80=99t =
have to depend on the developer getting the spec correct to fail the =
correct way.

    I =
worry that adding more parameters to the authz and token protocol flows =
increases complexity and attack surface. It also means per authorization =
validation has to take place vs. a one-time validation at config time. =
 Placing it in the configuration lookup phase (whether via web =
finger or just a special OAuth endpoint) seems more appropriate and far =
less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D

    That said, it may be that when we =
consider all the use cases, some combination of AS protocol and =
discovery may be both needed. I=E2=80=99m not ready to make conclusions =
about this.  The current oauth-discovery spec seems to put future =
generic clients at risk and that is my primary concern.

    Best Regards,

    




    

    

    On Mar 13, 2016, at 10:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

    Thanks for posting this, Phil.  It provides a concrete =
example of a way that protected resource discovery could be added to =
authorization server metadata discovery, and as such, should provide =
useful input for working group discussions on this topic.  It=E2=80=99=
s always great when someone takes the time to write an actual draft that =
can be examined and implemented, and I appreciate you doing that.
     
    The content of your draft =
points out that there appears to be complete agreement on what the =
authorization server metadata format should be, which is great!  =
I=E2=80=99ll note that Section 3 of draft-hunt-oauth-bound-config-00 =
titled =E2=80=9CAuthorization Server Metadata=E2=80=9D is an exact copy =
of Section 2 of draft-ietf-oauth-discovery-01 (with the same title), =
modulo applying a correction suggested by the working group.  To me =
this suggests that the authorization server metadata definitions in =
draft-ietf-oauth-discovery (which is now the whole normative content of =
the draft) are clearly ready for standardization, since even your =
alternative proposal includes them verbatim.
     
    Reading your draft, the =
problem I have with it is that you are returning the AS metadata only as =
a WebFinger response, rather than as an https-protected resource =
published by the authorization server.  The choice to only return =
this via WebFinger makes your draft incompatible with most deployed =
implementations of OAuth metadata, including the 22 implementations =
using it listed athttp://openid.net/certification/ (see the =E2=80=9COP =
Config=E2=80=9D column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CADAL=E2=
=80=9D library, which uses the metadata path for client =
configuration.  Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do.
     
    Therefore, I =
would request that you make these minor revisions to your draft and =
republish, so as to provide a unified way forward that is compatible =
with all known existing OAuth Discovery deployments:
    1.       Modify your section 2 =E2=80=9CAuthorization =
Server WebFinger Discovery=E2=80=9D to have the WebFinger request return =
the issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=
=80=9D value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
    2.       Reference the metadata definitions from =
Section 2 of draft-ietf-oauth-discovery, rather than duplicating them in =
your Section 3.
     
    That would have =
the advantage of paring your draft down to only the new things that it =
proposes, enabling them to be more clearly understood and evaluated on =
their own merits.  I look forward to the discussions of ways of =
performing additional kinds of OAuth discovery, and consider your draft =
a valuable input to those discussions.
     
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          Best =
wishes,
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
    Sent: Sunday, March 13, 2016 6:45 =
PM
    To: Phil Hunt <phil.hunt@oracle.com>
    Cc: oauth=
 <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    As I have told Phil off list.  
     
    Discovery is the wrong place to try and =
provide security against man in the middle attacks on the RS.
     
    This requires the client to know what the =
RS URI is before retrieving the information on the AS Configuration.
     
    The proposal Mike and I have been working =
on requires the client to have a notion of what API it is looking for =
and retrieve the .well-known file for that API from the issuer.   =
That allows a protocol like Connect to register its own config file that =
can point to the RS.   
     
    If the API specific well known is not available the =
client can try the default oauth-server one.
     
    That then allows us to deal with =
restricting where AT are presented as part of the protocol rather then =
dragging discovery in as a requirement.
     
    In my opinion the resource the token is =
targeted to should be separated from the scope and returned as part of =
the meta-data about the AT along with scopes granted and expiry time. =
  We should also have a input parameter for resources so that a =
client can restrict tokens issued to a subset of the ones granted by the =
refresh token.   It would then also be possible to ask a AS for a =
token for a unregistered RS and have the AS produce a JWT access token =
with the resource as an audience if policy allows.
     
    That however was supposed to be dealt =
with as part of the mixed up client set of mitigations.  
    In that the goal was to mitigate the attacks by returning =
meta-data about the tokens, and not to require discovery.
     
    We intend to return =E2=80=9Ciss=E2=80=9D =
and =E2=80=9Ccleint_id=E2=80=9D for the code, and I intend to discuss at =
the F2F returning resource for AT as well.
     
    Those mitigate the attack.  
     
    I will continue to resist mixing up =
discovery of configuration meta-data with mitigation of the attacks.
     
    We return meta-data about the tokens now, =
because AT are opaque to the client, we neglected to include some of the =
information for the client needs to be secure.   We just need to =
add that in to the existing flows.
     
    While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add on, it puts more of a burden on the client needing =
to potentially change how it stores the relationships between AS and RS =
to prevent compromise, I think the solution should be biased towards =
simplicity on the client side.
     
    If we return the resources as part of the existing =
meta data the client checks that against the resource it intends to send =
the token to and if it is not in the list then it can=E2=80=99t send the =
token.  Simple check every time it gets a new AT, no =
optionality.
     
    I am not saying anything new Nat has been advocating =
basically this for some time, and dis submit a draft.   I prefer to =
return the info in the existing format rather than as link headers, =
 but that is the largest difference between what Nat and I are =
saying with respect to resource.
     
    That is the core of my problem with Phil=E2=80=99s =
draft.
     
    I guess we will need to have a long conversation in =
BA.
     
    Regards
    John B.
     
    On =
Mar 13, 2016, at 8:12 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
     
    This draft is a =
proposed alternate proposal for draft-ietf-oauth-discovery.  As =
such, it contains the same registry for OAuth Config Metadata as the =
authors believe that both solutions are not required, or depending on WG =
discussion they will be merged. The intent is to provide a simple =
complete draft for consideration.
     
    How it works...
    Given that a client =
has previously discovered an OAuth protected resource, the bound =
configuration method allows a client to return the configuration for an =
oauth authorization server that can issue tokens for the resource URI =
specified by the client.  The AS is not required to be in the same =
domain.  The AS is however required to know if it can issue tokens =
for a resource service (which presumes some agreement exists on tokens =
etc).
     
    The draft does not require that the resource exist =
(e.g. for unconfigured or new user based resources). It only requires =
that the AS service provider agrees it can issue tokens.
     
    =46rom a security perspective, returning =
the OAuth service configuration for a specified resource URI serves to =
confirm the client is in possession of a valid resource URI ensuring the =
client has received a valid set of endpoints for the resource and the =
associated oauth services.
     
    I propose that the WG consider the alternate draft =
carefully as well as other submissions and evaluate the broader =
discovery problem before proceeding with WGLC on OAuth Discovery.
     
    Thanks!
     
    Phil
     
    @independentid
    www.independentid.com
     


    Begin forwarded message:
     
    Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
    Date: March 13, 2016 =
at 3:53:37 PM PDT
    To: "Phil Hunt" =
<phil.hunt@yahoo.com>, =
"Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>
     

    A new version of =
I-D, draft-hunt-oauth-bound-config-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:        &=
nbsp;    draft-hunt-oauth-bound=
-config
    Revision:        <=
span class=3D"Apple-converted-space"> 00
    Title:        &=
nbsp;      OAuth 2.0 Bound =
Configuration Lookup
    Document date:        &=
nbsp; 2016-03-13
    Group:        &=
nbsp;    Individual =
Submission
    Pages:        &=
nbsp;     22
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

    Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


    Abstract:
      This specification defines a mechanism for the =
client of an OAuth 2.0
      protected resource =
service to obtain the configuration details of an
      OAuth 2.0 authorization server that is capable of =
authorizing access
      to a specific resource =
service.  The information includes the OAuth
      2.0 component endpoint location URIs and as well =
as authorization
      server capabilities.




    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.

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


    <=
br =
class=3D"">
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    =

--Apple-Mail=_A2611D24-357E-487F-B593-19DDC71555CA--

--Apple-Mail=_1FD2BF43-D8F1-44AE-8A0A-F70301EE10CB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJW5z7TAAoJEDPAngkbd+w9xqIH/0n1EJ7udJB3GNio40hUtoLU
dDwqI3XMJBWdEc8Tg5Qe7F8lJnTb7cJF7PxQAtzHAbwSmLOMCCGJ/XgQCZ/6JgXe
bCujW32GGOapP2l/mWrHFqI4dVFJljw/ojfHbDx5ZB1fgzj+1f6Tcs06O5Hi0rVr
vnVAIB9Q4WzhM5r5OmvEoEEcKP07CqN+JENj5ZEtvaYs4zhVnb4JzGpb8OlmVN5/
TpGhOc5yyEWeoKFGMfvmQnaZLZFC6fIeVtW8qKZj/PCXqpuc10SG6B72UGK+g+pQ
M2GUKdwbciEw67qGZKEHvbo2inMOPPHUu7dRfgpTIWcdUCj8hAmdci86KlplyTE=
=HjLc
-----END PGP SIGNATURE-----

--Apple-Mail=_1FD2BF43-D8F1-44AE-8A0A-F70301EE10CB--


From nobody Mon Mar 14 16:29:33 2016
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 B21D312D6A0 for ; Mon, 14 Mar 2016 16:29:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 6lR29f7ws-0b for ; Mon, 14 Mar 2016 16:29:26 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 DD88F12D807 for ; Mon, 14 Mar 2016 16:29:12 -0700 (PDT)
Received: by mail-qg0-x232.google.com with SMTP id t4so494629qge.0 for ; Mon, 14 Mar 2016 16:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=vKlMlgZi85rpeXs72ZiJwGvrpee7g9cyvDOhKWLVIPM=; b=DObesWKeqiF9wVsHCzIG1pzOwiCXi8ZgY22HOaKzNXKMSo5fXysucZfx08gxUNQNoi cpRJVNPlVH3DVAIxUeu4tRyFsvMoW/eZ9p+n9dkmLU7AXf0nHzz4L7o4Ts2h4auMahMc r6rtnz2GON7MUs8br7+fxV4ttGl3DgnkxnPUCRG/sn11ezZV2YSEdbuazBQ55vnWWgLO GRZfdamDHdIt+pG8zOxO5he/Iw2VYLOEPAnxHwZ7uoqu4U1mBHZ+QBR5cGNq9lEITIt8 PGUD8UeKxCi2vNul6okgw0inerbkS8zQNmfh53F1HMNV3pJ3fgTX1+GjD/6FdJWqj3Um 9WOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vKlMlgZi85rpeXs72ZiJwGvrpee7g9cyvDOhKWLVIPM=; b=hyT0XofgYYMuqLR4tNXUaejkYrNOxM1xDXX5+5BRhkp+N0kUNDBd+ZMTfrcWFr48N5 QVb16Xx4bsG6trUBVH4k19bI/76TxtQ/vYYkxidRF14rfJhkGDSnEF8gAbqWluCFNQiv /sooT4YjfWVm/1LnwgJ+DzEnzWYyn3CEh5wLSNNrPfqix/zscvCYhsEGjP7Y7ubyQRSM ErTru2cHThF+TtAMTIqxH7lrTiEJCJhfi2nDO5c+v22RZo23PjOcdwqfnXNPEnl2n9m5 zPK815IFk99SpjphjvmJXzLFJ6XoHGAPncNuYIh4FB935KP2yvb3UcWdM9ytVP9Mo9ti luJg==
X-Gm-Message-State: AD7BkJJyCBjQSFRxzWBZFEVH2nfVPs8lgLipJhAjUGr+IHECxfkwXcIPke5AhLHYmnMgDg==
X-Received: by 10.140.98.71 with SMTP id n65mr33563756qge.22.1457998151770; Mon, 14 Mar 2016 16:29:11 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.161.145]) by smtp.gmail.com with ESMTPSA id j68sm11380114qge.41.2016.03.14.16.29.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Mar 2016 16:29:10 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_021F869E-B27B-4496-97A3-9D09BA36C27B"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu>
Date: Mon, 14 Mar 2016 20:29:06 -0300
Message-Id: <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu>
To: Justin Richer 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 23:29:32 -0000

--Apple-Mail=_021F869E-B27B-4496-97A3-9D09BA36C27B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_654ECEB7-990A-4B55-A2A7-5D85D5F87C28"


--Apple-Mail=_654ECEB7-990A-4B55-A2A7-5D85D5F87C28
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes Brian and I discussed the reasons for separating =
audience/resource/destination from scope yesterday, and how that might =
impact token exchange and the need to align.

I think this is a core problem that needs to be addressed.  =20

The mixup at the resource is posable because scope is too overloaded.  =
Unless scopes were structured the client can=E2=80=99t tell what =
resource servers apply to a given scope.
The AS winds up applying the wrong audience to the AT, and the client =
has no way to tell.

There is no problem with giving a AT to a bad  or unknown RS.  That =
needs to be made safe by putting the correct audience in the AT. =20
To do that the AS needs to know where the client is going to use the =
token so it can produce the correct token type and include the correct =
audience.

I agree that we also see a lot of hacks around using scopes and other =
mechanisms to indicate requested token validity time.

Scope is too overloaded, and we don=E2=80=99t return sufficient token =
meta-data with the opaque tokens.  =20
We need to address the core problem and not patch a symptom by adding =
external discovery.

John B.



> On Mar 14, 2016, at 7:44 PM, Justin Richer  wrote:
>=20
> I agree that this is valuable, and not just for PoP. In all honesty, =
it=E2=80=99s not even really required for PoP to function in many cases =
=E2=80=94 it=E2=80=99s just an optimization for one particular kind of =
key distribution mechanism in that case.=20
>=20
> In the years of deployment experience with OAuth 2, I think we=E2=80=99v=
e really got three different kinds of things that currently get folded =
into =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:
>=20
>=20
>  - What things do I want to access? (photos, profile)
>  - What actions do I want to take on these things? (read, write, =
delete)
>  - How long do I want these tokens to work? =
(offline_access/refresh_token, one time use, next hour, etc)
>=20
>=20
> I think the first one is close to the audience/resource parameters =
that have been bandied about a few times, including in the current token =
exchange document. We should be consistent across drafts in that regard. =
The second is more traditional scope-ish. The third has been patched in =
with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.
>=20
> Just another vector to think about if we=E2=80=99re going to be adding =
things like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.
>=20
>  =E2=80=94 Justin
>=20
>=20
>> On Mar 14, 2016, at 6:26 PM, John Bradley > wrote:
>>=20
>> Yes I will work on another proposal for allowing clients to specify =
what resource they want a token for and providing the meta-data to the =
client about the resources that a token is valid for.
>>=20
>> We have part of it in the POP key distribution spec and talked about =
separating it, as it is used more places than just for assigning keys.  =20=

>> I know some AS use different token formats for different RS so are =
all-ready needing to pass the resource in the request to avoid making a =
mess of scopes.
>>=20
>> John B.
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) > wrote:
>>>=20
>>> Inline
>>>=20
>>> Phil
>>>=20
>>> On Mar 14, 2016, at 14:13, John Bradley > wrote:
>>>=20
>>>> We had two mandates.  One was to provide a spec for AS metadata.   =
The other was to mitigate the client mixup attack.  The request was to =
do the latter without requiring the former for clients that don=E2=80=99t =
otherwise need discovery.
>>> There is no mandate for any of this. See =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =

>>>>=20
>>>> Returning the issuer and client_id from the authorization endpoint =
and the client checking them can be done by the client without =
discovery.=20
>>>=20
>>> How does this address the issue of whether the client is talking to =
the wrong endpoint?
>>>>=20
>>>> Any client that has the resource and issuer hard coded probably =
doesn=E2=80=99t need discovery. =20
>>> We agree
>>>=20
>>>=20
>>>> One of the things that a client will need discovery for is to find =
the RS, so requiring the client to know the RS URI before getting the AS =
config seems backwards to me.=20
>>> How can you make an assumption on order? You seem to be conflating =
authentication with authorization by assuming the identity drives what =
the resource is.=20
>>>=20
>>> There are lots of applications that require user rights but are not =
identify centric. For example a document service.=20
>>>>=20
>>>> Unless the client tells the AS where it intends to use the token we =
will be leaving a security hole because the bearer tokens will have too =
loose an audience if they have one at all.
>>> This is the biggest risk we have IMHO.=20
>>>>=20
>>>> True you are telling the AS (Webfinger service) what the RS is but =
that is not at a place that is useful in the token production process.
>>>=20
>>> This has nothing to do with token production.=20
>>>=20
>>> What we want to ensure is whether an honest client is correctly =
configured and has not been mislead - eg by a phishing page.=20
>>>>=20
>>>> I also think there are use cases where the AS doesn=E2=80=99t know =
all the possible RS.   That is not something that a out of band check =
can address.
>>>=20
>>> May be. Lets identify them.=20
>>>=20
>>>> There are also cases where a token might be good at multiple RS =
endpoints intentionally.
>>>=20
>>>>  In your solution the client would need to make a discovery request =
for each endpoint.
>>> Sure. Otherwise how would it know if there is one AS or a pool of AS =
servers assigned to each instance?
>>>> Those requests lack the context of who the client and resource =
owner are.  I think that will be a problem in some use cases.=20
>>>=20
>>> Not sure I agree. This is about discovering a valid set of =
endpoints. For mitm, we mainly want to check the hostname is correct. If =
a client chooses evil.com  the cert can be valid and =
TLS will pass. How does it otherwise know it is supposed to talk to =
res.example.com ?
>>>>=20
>>>> If this is added to the token endpoint it would be checked when =
code or refresh are exchanged, not every time the token is used.  =20
>>> Your proposal requires rhe client to check. I am not clear how the =
AS can know the exact uri. It is far easier to validate than to lookup =
since as you say the client may be authorized to use multiple ASs.=20
>>>> With a out of band check the client would never know if a RS was =
removed/revoked. =20
>>>=20
>>> Not sure that is in scope.=20
>>>=20
>>> None of the current proposals address this issue.=20
>>>> =20
>>>>=20
>>>> I don=E2=80=99t see checking when refreshing a token as something =
that is a huge burden.
>>>=20
>>> Still its a lot more than once.=20
>>>=20
>>> Why don't you draft another alternative?
>>>>=20
>>>> If the server wants to do the check on it=E2=80=99s side then we =
could require the client to send the RS URI in the token request. that =
way you really know the client is not going to get a token for the wrong =
RS endpoint.
>>>> If you check out of band in discovery you really have no idea if =
the client is checking.
>>>=20
>>> In the new webfinger draft, the client isn't checking. The service =
provider simply does not disclose oauth information to misconfigured =
clients.=20
>>>>=20
>>>> John B.
>>>> =20
>>>>=20
>>>>=20
>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt > wrote:
>>>>>=20
>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take =
each in turn:
>>>>>=20
>>>>> Mike,
>>>>>=20
>>>>> Regarding your suggested amendments
>>>>>=20
>>>>> Item 1: Returning the config URL would create two problems. One,it =
makes bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations). =20
>>>>>=20
>>>>> The two-step process allows the current discovery process to =
continue. I disagree with this. This is why I put forward an =
=E2=80=9Calternate" draft that is almost the same but simply adds the =
check before returning the configuration data.  I worry that  developers =
would have no incentive to do the two-step approach. They would just =
start at step 2 which in turn puts AS=E2=80=99s at risk of exposing =
tokens because it works. This makes OAuth promiscuous.
>>>>>=20
>>>>> Regarding existing implementations. Most of those implementations =
are for OIDC.  I think it makes sense for OIDF to continue use of OIDC's =
discovery spec because the UserInfo endpoint is well defined and the =
likelihood of a client mis-informed about the resource endpoint is not =
there.  IMO This does not apply to the broader OAuth community.
>>>>>=20
>>>>> Item 2:  It may be appropriate to have a separate configuration =
registry specification, but I think we should hold off until we have a =
complete solution and then make the decision what drafts should exist =
and how many pieces.  A big concern is the perceived complexity of =
multiple solutions and multiple drafts.
>>>>>=20
>>>>> As to John Bradley=E2=80=99s comments:
>>>>>=20
>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a security =
threat by having a discovery specification to prevent clients being =
mis-lead about endpoints (of which resource service is one) in an oauth =
protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?
>>>>>=20
>>>>> Re: Your proposal for MITM mitigation
>>>>> You propose that instead the resource endpoint check should be in =
the oauth protocol itself.  The difference is that validation is =
transferred back to the client to get it right. As well, without the =
client informing the AS, I can=E2=80=99t see a way for the AS to know =
what endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many cases.
>>>>>=20
>>>>> As a principle, the members have discussed many times that the AS =
service should do validation when possible =E2=80=94 this was =
particularly true at the Germany meeting when this came up. This is why =
I prefer the client tell the service provider what it intends to do and =
the service provider can fail that request immediately if necessary. We =
don=E2=80=99t have to depend on the developer getting the spec correct =
to fail the correct way.
>>>>>=20
>>>>> I worry that adding more parameters to the authz and token =
protocol flows increases complexity and attack surface. It also means =
per authorization validation has to take place vs. a one-time validation =
at config time.  Placing it in the configuration lookup phase (whether =
via web finger or just a special OAuth endpoint) seems more appropriate =
and far less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D
>>>>>=20
>>>>> That said, it may be that when we consider all the use cases, some =
combination of AS protocol and discovery may be both needed. I=E2=80=99m =
not ready to make conclusions about this.  The current oauth-discovery =
spec seems to put future generic clients at risk and that is my primary =
concern.
>>>>>=20
>>>>> Best Regards,
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones =
> =
wrote:
>>>>>>=20
>>>>>> Thanks for posting this, Phil.  It provides a concrete example of =
a way that protected resource discovery could be added to authorization =
server metadata discovery, and as such, should provide useful input for =
working group discussions on this topic.  It=E2=80=99s always great when =
someone takes the time to write an actual draft that can be examined and =
implemented, and I appreciate you doing that.
>>>>>> =20
>>>>>> The content of your draft points out that there appears to be =
complete agreement on what the authorization server metadata format =
should be, which is great!  I=E2=80=99ll note that Section 3 of =
draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server =
Metadata=E2=80=9D is an exact copy of Section 2 of =
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a =
correction suggested by the working group.  To me this suggests that the =
authorization server metadata definitions in draft-ietf-oauth-discovery =
(which is now the whole normative content of the draft) are clearly =
ready for standardization, since even your alternative proposal includes =
them verbatim.
>>>>>> =20
>>>>>> Reading your draft, the problem I have with it is that you are =
returning the AS metadata only as a WebFinger response, rather than as =
an https-protected resource published by the authorization server.  The =
choice to only return this via WebFinger makes your draft incompatible =
with most deployed implementations of OAuth metadata, including the 22 =
implementations using it listed athttp://openid.net/certification/ =
 (see the =E2=80=9COP Config=E2=80=9D =
column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D library, which uses the metadata path for client =
configuration.=C2=A0 Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do. <>
>>>>>> =20
>>>>>> Therefore, I would request that you make these minor revisions to =
your draft and republish, so as to provide a unified way forward that is =
compatible with all known existing OAuth Discovery deployments:
>>>>>> 1.       Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D to have the WebFinger request return the =
issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D=
 value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
>>>>>> 2.       Reference the metadata definitions from Section 2 of =
draft-ietf-oauth-discovery, rather than duplicating them in your Section =
3.
>>>>>> =20
>>>>>> That would have the advantage of paring your draft down to only =
the new things that it proposes, enabling them to be more clearly =
understood and evaluated on their own merits.  I look forward to the =
discussions of ways of performing additional kinds of OAuth discovery, =
and consider your draft a valuable input to those discussions.
>>>>>> =20
>>>>>>                                                           Best =
wishes,
>>>>>>                                                           -- Mike
>>>>>> =20
>>>>>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of John Bradley
>>>>>> Sent: Sunday, March 13, 2016 6:45 PM
>>>>>> To: Phil Hunt >
>>>>>> Cc: oauth >
>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>>>>> =20
>>>>>> As I have told Phil off list. =20
>>>>>> =20
>>>>>> Discovery is the wrong place to try and provide security against =
man in the middle attacks on the RS.
>>>>>> =20
>>>>>> This requires the client to know what the RS URI is before =
retrieving the information on the AS Configuration.
>>>>>> =20
>>>>>> The proposal Mike and I have been working on requires the client =
to have a notion of what API it is looking for and retrieve the =
.well-known file for that API from the issuer.   That allows a protocol =
like Connect to register its own config file that can point to the RS.  =20=

>>>>>> =20
>>>>>> If the API specific well known is not available the client can =
try the default oauth-server one.
>>>>>> =20
>>>>>> That then allows us to deal with restricting where AT are =
presented as part of the protocol rather then dragging discovery in as a =
requirement.
>>>>>> =20
>>>>>> In my opinion the resource the token is targeted to should be =
separated from the scope and returned as part of the meta-data about the =
AT along with scopes granted and expiry time.   We should also have a =
input parameter for resources so that a client can restrict tokens =
issued to a subset of the ones granted by the refresh token.   It would =
then also be possible to ask a AS for a token for a unregistered RS and =
have the AS produce a JWT access token with the resource as an audience =
if policy allows.
>>>>>> =20
>>>>>> That however was supposed to be dealt with as part of the mixed =
up client set of mitigations. =20
>>>>>> In that the goal was to mitigate the attacks by returning =
meta-data about the tokens, and not to require discovery.
>>>>>> =20
>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=
=80=9D for the code, and I intend to discuss at the F2F returning =
resource for AT as well.
>>>>>> =20
>>>>>> Those mitigate the attack. =20
>>>>>> =20
>>>>>> I will continue to resist mixing up discovery of configuration =
meta-data with mitigation of the attacks.
>>>>>> =20
>>>>>> We return meta-data about the tokens now, because AT are opaque =
to the client, we neglected to include some of the information for the =
client needs to be secure.   We just need to add that in to the existing =
flows.
>>>>>> =20
>>>>>> While Phil=E2=80=99s proposal is easier for the AS to implement =
as an add on, it puts more of a burden on the client needing to =
potentially change how it stores the relationships between AS and RS to =
prevent compromise, I think the solution should be biased towards =
simplicity on the client side.
>>>>>> =20
>>>>>> If we return the resources as part of the existing meta data the =
client checks that against the resource it intends to send the token to =
and if it is not in the list then it can=E2=80=99t send the token.  =
Simple check every time it gets a new AT, no optionality.
>>>>>> =20
>>>>>> I am not saying anything new Nat has been advocating basically =
this for some time, and dis submit a draft.   I prefer to return the =
info in the existing format rather than as link headers,  but that is =
the largest difference between what Nat and I are saying with respect to =
resource.
>>>>>> =20
>>>>>> That is the core of my problem with Phil=E2=80=99s draft.
>>>>>> =20
>>>>>> I guess we will need to have a long conversation in BA.
>>>>>> =20
>>>>>> Regards
>>>>>> John B.
>>>>>> =20
>>>>>> On Mar 13, 2016, at 8:12 PM, Phil Hunt > wrote:
>>>>>> =20
>>>>>> This draft is a proposed alternate proposal for =
draft-ietf-oauth-discovery.  As such, it contains the same registry for =
OAuth Config Metadata as the authors believe that both solutions are not =
required, or depending on WG discussion they will be merged. The intent =
is to provide a simple complete draft for consideration.
>>>>>> =20
>>>>>> How it works...
>>>>>> Given that a client has previously discovered an OAuth protected =
resource, the bound configuration method allows a client to return the =
configuration for an oauth authorization server that can issue tokens =
for the resource URI specified by the client.  The AS is not required to =
be in the same domain.  The AS is however required to know if it can =
issue tokens for a resource service (which presumes some agreement =
exists on tokens etc).
>>>>>> =20
>>>>>> The draft does not require that the resource exist (e.g. for =
unconfigured or new user based resources). It only requires that the AS =
service provider agrees it can issue tokens.
>>>>>> =20
>>>>>> =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.
>>>>>> =20
>>>>>> I propose that the WG consider the alternate draft carefully as =
well as other submissions and evaluate the broader discovery problem =
before proceeding with WGLC on OAuth Discovery.
>>>>>> =20
>>>>>> Thanks!
>>>>>> =20
>>>>>> Phil
>>>>>> =20
>>>>>> @independentid
>>>>>> www.independentid.com 
>>>>>> phil.hunt@oracle.com 
>>>>>> =20
>>>>>>=20
>>>>>>=20
>>>>>> Begin forwarded message:
>>>>>> =20
>>>>>> From: internet-drafts@ietf.org 
>>>>>> Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>>>>> Date: March 13, 2016 at 3:53:37 PM PDT
>>>>>> To: "Phil Hunt" >, "Anthony Nadalin" >, "Tony Nadalin" >
>>>>>> =20
>>>>>>=20
>>>>>> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>>>>>> has been successfully submitted by Phil Hunt and posted to the
>>>>>> IETF repository.
>>>>>>=20
>>>>>> Name:             draft-hunt-oauth-bound-config
>>>>>> Revision:         00
>>>>>> Title:               OAuth 2.0 Bound Configuration Lookup
>>>>>> Document date:          2016-03-13
>>>>>> Group:             Individual Submission
>>>>>> Pages:              22
>>>>>> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>>>> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =

>>>>>> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =

>>>>>>=20
>>>>>>=20
>>>>>> Abstract:
>>>>>>   This specification defines a mechanism for the client of an =
OAuth 2.0
>>>>>>   protected resource service to obtain the configuration details =
of an
>>>>>>   OAuth 2.0 authorization server that is capable of authorizing =
access
>>>>>>   to a specific resource service.  The information includes the =
OAuth
>>>>>>   2.0 component endpoint location URIs and as well as =
authorization
>>>>>>   server capabilities.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 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 .
>>>>>>=20
>>>>>> The IETF Secretariat
>>>>>>=20
>>>>>> =20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_654ECEB7-990A-4B55-A2A7-5D85D5F87C28
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes Brian and I discussed the reasons for separating =
audience/resource/destination from scope yesterday, and how that might =
impact token exchange and the need to align.

    I think this is a core problem that =
needs to be addressed.   

    The mixup at the resource is posable =
because scope is too overloaded.  Unless scopes were structured the =
client can=E2=80=99t tell what resource servers apply to a given =
scope.
    The AS winds up applying the wrong audience =
to the AT, and the client has no way to tell.

    There is no problem with giving a AT to =
a bad  or unknown RS.  That needs to be made safe by putting =
the correct audience in the AT.  
    To do that =
the AS needs to know where the client is going to use the token so it =
can produce the correct token type and include the correct =
audience.

    I =
agree that we also see a lot of hacks around using scopes and other =
mechanisms to indicate requested token validity time.

    Scope is too overloaded, =
and we don=E2=80=99t return sufficient token meta-data with the opaque =
tokens.   
    We need to address the core =
problem and not patch a symptom by adding external discovery.

    John B.



    On Mar 14, 2016, at 7:44 PM, =
Justin Richer <jricher@mit.edu> wrote:

    I agree that =
this is valuable, and not just for PoP. In all honesty, it=E2=80=99s not =
even really required for PoP to function in many cases =E2=80=94 it=E2=80=99=
s just an optimization for one particular kind of key distribution =
mechanism in that case. 

    In the years of deployment experience with OAuth 2, I think =
we=E2=80=99ve really got three different kinds of things that currently =
get folded into =E2=80=9Cscope=E2=80=9D that we might want to try =
separating out better:


     - What things do I =
want to access? (photos, profile)
     - What =
actions do I want to take on these things? (read, write, =
delete)
     - How long do I want these tokens to =
work? (offline_access/refresh_token, one time use, next hour, =
etc)


    I think the first one is close to the =
audience/resource parameters that have been bandied about a few times, =
including in the current token exchange document. We should be =
consistent across drafts in that regard. The second is more traditional =
scope-ish. The third has been patched in with things like =
=E2=80=9Coffline_access=E2=80=9D in certain APIs.
    Just another vector to think about if =
we=E2=80=99re going to be adding things like =E2=80=9Caudience=E2=80=9D =
or =E2=80=9Cresource=E2=80=9D or both to the token requests.

     =E2=80=94 =
Justin


    On Mar 14, 2016, at 6:26 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    Yes I will =
work on another proposal for allowing clients to specify what resource =
they want a token for and providing the meta-data to the client about =
the resources that a token is valid for.

    We have part of it in the POP key =
distribution spec and talked about separating it, as it is used more =
places than just for assigning keys.   
    I =
know some AS use different token formats for different RS so are =
all-ready needing to pass the resource in the request to avoid making a =
mess of scopes.

    John B.





    On Mar =
14, 2016, at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    Inline

    Phil

    On =
Mar 14, 2016, at 14:13, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    We had two mandates. =
 One was to provide a spec for AS metadata.   The other was to =
mitigate the client mixup attack.  The request was to do the latter =
without requiring the former for clients that don=E2=80=99t otherwise =
need discovery.
    There is no mandate for any of this. =
See http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt

    Returning =
the issuer and client_id from the authorization endpoint and the client =
checking them can be done by the client without =
discovery. 

    How does this address the issue of whether the client =
is talking to the wrong endpoint?

    Any client that has the resource and issuer hard coded =
probably doesn=E2=80=99t need discovery. =
 
    We agree


    One of the things that a =
client will need discovery for is to find the RS, so requiring the =
client to know the RS URI before getting the AS config seems backwards =
to me. 
    How can you make an assumption on =
order? You seem to be conflating authentication with authorization by =
assuming the identity drives what the resource is. 

    There are lots of =
applications that require user rights but are not identify centric. For =
example a document service. 

    Unless the client tells the AS where it intends to use the =
token we will be leaving a security hole because the bearer tokens will =
have too loose an audience if they have one at =
all.
    This is the biggest risk we have =
IMHO. 

    True you =
are telling the AS (Webfinger service) what the RS is but that is not at =
a place that is useful in the token production =
process.

    This=
 has nothing to do with token production. 

    What we want to ensure is whether an =
honest client is correctly configured and has not been mislead - eg by a =
phishing page. 

    I also think there are use cases where the AS doesn=E2=80=99t =
know all the possible RS.   That is not something that a out of =
band check can address.

    May be. =
Lets identify them. 

    There are also =
cases where a token might be good at multiple RS endpoints =
intentionally.

     In your =
solution the client would need to make a discovery request for each =
endpoint.
    Sure. Otherwise how would it know if =
there is one AS or a pool of AS servers assigned to each instance?
    Those requests lack the context of who the client and =
resource owner are.  I think that will be a problem in some use =
cases. 

    Not sure I agree. This is about discovering a valid set =
of endpoints. For mitm, we mainly want to check the hostname is correct. =
If a client chooses evil.com =
the cert can be valid and TLS will pass. How does it otherwise know it =
is supposed to talk to res.example.com?

    If this is added to the token endpoint it would be checked =
when code or refresh are exchanged, not every time the token is used. =
  
    Your proposal requires rhe client =
to check. I am not clear how the AS can know the exact uri. It is far =
easier to validate than to lookup since as you say the client may be =
authorized to use multiple ASs. 
    With a out of =
band check the client would never know if a RS was removed/revoked. =
 

    Not =
sure that is in scope. 

    None of the current proposals address =
this issue. 
     

    I don=E2=80=99t see checking when =
refreshing a token as something that is a huge =
burden.

    Still=
 its a lot more than once. 

    Why don't you draft another =
alternative?

    If the =
server wants to do the check on it=E2=80=99s side then we could require =
the client to send the RS URI in the token request. that way you really =
know the client is not going to get a token for the wrong RS =
endpoint.
    If you check out of band in discovery you =
really have no idea if the client is =
checking.

    In the new webfinger draft, the =
client isn't checking. The service provider simply does not disclose =
oauth information to misconfigured clients. 

    John B.
     


    On Mar 14, 2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    Thanks to Mike and John for their feedback.  I=E2=80=99ll =
take each in turn:

    Mike,

    Regarding your suggested =
amendments

    Item =
1: Returning the config URL would create two problems. One,it makes =
bound discovery a two-step process - that adds complexity.  It =
seems far simpler to mandate TLS (which I think it already does in the =
security considerations).  

    The two-step process allows the current =
discovery process to continue. I disagree with this. This is why I put =
forward an =E2=80=9Calternate" draft that is almost the same but simply =
adds the check before returning the configuration data.  I worry =
that  developers would have no incentive to do the two-step =
approach. They would just start at step 2 which in turn puts AS=E2=80=99s =
at risk of exposing tokens because it works. This makes OAuth =
promiscuous.

    Regarding existing implementations. Most of those =
implementations are for OIDC.  I think it makes sense for OIDF to =
continue use of OIDC's discovery spec because the UserInfo endpoint is =
well defined and the likelihood of a client mis-informed about the =
resource endpoint is not there.  IMO This does not apply to the =
broader OAuth community.

    Item 2:  It may be appropriate to have a separate =
configuration registry specification, but I think we should hold off =
until we have a complete solution and then make the decision what drafts =
should exist and how many pieces.  A big concern is the perceived =
complexity of multiple solutions and multiple drafts.

    As to John Bradley=E2=80=99=
s comments:

    Re: =
Discovery is the wrong place to mitigate threats. 
    I=E2=80=99m confused by this.  Our mandate was to solve =
a security threat by having a discovery specification to prevent clients =
being mis-lead about endpoints (of which resource service is one) in an =
oauth protected exchange.  Maybe what you mean is we should not use =
.well-known of any kind and we should just create a =E2=80=9C/Config=E2=80=
=9D endpoint to OAuth?

    Re: Your proposal for MITM mitigation
    You =
propose that instead the resource endpoint check should be in the oauth =
protocol itself.  The difference is that validation is transferred =
back to the client to get it right. As well, without the client =
informing the AS, I can=E2=80=99t see a way for the AS to know what =
endpoint the client is using.  The webfinger approach does this =
once and only requires that the host name be checked in many =
cases.

    As a =
principle, the members have discussed many times that the AS service =
should do validation when possible =E2=80=94 this was particularly true =
at the Germany meeting when this came up. This is why I prefer the =
client tell the service provider what it intends to do and the service =
provider can fail that request immediately if necessary. We don=E2=80=99t =
have to depend on the developer getting the spec correct to fail the =
correct way.

    I =
worry that adding more parameters to the authz and token protocol flows =
increases complexity and attack surface. It also means per authorization =
validation has to take place vs. a one-time validation at config time. =
 Placing it in the configuration lookup phase (whether via web =
finger or just a special OAuth endpoint) seems more appropriate and far =
less complex - as the request itself is simple and has only one =
parameter. Here we are not considered about legitimacy of the client. =
we=E2=80=99re just concerned with the issue "has the client been =
correctly informed?=E2=80=9D

    That said, it may be that when we =
consider all the use cases, some combination of AS protocol and =
discovery may be both needed. I=E2=80=99m not ready to make conclusions =
about this.  The current oauth-discovery spec seems to put future =
generic clients at risk and that is my primary concern.

    Best Regards,

    




    

    

    On Mar 13, 2016, at 10:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

    Thanks for posting this, Phil.  It provides a concrete =
example of a way that protected resource discovery could be added to =
authorization server metadata discovery, and as such, should provide =
useful input for working group discussions on this topic.  It=E2=80=99=
s always great when someone takes the time to write an actual draft that =
can be examined and implemented, and I appreciate you doing that.
     
    The content of your draft =
points out that there appears to be complete agreement on what the =
authorization server metadata format should be, which is great!  =
I=E2=80=99ll note that Section 3 of draft-hunt-oauth-bound-config-00 =
titled =E2=80=9CAuthorization Server Metadata=E2=80=9D is an exact copy =
of Section 2 of draft-ietf-oauth-discovery-01 (with the same title), =
modulo applying a correction suggested by the working group.  To me =
this suggests that the authorization server metadata definitions in =
draft-ietf-oauth-discovery (which is now the whole normative content of =
the draft) are clearly ready for standardization, since even your =
alternative proposal includes them verbatim.
     
    Reading your draft, the =
problem I have with it is that you are returning the AS metadata only as =
a WebFinger response, rather than as an https-protected resource =
published by the authorization server.  The choice to only return =
this via WebFinger makes your draft incompatible with most deployed =
implementations of OAuth metadata, including the 22 implementations =
using it listed athttp://openid.net/certification/ (see the =E2=80=9COP =
Config=E2=80=9D column in the table) and OAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CADAL=E2=
=80=9D library, which uses the metadata path for client =
configuration.  Without having ASs provide the metadata as an =
https-protected resource, implementations such as ADAL can=E2=80=99t use =
it for client configuration as the currently do.
     
    Therefore, I =
would request that you make these minor revisions to your draft and =
republish, so as to provide a unified way forward that is compatible =
with all known existing OAuth Discovery deployments:
    1.       Modify your section 2 =E2=80=9CAuthorization =
Server WebFinger Discovery=E2=80=9D to have the WebFinger request return =
the issuer identifier for the AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=
=80=9D value, rather than returning the metadata values by value as the =
=E2=80=9Cproperties=E2=80=9D value.
    2.       Reference the metadata definitions from =
Section 2 of draft-ietf-oauth-discovery, rather than duplicating them in =
your Section 3.
     
    That would have =
the advantage of paring your draft down to only the new things that it =
proposes, enabling them to be more clearly understood and evaluated on =
their own merits.  I look forward to the discussions of ways of =
performing additional kinds of OAuth discovery, and consider your draft =
a valuable input to those discussions.
     
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          Best =
wishes,
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
    Sent: Sunday, March 13, 2016 6:45 =
PM
    To: Phil Hunt <phil.hunt@oracle.com>
    Cc: oauth=
 <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    As I have told Phil off list.  
     
    Discovery is the wrong place to try and =
provide security against man in the middle attacks on the RS.
     
    This requires the client to know what the =
RS URI is before retrieving the information on the AS Configuration.
     
    The proposal Mike and I have been working =
on requires the client to have a notion of what API it is looking for =
and retrieve the .well-known file for that API from the issuer.   =
That allows a protocol like Connect to register its own config file that =
can point to the RS.   
     
    If the API specific well known is not available the =
client can try the default oauth-server one.
     
    That then allows us to deal with =
restricting where AT are presented as part of the protocol rather then =
dragging discovery in as a requirement.
     
    In my opinion the resource the token is =
targeted to should be separated from the scope and returned as part of =
the meta-data about the AT along with scopes granted and expiry time. =
  We should also have a input parameter for resources so that a =
client can restrict tokens issued to a subset of the ones granted by the =
refresh token.   It would then also be possible to ask a AS for a =
token for a unregistered RS and have the AS produce a JWT access token =
with the resource as an audience if policy allows.
     
    That however was supposed to be dealt =
with as part of the mixed up client set of mitigations.  
    In that the goal was to mitigate the attacks by returning =
meta-data about the tokens, and not to require discovery.
     
    We intend to return =E2=80=9Ciss=E2=80=9D =
and =E2=80=9Ccleint_id=E2=80=9D for the code, and I intend to discuss at =
the F2F returning resource for AT as well.
     
    Those mitigate the attack.  
     
    I will continue to resist mixing up =
discovery of configuration meta-data with mitigation of the attacks.
     
    We return meta-data about the tokens now, =
because AT are opaque to the client, we neglected to include some of the =
information for the client needs to be secure.   We just need to =
add that in to the existing flows.
     
    While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add on, it puts more of a burden on the client needing =
to potentially change how it stores the relationships between AS and RS =
to prevent compromise, I think the solution should be biased towards =
simplicity on the client side.
     
    If we return the resources as part of the existing =
meta data the client checks that against the resource it intends to send =
the token to and if it is not in the list then it can=E2=80=99t send the =
token.  Simple check every time it gets a new AT, no =
optionality.
     
    I am not saying anything new Nat has been advocating =
basically this for some time, and dis submit a draft.   I prefer to =
return the info in the existing format rather than as link headers, =
 but that is the largest difference between what Nat and I are =
saying with respect to resource.
     
    That is the core of my problem with Phil=E2=80=99s =
draft.
     
    I guess we will need to have a long conversation in =
BA.
     
    Regards
    John B.
     
    On =
Mar 13, 2016, at 8:12 PM, Phil Hunt <phil.hunt@oracle.com> =
wrote:
     
    This draft is a =
proposed alternate proposal for draft-ietf-oauth-discovery.  As =
such, it contains the same registry for OAuth Config Metadata as the =
authors believe that both solutions are not required, or depending on WG =
discussion they will be merged. The intent is to provide a simple =
complete draft for consideration.
     
    How it works...
    Given that a client =
has previously discovered an OAuth protected resource, the bound =
configuration method allows a client to return the configuration for an =
oauth authorization server that can issue tokens for the resource URI =
specified by the client.  The AS is not required to be in the same =
domain.  The AS is however required to know if it can issue tokens =
for a resource service (which presumes some agreement exists on tokens =
etc).
     
    The draft does not require that the resource exist =
(e.g. for unconfigured or new user based resources). It only requires =
that the AS service provider agrees it can issue tokens.
     
    =46rom a security perspective, returning =
the OAuth service configuration for a specified resource URI serves to =
confirm the client is in possession of a valid resource URI ensuring the =
client has received a valid set of endpoints for the resource and the =
associated oauth services.
     
    I propose that the WG consider the alternate draft =
carefully as well as other submissions and evaluate the broader =
discovery problem before proceeding with WGLC on OAuth Discovery.
     
    Thanks!
     
    Phil
     
    @independentid
    www.independentid.com
     


    Begin forwarded message:
     
    Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
    Date: March 13, 2016 =
at 3:53:37 PM PDT
    To: "Phil Hunt" =
<phil.hunt@yahoo.com>, =
"Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>
     

    A new version of =
I-D, draft-hunt-oauth-bound-config-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:        &=
nbsp;    draft-hunt-oauth-bound=
-config
    Revision:        <=
span class=3D"Apple-converted-space"> 00
    Title:        &=
nbsp;      OAuth 2.0 Bound =
Configuration Lookup
    Document date:        &=
nbsp; 2016-03-13
    Group:        &=
nbsp;    Individual =
Submission
    Pages:        &=
nbsp;     22
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

    Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


    Abstract:
      This specification defines a mechanism for the =
client of an OAuth 2.0
      protected resource =
service to obtain the configuration details of an
      OAuth 2.0 authorization server that is capable of =
authorizing access
      to a specific resource =
service.  The information includes the OAuth
      2.0 component endpoint location URIs and as well =
as authorization
      server capabilities.




    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.

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


    <=
br =
class=3D"">
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    =

--Apple-Mail=_654ECEB7-990A-4B55-A2A7-5D85D5F87C28--

--Apple-Mail=_021F869E-B27B-4496-97A3-9D09BA36C27B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTQyMzI5MDdaMCMGCSqGSIb3DQEJBDEWBBQ8FgLOOzLldukV77SDPU5b
oOcF3zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQB264NwUKM7zYI9upNaY0VQ1+SpZPH63E/nrWJMU19USfPFlgbHRjcA
3KF1ldSPS79d7xpxbwIIrfqUdPa2U1rjd+RO2YWhtKjJ2QDqDdJxJQwzBZ3OVB+Tgsa4bQ1Bt1zS
Qj5WQ8uWVJQAqLiFfDfTt039aXAJjxbsL0OSa5SqR9VBRtcSEYF05KMWTj7069FHLPx+BJgqoERF
NDTjaeUpiUDlct4eVm+pIPUgqCXZNCzFfBWusapIJX+32U7E3RAorl15TRKyk0reK7BaV5XraEPa
H2YaI3kvoLnyyxJEuGGdVGnnx+5OuXh9YtNPXeCcHjFjj3aur+YnF9Ch9qnEAAAAAAAA
--Apple-Mail=_021F869E-B27B-4496-97A3-9D09BA36C27B--


From nobody Mon Mar 14 16:29:53 2016
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 E1C1312D809 for ; Mon, 14 Mar 2016 16:29:52 -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=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 lwZ8SR4N5PyP for ; Mon, 14 Mar 2016 16:29:40 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 22B3412D648 for ; Mon, 14 Mar 2016 16:29:23 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id l68so3739877wml.1 for ; Mon, 14 Mar 2016 16:29:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VAC0D/RcvHSKURTIG3ILeyy3WxnDETPDsFbiJ/+9DB8=; b=Ww6+mtPHAzv7qEXRoVHUZeznOgFZ0HGj87Sx1R4ekVxmOFNfRLmnYUMrnxIgADtClQ XdnT3UlcQaLXRxh5i0zoH5r7mmkNNmK7LOBuSn0m0/NZbZs/sxjUiWBQQ9pA+jn0P0ql ry4fE+dbxxnDAdTvsg+LuSUl9keSDNw3BpAbc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VAC0D/RcvHSKURTIG3ILeyy3WxnDETPDsFbiJ/+9DB8=; b=HgvyY1I/wJxhTcgWE0EG9WuGTapboPcmI8ZUnZTASh3CsWvQbIFi22+X6FS28WtaVd zwUoj/1mV5sHscicT0P6ao8Eh/rE/9o22W6bM3miEA7/oXEG0rrweScyaZXNwbnecSPs 23iWHF5PYQcmcneV9rxAmkAzJ/f0ekjxnCbeDWvlRme0jmeHK+DyjglbgWd3Tj29sO5j vd53PYDMtXxIvjulMx5SXqF+4Z0fIV1nNizGlWf3aPcyRKPtbdzpXBIjANyaWiz7jJGT dNjGOjCyq1ho51rGBMRdyyP99K2ijlsaXz1j1L4YQkFzDnDvooAzcXBp5EBYECq1u9IO xvBQ==
X-Gm-Message-State: AD7BkJIv0fEfKkYBjnDdW6JZ7WcglnyWWc1ALo+OXKosPoYw1Q9iKf8A+WdeZtg4tRqz7J05
X-Received: by 10.28.172.132 with SMTP id v126mr20679539wme.28.1457998161575;  Mon, 14 Mar 2016 16:29:21 -0700 (PDT)
Received: from [10.125.54.45] ([81.145.221.186]) by smtp.gmail.com with ESMTPSA id gk4sm24368245wjd.7.2016.03.14.16.29.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 16:29:20 -0700 (PDT)
To: Justin Richer , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu>
From: Hans Zandbelt 
Message-ID: <56E7494F.906@pingidentity.com>
Date: Mon, 14 Mar 2016 23:29:19 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Mar 2016 23:29:53 -0000

+1, I've found the very same in OAuth deployments that I was involved 
in; the hard part is to give names and descriptions to these concepts so 
that they cover all use cases and can be applied unambiguously

Hans.

On 3/14/16 10:44 PM, Justin Richer wrote:
> I agree that this is valuable, and not just for PoP. In all honesty,
> it’s not even really required for PoP to function in many cases — it’s
> just an optimization for one particular kind of key distribution
> mechanism in that case.
>
> In the years of deployment experience with OAuth 2, I think we’ve really
> got three different kinds of things that currently get folded into
> “scope” that we might want to try separating out better:
>
>
>   - What things do I want to access? (photos, profile)
>   - What actions do I want to take on these things? (read, write, delete)
>   - How long do I want these tokens to work?
> (offline_access/refresh_token, one time use, next hour, etc)
>
>
> I think the first one is close to the audience/resource parameters that
> have been bandied about a few times, including in the current token
> exchange document. We should be consistent across drafts in that regard.
> The second is more traditional scope-ish. The third has been patched in
> with things like “offline_access” in certain APIs.
>
> Just another vector to think about if we’re going to be adding things
> like “audience” or “resource” or both to the token requests.
>
>   — Justin
>
>
>> On Mar 14, 2016, at 6:26 PM, John Bradley > > wrote:
>>
>> Yes I will work on another proposal for allowing clients to specify
>> what resource they want a token for and providing the meta-data to the
>> client about the resources that a token is valid for.
>>
>> We have part of it in the POP key distribution spec and talked about
>> separating it, as it is used more places than just for assigning keys.
>> I know some AS use different token formats for different RS so are
>> all-ready needing to pass the resource in the request to avoid making
>> a mess of scopes.
>>
>> John B.
>>
>>
>>
>>
>>
>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >> > wrote:
>>>
>>> Inline
>>>
>>> Phil
>>>
>>> On Mar 14, 2016, at 14:13, John Bradley >> > wrote:
>>>
>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>> The other was to mitigate the client mixup attack.  The request was
>>>> to do the latter without requiring the former for clients that don’t
>>>> otherwise need discovery.
>>> There is no mandate for any of this. See
>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
>>>>
>>>> Returning the issuer and client_id from the authorization endpoint
>>>> and the client checking them can be done by the client without
>>>> discovery.
>>>
>>> How does this address the issue of whether the client is talking to
>>> the wrong endpoint?
>>>>
>>>> Any client that has the resource and issuer hard coded probably
>>>> doesn’t need discovery.
>>> We agree
>>>
>>>
>>>> One of the things that a client will need discovery for is to find
>>>> the RS, so requiring the client to know the RS URI before getting
>>>> the AS config seems backwards to me.
>>> How can you make an assumption on order? You seem to be conflating
>>> authentication with authorization by assuming the identity drives
>>> what the resource is.
>>>
>>> There are lots of applications that require user rights but are not
>>> identify centric. For example a document service.
>>>>
>>>> Unless the client tells the AS where it intends to use the token we
>>>> will be leaving a security hole because the bearer tokens will have
>>>> too loose an audience if they have one at all.
>>> This is the biggest risk we have IMHO.
>>>>
>>>> True you are telling the AS (Webfinger service) what the RS is but
>>>> that is not at a place that is useful in the token production process.
>>>
>>> This has nothing to do with token production.
>>>
>>> What we want to ensure is whether an honest client is correctly
>>> configured and has not been mislead - eg by a phishing page.
>>>>
>>>> I also think there are use cases where the AS doesn’t know all the
>>>> possible RS.   That is not something that a out of band check can
>>>> address.
>>>
>>> May be. Lets identify them.
>>>
>>>> There are also cases where a token might be good at multiple RS
>>>> endpoints intentionally.
>>>
>>>>  In your solution the client would need to make a discovery request
>>>> for each endpoint.
>>> Sure. Otherwise how would it know if there is one AS or a pool of AS
>>> servers assigned to each instance?
>>>> Those requests lack the context of who the client and resource owner
>>>> are.  I think that will be a problem in some use cases.
>>>
>>> Not sure I agree. This is about discovering a valid set of endpoints.
>>> For mitm, we mainly want to check the hostname is correct. If a
>>> client chooses evil.com  the cert can be valid and
>>> TLS will pass. How does it otherwise know it is supposed to talk to
>>> res.example.com ?
>>>>
>>>> If this is added to the token endpoint it would be checked when code
>>>> or refresh are exchanged, not every time the token is used.
>>> Your proposal requires rhe client to check. I am not clear how the AS
>>> can know the exact uri. It is far easier to validate than to lookup
>>> since as you say the client may be authorized to use multiple ASs.
>>>> With a out of band check the client would never know if a RS was
>>>> removed/revoked.
>>>
>>> Not sure that is in scope.
>>>
>>> None of the current proposals address this issue.
>>>>
>>>> I don’t see checking when refreshing a token as something that is a
>>>> huge burden.
>>>
>>> Still its a lot more than once.
>>>
>>> Why don't you draft another alternative?
>>>>
>>>> If the server wants to do the check on it’s side then we could
>>>> require the client to send the RS URI in the token request. that way
>>>> you really know the client is not going to get a token for the wrong
>>>> RS endpoint.
>>>> If you check out of band in discovery you really have no idea if the
>>>> client is checking.
>>>
>>> In the new webfinger draft, the client isn't checking. The service
>>> provider simply does not disclose oauth information to misconfigured
>>> clients.
>>>>
>>>> John B.
>>>>
>>>>
>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >>>> > wrote:
>>>>>
>>>>> Thanks to Mike and John for their feedback.  I’ll take each in turn:
>>>>>
>>>>> Mike,
>>>>>
>>>>> Regarding your suggested amendments
>>>>>
>>>>> Item 1: Returning the config URL would create two problems. One,it
>>>>> makes bound discovery a two-step process - that adds complexity.
>>>>>  It seems far simpler to mandate TLS (which I think it already does
>>>>> in the security considerations).
>>>>>
>>>>> The two-step process allows the current discovery process to
>>>>> continue. I disagree with this. This is why I put forward an
>>>>> “alternate" draft that is almost the same but simply adds the check
>>>>> before returning the configuration data.  I worry that  developers
>>>>> would have no incentive to do the two-step approach. They would
>>>>> just start at step 2 which in turn puts AS’s at risk of exposing
>>>>> tokens because it works. This makes OAuth promiscuous.
>>>>>
>>>>> Regarding existing implementations. Most of those implementations
>>>>> are for OIDC.  I think it makes sense for OIDF to continue use of
>>>>> OIDC's discovery spec because the UserInfo endpoint is well defined
>>>>> and the likelihood of a client mis-informed about the resource
>>>>> endpoint is not there.  IMO This does not apply to the broader
>>>>> OAuth community.
>>>>>
>>>>> Item 2:  It may be appropriate to have a separate configuration
>>>>> registry specification, but I think we should hold off until we
>>>>> have a complete solution and then make the decision what drafts
>>>>> should exist and how many pieces.  A big concern is the perceived
>>>>> complexity of multiple solutions and multiple drafts.
>>>>>
>>>>> As to John Bradley’s comments:
>>>>>
>>>>> Re: Discovery is the wrong place to mitigate threats.
>>>>> I’m confused by this.  Our mandate was to solve a security threat
>>>>> by having a discovery specification to prevent clients being
>>>>> mis-lead about endpoints (of which resource service is one) in an
>>>>> oauth protected exchange.  Maybe what you mean is we should not use
>>>>> .well-known of any kind and we should just create a “/Config”
>>>>> endpoint to OAuth?
>>>>>
>>>>> Re: Your proposal for MITM mitigation
>>>>> You propose that instead the resource endpoint check should be in
>>>>> the oauth protocol itself.  The difference is that validation is
>>>>> transferred back to the client to get it right. As well, without
>>>>> the client informing the AS, I can’t see a way for the AS to know
>>>>> what endpoint the client is using.  The webfinger approach does
>>>>> this once and only requires that the host name be checked in many
>>>>> cases.
>>>>>
>>>>> As a principle, the members have discussed many times that the AS
>>>>> service should do validation when possible — this was particularly
>>>>> true at the Germany meeting when this came up. This is why I prefer
>>>>> the client tell the service provider what it intends to do and the
>>>>> service provider can fail that request immediately if necessary. We
>>>>> don’t have to depend on the developer getting the spec correct to
>>>>> fail the correct way.
>>>>>
>>>>> I worry that adding more parameters to the authz and token protocol
>>>>> flows increases complexity and attack surface. It also means per
>>>>> authorization validation has to take place vs. a one-time
>>>>> validation at config time.  Placing it in the configuration lookup
>>>>> phase (whether via web finger or just a special OAuth endpoint)
>>>>> seems more appropriate and far less complex - as the request itself
>>>>> is simple and has only one parameter. Here we are not considered
>>>>> about legitimacy of the client. we’re just concerned with the issue
>>>>> "has the client been correctly informed?”
>>>>>
>>>>> That said, it may be that when we consider all the use cases, some
>>>>> combination of AS protocol and discovery may be both needed. I’m
>>>>> not ready to make conclusions about this.  The current
>>>>> oauth-discovery spec seems to put future generic clients at risk
>>>>> and that is my primary concern.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> Thanks for posting this, Phil.  It provides a concrete example of
>>>>>> a way that protected resource discovery could be added to
>>>>>> authorization server metadata discovery, and as such, should
>>>>>> provide useful input for working group discussions on this topic.
>>>>>> It’s always great when someone takes the time to write an actual
>>>>>> draft that can be examined and implemented, and I appreciate you
>>>>>> doing that.
>>>>>> The content of your draft points out that there appears to be
>>>>>> complete agreement on what the authorization server metadata
>>>>>> format should be, which is great!  I’ll note that Section 3 of
>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server
>>>>>> Metadata” is an exact copy of Section 2 of
>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>>>>>> applying a correction suggested by the working group.  To me this
>>>>>> suggests that the authorization server metadata definitions in
>>>>>> draft-ietf-oauth-discovery (which is now the whole normative
>>>>>> content of the draft) are clearly ready for standardization, since
>>>>>> even your alternative proposal includes them verbatim.
>>>>>> Reading your draft, the problem I have with it is that you are
>>>>>> returning the AS metadata only as a WebFinger response, rather
>>>>>> than as an https-protected resource published by the authorization
>>>>>> server.  The choice to only return this via WebFinger makes your
>>>>>> draft incompatible with most deployed implementations of OAuth
>>>>>> metadata, including the 22 implementations using it listed
>>>>>> athttp://openid.net/certification/(see the “OP Config” column in
>>>>>> the table) andOAuth 2.0 libraries such as Microsoft’s “ADAL”
>>>>>> library, which uses the metadata path for client configuration.
>>>>>> Without having ASs provide the metadata as an https-protected
>>>>>> resource, implementations such as ADAL can’t use it for client
>>>>>> configuration as the currently do.
>>>>>> Therefore, I would request that you make these minor revisions to
>>>>>> your draft and republish, so as to provide a unified way forward
>>>>>> that is compatible with all known existing OAuth Discovery
>>>>>> deployments:
>>>>>> 1.Modify your section 2 “Authorization Server WebFinger Discovery”
>>>>>> to have the WebFinger request return the issuer identifier for the
>>>>>> AS as the “WebFinger “rel” value, rather than returning the
>>>>>> metadata values by value as the “properties” value.
>>>>>> 2.Reference the metadata definitions from Section 2 of
>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in your
>>>>>> Section 3.
>>>>>> That would have the advantage of paring your draft down to only
>>>>>> the new things that it proposes, enabling them to be more clearly
>>>>>> understood and evaluated on their own merits.  I look forward to
>>>>>> the discussions of ways of performing additional kinds of OAuth
>>>>>> discovery, and consider your draft a valuable input to those
>>>>>> discussions.
>>>>>>                                                           Best wishes,
>>>>>>                                                           -- Mike
>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*John Bradley
>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>> *To:*Phil Hunt >
>>>>>> *Cc:*oauth >
>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>> As I have told Phil off list.
>>>>>> Discovery is the wrong place to try and provide security against
>>>>>> man in the middle attacks on the RS.
>>>>>> This requires the client to know what the RS URI is before
>>>>>> retrieving the information on the AS Configuration.
>>>>>> The proposal Mike and I have been working on requires the client
>>>>>> to have a notion of what API it is looking for and retrieve the
>>>>>> .well-known file for that API from the issuer.   That allows a
>>>>>> protocol like Connect to register its own config file that can
>>>>>> point to the RS.
>>>>>> If the API specific well known is not available the client can try
>>>>>> the default oauth-server one.
>>>>>> That then allows us to deal with restricting where AT are
>>>>>> presented as part of the protocol rather then dragging discovery
>>>>>> in as a requirement.
>>>>>> In my opinion the resource the token is targeted to should be
>>>>>> separated from the scope and returned as part of the meta-data
>>>>>> about the AT along with scopes granted and expiry time.   We
>>>>>> should also have a input parameter for resources so that a client
>>>>>> can restrict tokens issued to a subset of the ones granted by the
>>>>>> refresh token.   It would then also be possible to ask a AS for a
>>>>>> token for a unregistered RS and have the AS produce a JWT access
>>>>>> token with the resource as an audience if policy allows.
>>>>>> That however was supposed to be dealt with as part of the mixed up
>>>>>> client set of mitigations.
>>>>>> In that the goal was to mitigate the attacks by returning
>>>>>> meta-data about the tokens, and not to require discovery.
>>>>>> We intend to return “iss” and “cleint_id” for the code, and I
>>>>>> intend to discuss at the F2F returning resource for AT as well.
>>>>>> Those mitigate the attack.
>>>>>> I will continue to resist mixing up discovery of configuration
>>>>>> meta-data with mitigation of the attacks.
>>>>>> We return meta-data about the tokens now, because AT are opaque to
>>>>>> the client, we neglected to include some of the information for
>>>>>> the client needs to be secure.   We just need to add that in to
>>>>>> the existing flows.
>>>>>> While Phil’s proposal is easier for the AS to implement as an add
>>>>>> on, it puts more of a burden on the client needing to potentially
>>>>>> change how it stores the relationships between AS and RS to
>>>>>> prevent compromise, I think the solution should be biased towards
>>>>>> simplicity on the client side.
>>>>>> If we return the resources as part of the existing meta data the
>>>>>> client checks that against the resource it intends to send the
>>>>>> token to and if it is not in the list then it can’t send the
>>>>>> token.  Simple check every time it gets a new AT, no optionality.
>>>>>> I am not saying anything new Nat has been advocating basically
>>>>>> this for some time, and dis submit a draft.   I prefer to return
>>>>>> the info in the existing format rather than as link headers,  but
>>>>>> that is the largest difference between what Nat and I are saying
>>>>>> with respect to resource.
>>>>>> That is the core of my problem with Phil’s draft.
>>>>>> I guess we will need to have a long conversation in BA.
>>>>>> Regards
>>>>>> John B.
>>>>>>
>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt >>>>>     > wrote:
>>>>>>     This draft is a proposed alternate proposal for
>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same
>>>>>>     registry for OAuth Config Metadata as the authors believe that
>>>>>>     both solutions are not required, or depending on WG discussion
>>>>>>     they will be merged. The intent is to provide a simple
>>>>>>     complete draft for consideration.
>>>>>>     How it works...
>>>>>>     Given that a client has previously discovered an OAuth
>>>>>>     protected resource, the bound configuration method allows a
>>>>>>     client to return the configuration for an oauth authorization
>>>>>>     server that can issue tokens for the resource URI specified by
>>>>>>     the client.  The AS is not required to be in the same domain.
>>>>>>      The AS is however required to know if it can issue tokens for
>>>>>>     a resource service (which presumes some agreement exists on
>>>>>>     tokens etc).
>>>>>>     The draft does not require that the resource exist (e.g. for
>>>>>>     unconfigured or new user based resources). It only requires
>>>>>>     that the AS service provider agrees it can issue tokens.
>>>>>>     From a security perspective, returning the OAuth service
>>>>>>     configuration for a specified resource URI serves to confirm
>>>>>>     the client is in possession of a valid resource URI ensuring
>>>>>>     the client has received a valid set of endpoints for the
>>>>>>     resource and the associated oauth services.
>>>>>>     I propose that the WG consider the alternate draft carefully
>>>>>>     as well as other submissions and evaluate the broader
>>>>>>     discovery problem before proceeding with WGLC on OAuth Discovery.
>>>>>>     Thanks!
>>>>>>     Phil
>>>>>>     @independentid
>>>>>>     www.independentid.com 
>>>>>>     phil.hunt@oracle.com 
>>>>>>
>>>>>>
>>>>>>         Begin forwarded message:
>>>>>>         *From:*internet-drafts@ietf.org
>>>>>>         
>>>>>>         *Subject: New Version Notification for
>>>>>>         draft-hunt-oauth-bound-config-00.txt*
>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>         *To:*"Phil Hunt" >>>>>         >, "Anthony Nadalin"
>>>>>>         >,
>>>>>>         "Tony Nadalin" >>>>>         >
>>>>>>
>>>>>>
>>>>>>         A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>>>>>>         has been successfully submitted by Phil Hunt and posted to the
>>>>>>         IETF repository.
>>>>>>
>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>         Revision:00
>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>         Document date:2016-03-13
>>>>>>         Group:Individual Submission
>>>>>>         Pages:22
>>>>>>         URL:
>>>>>>         https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>         Status:
>>>>>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>         Htmlized:
>>>>>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>
>>>>>>
>>>>>>         Abstract:
>>>>>>           This specification defines a mechanism for the client of
>>>>>>         an OAuth 2.0
>>>>>>           protected resource service to obtain the configuration
>>>>>>         details of an
>>>>>>           OAuth 2.0 authorization server that is capable of
>>>>>>         authorizing access
>>>>>>           to a specific resource service.  The information
>>>>>>         includes the OAuth
>>>>>>           2.0 component endpoint location URIs and as well as
>>>>>>         authorization
>>>>>>           server capabilities.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         Please note that it may take a couple of minutes from the
>>>>>>         time of submission
>>>>>>         until the htmlized version and diff are available
>>>>>>         attools.ietf.org .
>>>>>>
>>>>>>         The IETF Secretariat
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     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
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Tue Mar 15 05:38:13 2016
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 ACED012D9F2 for ; Tue, 15 Mar 2016 05:38:10 -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, FREEMAIL_FROM=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 (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 0BwK4XxwjSvK for ; Tue, 15 Mar 2016 05:38:09 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 7532012D9F3 for ; Tue, 15 Mar 2016 05:38:02 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id l68so24454038wml.1 for ; Tue, 15 Mar 2016 05:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=KGP3piS7fKM2GeE4Q1DcHb43iepgx5lq5Fkle0rkXV8=; b=CG0snBxlQLSOpPL/BaOYtQL9rk+lvuEpSB85GSaYPuJlBjtJdg+1mal6lJzTLLtwDR 4P92apdfno/x0ggOZEaOwHiIgGcowD0a4qQvNZCoS7s6DJ+Y6wNmfyEb2P/4OLBD/9YD Gyox5Y8v7lfnoEl6z4ijytN3xln2QPU9PWa1+MAAXOqmUHXDC/1wfFB9Vzz22W9Go5gC UVF5U0wnQhZVJhIf8mRMPwjEA9GgnmafZgyewk9s9UBNKPi2wEBFqPIkMjJaL1A02jzF s+48cwnE959u0ehHJi53JDazUwcJcdXr1Am+rl57iR42hsIADUnwjYM/SUhFBBAVom9Z cfZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KGP3piS7fKM2GeE4Q1DcHb43iepgx5lq5Fkle0rkXV8=; b=JYIUiZQYA2CbOPDMRrUPeH8L6z14wrFX/dWsb6NuR705KoDZ601k+Za9lDfMMv2kd5 60235uQlACU3uS5zbiiTe75hqaeerB1Rv5yzPV8am5g65wzrAh8Zxk+niaqVjoe076io eMIxNSPdY9SpFHOFkN/l4nu05tE0K1y17Hj28h967jN3fcrBone3cupJ+9bCt/0aTTuC cLH8C6PPaN4Iy6i+pyAoCFXUg23l4rbeT5vdwaQRYxJZ7x8Noj25/1kI6z1DZuEkRROJ PKQuUcK5zvQDe8tG/EuxBN9lKXv/ruqJEAxrpj8hBWWQkIkGvfwiZEInQ9jry0X8TilO +gqg==
X-Gm-Message-State: AD7BkJJS4ONPBTg6AuAxhVaoDe1FowziMLzZPdYePNbFSh7eJM5M0281jpXgTI6r9/gN8w==
X-Received: by 10.194.189.143 with SMTP id gi15mr29414049wjc.54.1458045481003;  Tue, 15 Mar 2016 05:38:01 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id d2sm26848269wjf.28.2016.03.15.05.37.59 for  (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 05:37:59 -0700 (PDT)
To: oauth@ietf.org
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com>
From: Sergey Beryozkin 
Message-ID: <56E80227.7080709@gmail.com>
Date: Tue, 15 Mar 2016 12:37:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 12:38:10 -0000

Hi All

I've alway been thinking of Client Credentials as being the simplest 
flow but now that I'm looking at implementing it myself to be used in 
the real productions, I'm realizing that there's something I do not 
understand about it:

Do the clients using Client Credentials flow need to be 
OAuth2-registered, even when such clients are already known to the 
authentication system ?

For example, there might be some LDAP/etc entry for Alice (name, 
password). Now a client is using a client credentials flow to get an 
access token:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

I hope that in this case no explicit registration (the one typically 
required in redirection based flows) is needed, the client (Alice) has 
been 'implicitly' registered (as far as the notion of OAuth2 client is 
concerned) in LDAP/etc.

If the explicit registration with OAuth2 AS was still required in the 
case above then it would lead to a fairly massive duplication of effort 
(Alice is registered in Ldap, then also with OAuth2 AS), etc

Can someone clarify it please ?

Thanks, Sergey










From nobody Tue Mar 15 05:53:30 2016
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 151EA12DA0B for ; Tue, 15 Mar 2016 05:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2skBppBC5dgR for ; Tue, 15 Mar 2016 05:53:26 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 6CE4912DA06 for ; Tue, 15 Mar 2016 05:53:19 -0700 (PDT)
X-AuditID: 1209190c-ec3ff7000000022a-53-56e805bedbd7
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id DA.C0.00554.EB508E65; Tue, 15 Mar 2016 08:53:18 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u2FCrH3Z006093 for ; Tue, 15 Mar 2016 08:53:18 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2FCrGkj028812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 15 Mar 2016 08:53:17 -0400
To: oauth@ietf.org
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com>
From: Justin Richer 
Message-ID: <56E805B8.5000305@mit.edu>
Date: Tue, 15 Mar 2016 08:53:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E80227.7080709@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixG6nrruP9UWYwbtD3BYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqzdN1kLlopXbP+xk62B8YJQFyMHh4SAicSjj/ZdjFwcQgJt TBJd+5czQjjHGCX+HpzPAuF8YJJoWXSZqYuRk0NYwEPiysa3YLaIgJDE8519TBBFl1kk9k/Y wAaSYBNQlZi+pgWsiFdATWLaz79gcRageOOu1YwgtqhAjMTxd+cYIWoEJU7OfMICYnMKaEr8 nfcBrJdZwFbiztzdzBC2vMT2t3OYJzDyz0LSMgtJ2SwkZQsYmVcxyqbkVunmJmbmFKcm6xYn J+blpRbpGurlZpbopaaUbmIEhR+nJM8OxjNvvA4xCnAwKvHwzpB6HibEmlhWXJl7iFGSg0lJ lFftIVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG8Vy4swId6UxMqq1KJ8mJQ0B4uSOG/h/tNh QgLpiSWp2ampBalFMFkZDg4lCd7TII2CRanpqRVpmTklCGkmDk6Q4TxAw4+DDS8uSMwtzkyH yJ9iVJQS5z3JDJQQAElklObB9YLSQ8Lbw6avGMWBXhHmnQfSzgNMLXDdr4AGMwEN7gl/BjK4 JBEhJdXAmMv4YHWel4V+gk1Lyf6wVVLvFLVXc3q6/jlc+aHrkiTnv5UnmySN1jzRZk36npHm vE71XMKq4B6F70eNluxlN9SNCnt/9fMj1VaZ0LsaZ/wOPE+4aMPXGxb7eVpltTz3tOrlJtFh qTfuKkT+DT1ruMz9kIHAvb4ynljFCws/yuyb+37zq837lFiKMxINtZiLihMBMXk4QuoCAAA=
Archived-At: 
Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 12:53:29 -0000

Is Alice the client here (the piece of software), or is Alice the 
resource owner? If Alice is the resource owner, then you should 
absolutely not be using the client credentials flow like this.

The client credentials flow is designed for cases where the client is 
acting on its own behalf, not on behalf of any particular user. It's an 
optimization of the canonical authorization code flow, where there is no 
interaction with the resource owner because there is no resource owner 
as a separate entity. It's most useful for backend systems that would 
have traditionally used a developer key to get access to bulk data. If 
you're using it for single-user access, you're doing it wrong.

Also, you should keep in mind that things that seem "simple" on the 
surface are often simplified at the cost of making specific security 
concessions and assumptions. The authorization code flow is "complex" 
for very good reasons, all of them security focused. You should never 
pick a different OAuth flow just because it looks simpler, you should 
only pick them if you're within the use case that it was designed for, 
and therefor the assumptions of its security patterns match.

We've seen a *ton* of problems with people picking the implicit flow in 
the real world and using it with clients other than in-browser 
applications that it was designed for. If you're not in that specific 
space, you're taking on huge risks.

  -- Justin

On 3/15/2016 8:37 AM, Sergey Beryozkin wrote:
> Hi All
>
> I've alway been thinking of Client Credentials as being the simplest 
> flow but now that I'm looking at implementing it myself to be used in 
> the real productions, I'm realizing that there's something I do not 
> understand about it:
>
> Do the clients using Client Credentials flow need to be 
> OAuth2-registered, even when such clients are already known to the 
> authentication system ?
>
> For example, there might be some LDAP/etc entry for Alice (name, 
> password). Now a client is using a client credentials flow to get an 
> access token:
>
> POST /token HTTP/1.1
> Host: server.example.com
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
> Content-Type: application/x-www-form-urlencoded
>
> grant_type=client_credentials
>
> I hope that in this case no explicit registration (the one typically 
> required in redirection based flows) is needed, the client (Alice) has 
> been 'implicitly' registered (as far as the notion of OAuth2 client is 
> concerned) in LDAP/etc.
>
> If the explicit registration with OAuth2 AS was still required in the 
> case above then it would lead to a fairly massive duplication of 
> effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>
> Can someone clarify it please ?
>
> Thanks, Sergey
>
>
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Mar 15 06:01:56 2016
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 5EE2012DA20 for ; Tue, 15 Mar 2016 06:01:54 -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, FREEMAIL_FROM=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 (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 mD2-Ri12wXYU for ; Tue, 15 Mar 2016 06:01:40 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 7220F12D9EE for ; Tue, 15 Mar 2016 06:01:19 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id l124so9924739wmf.1 for ; Tue, 15 Mar 2016 06:01:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=uB2a0jj7DPX67BEVriEwSflUwlifpqgRqK1rtWDmKw4=; b=GlzYgCNcZZpKeV6rBzQRYGHw29I+bGRXHfyjFEFMsbAT3iDDowQ7BJs2cwAChA7mT7 9Pp+sWchmx+5u9g9YTrbNaxe0B9heiuyG70gH0asQe+K2quXWrk9Lly0s6F4EpD8C/1M M+zlkqYeTp/p4YyYakksN2xrLQIC8czaMGTBarORqnMFPl0iJOvFzFC5d1db5xIJL3uB 7xm9ypUi0EPDLPfIGISdsX4rrfLcYuZkZIJbKTaPQZKutcaNk3QeT0QNFK9Y0hJ2bECA SeS910hHMt2q8xw50cpuGUZrIAO9fR03nHceGWhH+zKZOMF3rDAJzpjeal6pFuVokglo BdQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uB2a0jj7DPX67BEVriEwSflUwlifpqgRqK1rtWDmKw4=; b=J9pXd0xCtpUO+3bkfMRfj7hyku6d72rQXcvqv+YjIewFxUGXioG/fffpUp1X3If1Go rEisgyxEn7iCXZuAJihhoqcBHTwqHyd3ALYhM3E6rboKIe65U13MK5hiufLOMj/oCbrh OisX67Xi7Gj82qe0pkkGRZU3besxn0np14WF7/pjqzleR8wtBFyVeyU7xpt+Wxi8FGf/ /qLkIgMSr0/ePMh/TcDlG5+yNMP9HOi+DwoQUSOvBjJjzDQ8O7EfH7uYCRauJnukGYsM ek2Qey/6gi3RCoku3UE6f7u8XnFF24KXjYsbW/XhaJP9equR0iKTc+t2gGPo8OI3TluQ pdbw==
X-Gm-Message-State: AD7BkJKTHzW7pJ1D6T+tHGv/J3cM3IHS4LPhErMMf7KgD9hp774msKn+7/4QKDdF5kblLQ==
X-Received: by 10.194.91.205 with SMTP id cg13mr29571275wjb.166.1458046877718;  Tue, 15 Mar 2016 06:01:17 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id gb9sm26997201wjb.26.2016.03.15.06.01.16 for  (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 06:01:16 -0700 (PDT)
To: oauth@ietf.org
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com>
From: Sergey Beryozkin 
Message-ID: <56E8079C.3010402@gmail.com>
Date: Tue, 15 Mar 2016 13:01:16 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E80227.7080709@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:01:55 -0000

Hi

After following the recent thread on multiple authorization servers, but 
also reading some other related threads, I have a question related to 
when the token introspection can be avoided.

My understanding has been that given that access tokens are opaque the 
RS does not know anything about its content, hence that was the purpose 
of the token introspection spec: provide an interoperable way for RS to 
submit a token to AS and get the token data for RS to make a final 
decision about this token.

I think if the access tokens are really opaque, i.e, they are sequences 
RS can not look into, then having the introspection option is the only 
way to check what the token is really about.

But the recent replies with respect to using JWS or JWE tokens have 
confused me.

1. AccessToken as JWS JWT Token:

RS can easily look into it, but Justin mentioned that in one case they 
first validate this JWS token and then forward it for some further 
introspection. Why start introspecting if the token has been validated 
and its content is visible ?
Perhaps because some token data which are sensitive are only visible in 
the introspection response ? If yes then why use a self-contained token 
if some more external data are associated with it.

2. AccessToken as JWE JWT Token: this option was mentioned a couple of 
times recently, Jonh B. suggested in the other thread the introspection 
may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to 
share the decrypting key with AS.

So, is introspection needed only for the completely opaque tokens or it 
is also needed for JWS and JWE tokens. I'd say it might be reasonable to 
skip it in case of JWS, depending on the specific requirements (as the 
expiry, issuer, will be typically set in JWS JWT), while with JWE I can 
not see how RS can avoid introspecting unless it shares the 
secret/private key with AS.


Thanks, Sergey






From nobody Tue Mar 15 06:05:33 2016
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 575BE12DA26 for ; Tue, 15 Mar 2016 06:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 rAigULwUsK8o for ; Tue, 15 Mar 2016 06:05:23 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 627D312D509 for ; Tue, 15 Mar 2016 06:05:20 -0700 (PDT)
Received: by mail-qg0-x234.google.com with SMTP id y89so13267344qge.2 for ; Tue, 15 Mar 2016 06:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=srwixVxqYB1ElmhtzlaVRwG5/ouvY7n0iZo3Ej86yFM=; b=zpjLH9oPDYEz8ONVrI89oimzskVMkAkExeNdzcpoGdkGWVsvIYsyCECpUxrdv5sMxq Bw3pXfJTqd7Fva8/8Pqkte8sIQEapGYTPL+0ciXXWRTDaYDgF3BAfSOyABbrYHnBBqfZ baqxMqK3B+A3C0LhDnC5YNu7I7gDJ0ihgCCIckqMO6zOce5yF/jm+Gjf9NK5zaSEFKGv GtEVVTu2ooJiZJzd4hNxC9BxfYEc6ZLmDHORamEp1wA29Ohb85SYMUVYOQuolyyJ8zUi QxKJl4VvkvsQPSWVIeBgjMFse9E3QF3FK4U0ICjRecsTg4aNL+IicUopvxLfJeLYIIU2 PopA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=srwixVxqYB1ElmhtzlaVRwG5/ouvY7n0iZo3Ej86yFM=; b=U+MIJrO5jMRRprTRNvM40pPIZ51UufVpACLRziuG9UFdjxHOnVXFwyk01G9HjZQSfg 8OiOrIiZNUyrow8KsTxFeY7NhMOkAR3D6mua/DUC3Rw6ZIC1s6KxJ/0qJZgnzGYfaS52 /FdHH8l8wGAxwuBC/CKvH9HSCceCs2qMdZ6+ytIhHZfpH1kNKI2Xj+AaXhhK0qP9VFz+ 5auBG6tTy/a6EOps77If1OszTqzHsNKojQ4gEIrpDmn+C6fqwbjJg7+Ry5nuTBt0L31I zU1IPyvErQnzeYPokrLXy+OEgIG9O+3nitCOLRkq1C+sFq11W+qS/CnyhpFHeIh2YVkX Wzuw==
X-Gm-Message-State: AD7BkJLCvZ3F3ZcCwM7t24LzJwkOFByil7IIEs+cVI5iCp6jyg6tu+JB8/3k48JplSlB/g==
X-Received: by 10.140.107.74 with SMTP id g68mr37511096qgf.82.1458047119365; Tue, 15 Mar 2016 06:05:19 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.44.172]) by smtp.gmail.com with ESMTPSA id l67sm12639446qgl.47.2016.03.15.06.05.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 06:05:18 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_A856C570-91E4-4834-8FD5-22DB11871ECA"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56E80227.7080709@gmail.com>
Date: Tue, 15 Mar 2016 10:05:07 -0300
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:05:32 -0000

--Apple-Mail=_A856C570-91E4-4834-8FD5-22DB11871ECA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I think you may be confusing Client credentials flow with resource owner =
credentials flow.

If there is a resource owner in the flow use code.   The resource owner =
credentials flow is a bad idea and only put in for backwards =
compatibility.

John B.

> On Mar 15, 2016, at 9:37 AM, Sergey Beryozkin  =
wrote:
>=20
> Hi All
>=20
> I've alway been thinking of Client Credentials as being the simplest =
flow but now that I'm looking at implementing it myself to be used in =
the real productions, I'm realizing that there's something I do not =
understand about it:
>=20
> Do the clients using Client Credentials flow need to be =
OAuth2-registered, even when such clients are already known to the =
authentication system ?
>=20
> For example, there might be some LDAP/etc entry for Alice (name, =
password). Now a client is using a client credentials flow to get an =
access token:
>=20
> POST /token HTTP/1.1
> Host: server.example.com
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
> Content-Type: application/x-www-form-urlencoded
>=20
> grant_type=3Dclient_credentials
>=20
> I hope that in this case no explicit registration (the one typically =
required in redirection based flows) is needed, the client (Alice) has =
been 'implicitly' registered (as far as the notion of OAuth2 client is =
concerned) in LDAP/etc.
>=20
> If the explicit registration with OAuth2 AS was still required in the =
case above then it would lead to a fairly massive duplication of effort =
(Alice is registered in Ldap, then also with OAuth2 AS), etc
>=20
> Can someone clarify it please ?
>=20
> Thanks, Sergey
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_A856C570-91E4-4834-8FD5-22DB11871ECA
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxMzA1MDhaMCMGCSqGSIb3DQEJBDEWBBTXUveoFUDyTmfbWG8ev7LD
CT9xzDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAI/66hN8NipJlf8BWfzwUaAo6fqbb36CHaCA240eUL7O81fVFVHZbq
BU2ydFI4ROXXTG+gjabCRWEZEqfxEeuRgjxoXhTyaaB17OvkiBnNOyy9EAm34niZDouyC4NPB486
8UXlZUsOgIJapbnrq008TI9kw9bFeaUoFF9AuKOUDDTcqSFjlqtZfSN/0fghfThmj4kXeY8iJiH9
WZyVt0qKCV79gR5dhQA+uqNDuc9KtMdoRYU6MeMze/WxrMZMD+k+3kcotzhQHMZD0jbqoM4/Gi3X
Nf4/TYteyr00Uti0KYfyR9Hn/9FtrSKRHt0iQnopNNonvyewj3ApAp47ay9WAAAAAAAA
--Apple-Mail=_A856C570-91E4-4834-8FD5-22DB11871ECA--


From nobody Tue Mar 15 06:11:42 2016
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 24D2D12DA02 for ; Tue, 15 Mar 2016 06:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 WYb-PWXTshop for ; Tue, 15 Mar 2016 06:11:37 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 DEEA412D53C for ; Tue, 15 Mar 2016 06:11:36 -0700 (PDT)
X-AuditID: 1209190d-9ebff70000003214-f7-56e80a07a29d
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 18.72.12820.70A08E65; Tue, 15 Mar 2016 09:11:35 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u2FDBZu8032767; Tue, 15 Mar 2016 09:11:35 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2FDBXQp001675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Mar 2016 09:11:34 -0400
To: Sergey Beryozkin , oauth@ietf.org
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com>
From: Justin Richer 
Message-ID: <56E80A02.20101@mit.edu>
Date: Tue, 15 Mar 2016 09:11:30 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E8079C.3010402@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixCmqrcvO9SLM4Pd9c4uTb1+xWfxbau/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZSy70sVWsEqoYtcb1wbGdXxdjJwcEgImElu2 rWHqYuTiEBJoY5K4c3ctK4SzkVGi+2YPG4Rzm0ni5vVfzCAtwgJuEksO72MEsUUErCVuPJ7O CFH0gUXi7eIuFpAEm4CqxPQ1LUBzOTh4BVQktsxgBwmzAIXvvH7KCmKLCsRIHH93DmwOr4Cg xMmZT8BaOQU0JfbcgLCZBWwl7szdzQxhy0tsfzuHeQIj/ywkLbOQlM1CUraAkXkVo2xKbpVu bmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGcDhK8u5g/HfX6xCjAAejEg/vDKnnYUKsiWXF lbmHGCU5mJREedUeAoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8HJzvAgT4k1JrKxKLcqHSUlz sCiJ88bcPBomJJCeWJKanZpakFoEk5Xh4FCS4D0D0ihYlJqeWpGWmVOCkGbi4AQZzgM0/DjY 8OKCxNzizHSI/ClGRSlx3kSQhABIIqM0D64XlC4S3h42fcUoDvSKMO9DkCoeYKqB634FNJgJ aHBP+DOQwSWJCCmpBsbsNROKVKXSPs2pEp34NP1PtJKRTti3HD7HCuWF87h2B6acaIxcaC1p 9fm5Rt6vK9fiPy5XaXM62vxF8UDs3J/zv+38G7o22Xq3ebf9ryr1Y39+GE/6lvXm4rnE1I1R luflfy8oXrf47KejezlKq4NXpCrd2n9F9dm8O+sFD0Tzx+j2SssUTpylxFKckWioxVxUnAgA 6ZWWUfICAAA=
Archived-At: 
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:11:41 -0000

The access tokens are opaque to the client, not the RS.

  -- Justin

On 3/15/2016 9:01 AM, Sergey Beryozkin wrote:
> Hi
>
> After following the recent thread on multiple authorization servers, 
> but also reading some other related threads, I have a question related 
> to when the token introspection can be avoided.
>
> My understanding has been that given that access tokens are opaque the 
> RS does not know anything about its content, hence that was the 
> purpose of the token introspection spec: provide an interoperable way 
> for RS to submit a token to AS and get the token data for RS to make a 
> final decision about this token.
>
> I think if the access tokens are really opaque, i.e, they are 
> sequences RS can not look into, then having the introspection option 
> is the only way to check what the token is really about.
>
> But the recent replies with respect to using JWS or JWE tokens have 
> confused me.
>
> 1. AccessToken as JWS JWT Token:
>
> RS can easily look into it, but Justin mentioned that in one case they 
> first validate this JWS token and then forward it for some further 
> introspection. Why start introspecting if the token has been validated 
> and its content is visible ?
> Perhaps because some token data which are sensitive are only visible 
> in the introspection response ? If yes then why use a self-contained 
> token if some more external data are associated with it.
>
> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of 
> times recently, Jonh B. suggested in the other thread the 
> introspection may not be needed (sorry if I misread it).
> The question here, how can RS deal with a JWE token, it would need to 
> share the decrypting key with AS.
>
> So, is introspection needed only for the completely opaque tokens or 
> it is also needed for JWS and JWE tokens. I'd say it might be 
> reasonable to skip it in case of JWS, depending on the specific 
> requirements (as the expiry, issuer, will be typically set in JWS 
> JWT), while with JWE I can not see how RS can avoid introspecting 
> unless it shares the secret/private key with AS.
>
>
> Thanks, Sergey
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Mar 15 06:12:26 2016
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 8CA0C12DA1A for ; Tue, 15 Mar 2016 06:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 6_JRSUA5v3KC for ; Tue, 15 Mar 2016 06:12:22 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 4E77412DA16 for ; Tue, 15 Mar 2016 06:12:22 -0700 (PDT)
Received: by mail-qg0-x229.google.com with SMTP id w104so13456899qge.1 for ; Tue, 15 Mar 2016 06:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ysyLbnq7flfatcD9k9WE2Rs/b/ZmliCAQDkYpG7FpPs=; b=mLHAZClhEIeAu+hmqaCzAV8/CDYNNzVkyjGIEEJxpvBqb0cKvQLPBpjhCK/ukhX1DE Ll1SBkOeczU+ucyRSEPDB+Eo5wjr+nFqm3wYqGIe9cG+SONabwErd6gcWtF9REQO/fyX DY2a0Q6e6if5s2oIwGNyn9OEc7j1av7EP7EYjcDb03qupWxSkOwlO4UwREtYWLLTHoVL yhQ41H4nVftTLlpyQ5PZrvTN/JHhoq77koF+WpYi12fBueu/F+H4S0ZpWagBD1eyNjXz Y2ePFwJDEcWqVf25xocDciOULnqokbREG4Nc5JSPr+kxJQ5Qxhazfz4aTpZakewfxjtD WFWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ysyLbnq7flfatcD9k9WE2Rs/b/ZmliCAQDkYpG7FpPs=; b=GV3tEGj2bfGXOGE4gDXLJkinFzwRmFA82BsyYsfqMRPn5hnic6YaY5NNbV6dbB+ZoM /R9Re0GQ3ukWgMI5SAGi5kw9No20E4C2268VbC4jODK8ail19KJu2wq6c/zKQw9oRs80 kHhAo2c4NbD+f5yX3QDVtadGqy6HVdekNzolVs7B5TFiA8pmiZoNvMRgHYjAycP+k27u W84kuD5taCkfecPRlnJKxOwmciJ75tYayAekQwKUaa06TvmGK8JGJteACsr89klPNOWy zDV/ePV5k8fAPokr7kX4D3lkA+FwqE94Vty5jMAyN1BWtsuPLw20hHuBz1ELsGt3zCtN GCnA==
X-Gm-Message-State: AD7BkJI3i3hhjzG4f5y3Y/yR23VnASAeJxLyomubjFhwNf0764vvVz8jq4VGRniU1u2qCw==
X-Received: by 10.140.141.197 with SMTP id 188mr39789181qhn.82.1458047541321;  Tue, 15 Mar 2016 06:12:21 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.44.172]) by smtp.gmail.com with ESMTPSA id u13sm12748260qkl.17.2016.03.15.06.12.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 06:12:20 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_E34FBE36-4BE1-45D3-ABD6-AAD8ED9C791A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56E8079C.3010402@gmail.com>
Date: Tue, 15 Mar 2016 10:12:16 -0300
Message-Id: <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:12:24 -0000

--Apple-Mail=_E34FBE36-4BE1-45D3-ABD6-AAD8ED9C791A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Access tokens are opaque to the client not the RS.

You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are =
standard options or you could do your own custom format and use a HMAC =
to integrity protect them.  If using astandard token format this =
supports multiple AS.

2 Use a completely opaque token and introspect it at a known AS.  This =
supports one AS

3 Hybrid use a JWT that contains an issuer as the token but with a =
single opaque claim that is used as a ID by the AS.  The RS receives the =
token looks at the issuer and sends the token to the issuer for =
introspection.   The  introspection endpoint checks the signature and =
looks up the reference to provide the introspection response as in 2.   =
This supports multiple AS.

I think Juston was recommending 3 as something he has done.

John B.

> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin  =
wrote:
>=20
> Hi
>=20
> After following the recent thread on multiple authorization servers, =
but also reading some other related threads, I have a question related =
to when the token introspection can be avoided.
>=20
> My understanding has been that given that access tokens are opaque the =
RS does not know anything about its content, hence that was the purpose =
of the token introspection spec: provide an interoperable way for RS to =
submit a token to AS and get the token data for RS to make a final =
decision about this token.
>=20
> I think if the access tokens are really opaque, i.e, they are =
sequences RS can not look into, then having the introspection option is =
the only way to check what the token is really about.
>=20
> But the recent replies with respect to using JWS or JWE tokens have =
confused me.
>=20
> 1. AccessToken as JWS JWT Token:
>=20
> RS can easily look into it, but Justin mentioned that in one case they =
first validate this JWS token and then forward it for some further =
introspection. Why start introspecting if the token has been validated =
and its content is visible ?
> Perhaps because some token data which are sensitive are only visible =
in the introspection response ? If yes then why use a self-contained =
token if some more external data are associated with it.
>=20
> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of =
times recently, Jonh B. suggested in the other thread the introspection =
may not be needed (sorry if I misread it).
> The question here, how can RS deal with a JWE token, it would need to =
share the decrypting key with AS.
>=20
> So, is introspection needed only for the completely opaque tokens or =
it is also needed for JWS and JWE tokens. I'd say it might be reasonable =
to skip it in case of JWS, depending on the specific requirements (as =
the expiry, issuer, will be typically set in JWS JWT), while with JWE I =
can not see how RS can avoid introspecting unless it shares the =
secret/private key with AS.
>=20
>=20
> Thanks, Sergey
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_E34FBE36-4BE1-45D3-ABD6-AAD8ED9C791A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxMzEyMTdaMCMGCSqGSIb3DQEJBDEWBBQsS4IJe7uNt/f5TGQxkv51
ljZq8zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBBcn3o8+cxFinCVTGrE/g6mz6w5UBOmXW60msyYcvCHiE69uhlIMK4
O2bInmMUTCf2H1VJIt3HHP7K7VwjmIfNaUPHQMvSXHo/FYKa0Ya5fPo6/RJ6fYAjEDIUD0E0tF4X
+v6zZxFaVJWFvkm0h5hyx1o6A1kA9NHKfV+iAd6gjP7Amzr8z/vOoNKMkBVooI7a2TBWWntPNMwz
SA/qsjG0xtlV94t6Fyz9P3tbpM8nupbVd4jiteJW5M/MzLd1SrTyiutJGYB5sfbyGiwoIJnoWRKg
8t+3Ma2j6XVtitnObovkqiua29mOkbYZ5LyDGf5Rz2Yrl1DNWulurk4nCI4LAAAAAAAA
--Apple-Mail=_E34FBE36-4BE1-45D3-ABD6-AAD8ED9C791A--


From nobody Tue Mar 15 06:18:05 2016
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 C440012DA29 for ; Tue, 15 Mar 2016 06:18:03 -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, FREEMAIL_FROM=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 (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 ydkN34xsHf7d for ; Tue, 15 Mar 2016 06:18:00 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 1242E12DA1A for ; Tue, 15 Mar 2016 06:17:50 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id l68so150440938wml.0 for ; Tue, 15 Mar 2016 06:17:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/pcX+q+9ybjA8tW0tEi6FC5xqZjbMKqXRjyaZvfsing=; b=QxJimQoCJCFvon/DS3Z9hrnQGNdu34RxNKC0ewNDcnTM4JV1iY62sYiEuZ/htP8Fmf G5AOOhsLDeGUl1scVXNMxCqeD9VLwLqWmzsdAxKmErSSxDVWyYy1JQfNvaR4cSGxW4Hi PagHia7gSv4gzjzsZ1cPaKfPL0T5reFOOvfwJ71bnWu2oSUfK5jRKJNQGswr6Z6+D3T4 I9Ax51tjha5jz/u9qEezZFpEHwcHvV3BynJtAekWVRCVbns7tg1ojGaMYkO8ExjZDcj3 dNQeHdo/itnYSwEI3D2WMezlrmJeRpKngm+qkuI3i+Hu4aHcciQlnJbX7l5Vr8eTvAnR u5BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/pcX+q+9ybjA8tW0tEi6FC5xqZjbMKqXRjyaZvfsing=; b=WYCKXtcj3N2st9z3MzChOpeerFtTs/4kxFTPM5Wp64lFjV+zMbiEAa/uEhGCgqotwU NuIuL5g9PLwxnMiJ0itSYKAoKKzWlRZ31wf6EenkpYpKp6mOst4nG0fqpEzfS/0pbKjm ey9L5MAbrecMz84/uU74eq/SJhNkE8ULHN+qgxDPlgXvyxdDZbWZS6e0RauvDBNAzIBa uAUL4Pbl15Gsbit+qREYqXGqN8pYrjuu0r9/vqPeRNwGgb6NzYYbzIuhradg/LaYXsHD 63uLVYaxL+SbdPMSUfpycu/WCAbm5d8qbccoUyFBK/ZDAKtNk6RuW7N9Kc9/EGG5Wpvq asoA==
X-Gm-Message-State: AD7BkJLMNuBRktJBq4VVZEuhiN7dzVIWo55NPPz1PQXBHzaoSGp3hPsxf6Bskezy8plPmA==
X-Received: by 10.28.135.4 with SMTP id j4mr24430872wmd.80.1458047868625; Tue, 15 Mar 2016 06:17:48 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id 63sm20916756wms.1.2016.03.15.06.17.47 for  (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 06:17:47 -0700 (PDT)
To: oauth@ietf.org
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E805B8.5000305@mit.edu>
From: Sergey Beryozkin 
Message-ID: <56E80B7B.2010801@gmail.com>
Date: Tue, 15 Mar 2016 13:17:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E805B8.5000305@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:18:04 -0000

Hi Justin

Many thanks for the quick response.
On 15/03/16 12:53, Justin Richer wrote:
> Is Alice the client here (the piece of software), or is Alice the
> resource owner?
Piece of software, something that needs to run without the human user 
being involved
> If Alice is the resource owner, then you should
> absolutely not be using the client credentials flow like this.
>
Sure.

> The client credentials flow is designed for cases where the client is
> acting on its own behalf, not on behalf of any particular user. It's an
> optimization of the canonical authorization code flow, where there is no
> interaction with the resource owner because there is no resource owner
> as a separate entity. It's most useful for backend systems that would
> have traditionally used a developer key to get access to bulk data. If
> you're using it for single-user access, you're doing it wrong.
>
I guess I'm still OK here, as I said, it is a piece of software which 
runs without a user. Like in all web services (SOAP or plain HTTP client 
invocations) where the client sets some credentials and accesses some 
data in the remote service.

> Also, you should keep in mind that things that seem "simple" on the
> surface are often simplified at the cost of making specific security
> concessions and assumptions. The authorization code flow is "complex"
> for very good reasons, all of them security focused. You should never
> pick a different OAuth flow just because it looks simpler, you should
> only pick them if you're within the use case that it was designed for,
> and therefor the assumptions of its security patterns match.
>
+1
> We've seen a *ton* of problems with people picking the implicit flow in
> the real world and using it with clients other than in-browser
> applications that it was designed for. If you're not in that specific
> space, you're taking on huge risks.
Sure, I understand.

So, as far as my original question is concerned, given that a client 
piece of software (no human user is involved) uses some credentials to 
get the token with client_credentials, would it be OK to avoid the 
explicit 'Client' registration with AS, given that the authentication 
system employed by AS is already aware of such credentials, I guess yes.

Thanks, Sergey
>
>   -- Justin
>
> On 3/15/2016 8:37 AM, Sergey Beryozkin wrote:
>> Hi All
>>
>> I've alway been thinking of Client Credentials as being the simplest
>> flow but now that I'm looking at implementing it myself to be used in
>> the real productions, I'm realizing that there's something I do not
>> understand about it:
>>
>> Do the clients using Client Credentials flow need to be
>> OAuth2-registered, even when such clients are already known to the
>> authentication system ?
>>
>> For example, there might be some LDAP/etc entry for Alice (name,
>> password). Now a client is using a client credentials flow to get an
>> access token:
>>
>> POST /token HTTP/1.1
>> Host: server.example.com
>> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>> Content-Type: application/x-www-form-urlencoded
>>
>> grant_type=client_credentials
>>
>> I hope that in this case no explicit registration (the one typically
>> required in redirection based flows) is needed, the client (Alice) has
>> been 'implicitly' registered (as far as the notion of OAuth2 client is
>> concerned) in LDAP/etc.
>>
>> If the explicit registration with OAuth2 AS was still required in the
>> case above then it would lead to a fairly massive duplication of
>> effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>>
>> Can someone clarify it please ?
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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


From nobody Tue Mar 15 06:18:52 2016
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 6495412D50A for ; Tue, 15 Mar 2016 06:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 JmJzyxO4wYXr for ; Tue, 15 Mar 2016 06:18:49 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 AB95712D5AD for ; Tue, 15 Mar 2016 06:18:45 -0700 (PDT)
X-AuditID: 1209190e-b0fff70000002a92-56-56e80bb4a6c3
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id D9.94.10898.4BB08E65; Tue, 15 Mar 2016 09:18:44 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u2FDIhSa012658; Tue, 15 Mar 2016 09:18:44 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2FDIfp1004316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Mar 2016 09:18:43 -0400
To: John Bradley , Sergey Beryozkin 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com>
From: Justin Richer 
Message-ID: <56E80BAE.4030309@mit.edu>
Date: Tue, 15 Mar 2016 09:18:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------010402030107000307090003"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hRV1t3C/SLM4PpsVYuTb1+xWfxbam+x +u5fNgdmj52z7rJ7LFnyk8nj9u2NLAHMUVw2Kak5mWWpRfp2CVwZk5a8Zy84bV9x5EkPawPj NuMuRk4OCQETid8/NzF1MXJxCAm0MUl82fGJBcLZyCixY+VLNpAqIYHbTBJ997NAbGEBN4kl h/cxgtgiAr4S7beOQHUvYZW4OmEXM0iCWUBI4sOlJhYQm01AVWL6mhYmEJtXQE3i5b49YHEW oPiOvitgg0QFYiSOvzvHCFEjKHFy5hOwGk4BO4kZ858xQcwMk7iwbj37BEb+WUjKZiFJQdi2 Enfm7maGsOUltr+dA2XrSizatoIdJt68dTbzAka2VYyyKblVurmJmTnFqcm6xcmJeXmpRbrG ermZJXqpKaWbGMHBLsm3g3FSg/chRgEORiUe3g8yz8OEWBPLiitzDzFKcjApifKqPQQK8SXl p1RmJBZnxBeV5qQWH2KU4GBWEuHl5ngRJsSbklhZlVqUD5OS5mBREudlZGBgEBJITyxJzU5N LUgtgsnKcHAoSfAyAqNaSLAoNT21Ii0zpwQhzcTBCTKcB2i4KkgNb3FBYm5xZjpE/hSjopQ4 71UuoIQASCKjNA+uF5SMEt4eNn3FKA70ijDvf5AqHmAig+t+BTSYCWhwT/gzkMEliQgpqQZG ZdtFYVmTnbv8lZvmLbi4Ui3/zUzhiD+nVXkVNs214eCr+nHIlI05Yotehohs6t/+jfN79DdY 8HU9nchx2X7Pq0/a/6xLN3G92SUSWOrbbyXUf7rga2/QwyX8B9tfLbyl49PKWWUeUcPnI/R5 z9TCBd1p3zKevzre7/xMOdMjxEvQqqr+yhclluKMREMt5qLiRADNH1YoIQMAAA==
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:18:51 -0000

This is a multi-part message in MIME format.
--------------010402030107000307090003
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

And don't forget option 4: look it up in a database because the RS and 
AS are in the same box.

  -- Justin

On 3/15/2016 9:12 AM, John Bradley wrote:
> Access tokens are opaque to the client not the RS.
>
> You have three basic design choices.
> 1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format this supports multiple AS.
>
> 2 Use a completely opaque token and introspect it at a known AS.  This supports one AS
>
> 3 Hybrid use a JWT that contains an issuer as the token but with a single opaque claim that is used as a ID by the AS.  The RS receives the token looks at the issuer and sends the token to the issuer for introspection.   The  introspection endpoint checks the signature and looks up the reference to provide the introspection response as in 2.   This supports multiple AS.
>
> I think Juston was recommending 3 as something he has done.
>
> John B.
>
>> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin  wrote:
>>
>> Hi
>>
>> After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided.
>>
>> My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token.
>>
>> I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about.
>>
>> But the recent replies with respect to using JWS or JWE tokens have confused me.
>>
>> 1. AccessToken as JWS JWT Token:
>>
>> RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ?
>> Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it.
>>
>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it).
>> The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS.
>>
>> So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS.
>>
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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


--------------010402030107000307090003
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    And don't forget option 4: look it up in a database because the RS
    and AS are in the same box.
    
    
    
     -- Justin
    
    
    
    
    On 3/15/2016 9:12 AM, John Bradley
      wrote:
    
    
    
    
    
      
    Access tokens are opaque to the client not the RS.

You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format this supports multiple AS.

2 Use a completely opaque token and introspect it at a known AS.  This supports one AS

3 Hybrid use a JWT that contains an issuer as the token but with a single opaque claim that is used as a ID by the AS.  The RS receives the token looks at the issuer and sends the token to the issuer for introspection.   The  introspection endpoint checks the signature and looks up the reference to provide the introspection response as in 2.   This supports multiple AS.

I think Juston was recommending 3 as something he has done.

John B.


    
      
    
        
    On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

Hi

After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided.

My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token.

I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about.

But the recent replies with respect to using JWS or JWE tokens have confused me.

1. AccessToken as JWS JWT Token:

RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ?
Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it.

2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS.

So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS.


Thanks, Sergey





_______________________________________________
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

    
    
    
    
    
  


--------------010402030107000307090003--


From nobody Tue Mar 15 06:22:03 2016
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 B7A8312D8E6 for ; Tue, 15 Mar 2016 06:22:01 -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, FREEMAIL_FROM=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 (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 0Y_RZkR5UqKH for ; Tue, 15 Mar 2016 06:21:59 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 824CD12D50A for ; Tue, 15 Mar 2016 06:21:59 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id l68so144626535wml.0 for ; Tue, 15 Mar 2016 06:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZSkBWDZzDKxB2WhZAG2pjZ5UuDsKIXs72pg2Q0G5xHY=; b=b++CNEdjLNi4fYoouRUm0VeEa1J3a5udkTT2nYhqgh6An0CB+GWeseG095o8zGYsyt m/EqgS0FhByT/t1neEUha2RzkiZQju0L1fiZjRjbGufsBIYPLuMTK/rOdhoBM79GqJzj trHxOwTe6Xm3xxETI9sr+epbTOMoRttKs0ITAeL43eswfJm9kI4Bs0T6e1FOfad9iQ3P raKTzYfIGl4EggTERXobCFVJPYAI2k4XMhEzYcYoCHiJsFp1YbEmMW02NiIhb1nD+X8Z CC0VXxGwKb19yt/VZkM/nIkbIbsKA9EzftRbj1frHvgCjRAY23h4bClEId2PP4LpDsE8 6GKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZSkBWDZzDKxB2WhZAG2pjZ5UuDsKIXs72pg2Q0G5xHY=; b=dBN6od41eolwaZC4k+MyrrTdxylI06kUcBIP9Sf/ay1Oy0YXeznz8ZstzQ/iqMMQO/ gP0eVzaapQDzNoEq6fogrgkN+K3rQnAnBZXwlKLySiQNFr1xpzLP5xQkeBNCVby/08cf bd0zDtqJMMc9bTeajSjia7Bm8qB0xwo+U/am4CaZStswv6scCaSuzI6wXIzGTE1FPWLd Mf+Z+/Z7ouMIzhCYdv5CfLEalIeWg/sCYckZ1lSxlKz/MpCGBYrzihVEnOSvsTHdMwtG +e5aT+jCf2sq7/7wXwKNCrPW8XB2vAz/7Ybv9U9XiyGQoCqaJB47Yg+kKoGcT5cgNi27 6xZQ==
X-Gm-Message-State: AD7BkJIonpAVjKt2iVXFaa688w4SoSPkszchVh7BZTal8+Bid4sk5+ERbARjXh2w7mirdQ==
X-Received: by 10.28.176.133 with SMTP id z127mr24636322wme.66.1458048118032;  Tue, 15 Mar 2016 06:21:58 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id gg7sm27157934wjd.10.2016.03.15.06.21.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 06:21:56 -0700 (PDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> 
From: Sergey Beryozkin 
Message-ID: <56E80C74.3060104@gmail.com>
Date: Tue, 15 Mar 2016 13:21:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:22:01 -0000

Hi John
On 15/03/16 13:05, John Bradley wrote:
> I think you may be confusing Client credentials flow with resource owner credentials flow.
>
Sorry, I should've clarified initially, it is a piece of software that 
needs to run without a human user. So I hope it is still client_credentials.

> If there is a resource owner in the flow use code.   The resource owner credentials flow is a bad idea and only put in for backwards compatibility.
>
Right, I was about to ask how resource owner credentials can help :-), 
but I guess I'll stay away from it for now.

Thanks, Sergey

> John B.
>
>> On Mar 15, 2016, at 9:37 AM, Sergey Beryozkin  wrote:
>>
>> Hi All
>>
>> I've alway been thinking of Client Credentials as being the simplest flow but now that I'm looking at implementing it myself to be used in the real productions, I'm realizing that there's something I do not understand about it:
>>
>> Do the clients using Client Credentials flow need to be OAuth2-registered, even when such clients are already known to the authentication system ?
>>
>> For example, there might be some LDAP/etc entry for Alice (name, password). Now a client is using a client credentials flow to get an access token:
>>
>> POST /token HTTP/1.1
>> Host: server.example.com
>> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>> Content-Type: application/x-www-form-urlencoded
>>
>> grant_type=client_credentials
>>
>> I hope that in this case no explicit registration (the one typically required in redirection based flows) is needed, the client (Alice) has been 'implicitly' registered (as far as the notion of OAuth2 client is concerned) in LDAP/etc.
>>
>> If the explicit registration with OAuth2 AS was still required in the case above then it would lead to a fairly massive duplication of effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>>
>> Can someone clarify it please ?
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Tue Mar 15 06:31:58 2016
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 850F812D5DB for ; Tue, 15 Mar 2016 06:31:56 -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, FREEMAIL_FROM=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 (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 6rE38MLQljxn for ; Tue, 15 Mar 2016 06:31:54 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 1FE6312D62E for ; Tue, 15 Mar 2016 06:31:54 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id l124so11042990wmf.1 for ; Tue, 15 Mar 2016 06:31:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=pq0bZNjuSJAeEoIr1MJHzSqMkc/LJfThR7MCZf4mBj0=; b=hbK6Npm2WIEvSuE9mKQu06K3blJozoSNfZh2tdxmbZwUlz5V0N8mj8jcv/Devh2jIF DPzTZwZiqZRF4/T+EvB0OPFQhiVdOfJcKvZYeMAsR1FxqUNlEKtfHTxIuG51aK6suKv3 6CqVQVCIm1IF3x1Qx32JaAueQ+DxVo4CfN+jVow9pSr6vOR/pqcn5+58rW1yDKSqQ8sj tMBkdgZnl89sDE670pyI1v1CJbWUTNbGXkDw9xura21HKDkYq0FbFniBQsov/yt+rRgX lpCehAVVO26hvvr6L4wKi7ZzwEpcqKM6kufINRXUTAWY7KyIZfiD4E8U1qptrjr5BYi3 iHWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pq0bZNjuSJAeEoIr1MJHzSqMkc/LJfThR7MCZf4mBj0=; b=d0VIvtYSbof29tM9qHg/eE477DyP69+l/W3VII1vJ1ujwI5iZwplFI7KUFK8ILtiY+ K9yO8p0NcZ3HEW0RgOd9XmqTJGmS5RnJhdCqN4LM4E3oixkOI7INiu6adh5ddN/tmIZa W2Gl8wji+/cW3AncEF2BmR9cvnJl7hPQg38H3bzk3W/zWyc/oTMTEpnWUK53zxj9S3V0 SCC+uqjv1HsAYW3brt8FCxkmGGaCysPBJoYnAhMXVe8UlKmk5p40md9K/Se63bLXTOG8 ZxGTbf3FfigNtWtyLrnBEMXaIKwF2aEc3NHPd/Q5Qs7pQOY+1iA8J10aB0pgLwwo/fJ2 uiXg==
X-Gm-Message-State: AD7BkJIyfPfDE5CfRFevIfvXiDi6uA5Q8DVXzybRXVRvO1bjS5Tz4IvnuHcTCENJSgVxBw==
X-Received: by 10.194.205.138 with SMTP id lg10mr30113944wjc.153.1458048712571;  Tue, 15 Mar 2016 06:31:52 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id up6sm27089922wjc.6.2016.03.15.06.31.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 06:31:51 -0700 (PDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com>
From: Sergey Beryozkin 
Message-ID: <56E80EC7.5080207@gmail.com>
Date: Tue, 15 Mar 2016 13:31:51 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:31:56 -0000

Hi John, Justin
On 15/03/16 13:12, John Bradley wrote:
> Access tokens are opaque to the client not the RS.
>
But only if they are self-contained as in the option 1 below, right ?
> You have three basic design choices.
> 1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format this supports multiple AS.

OK.
>
> 2 Use a completely opaque token and introspect it at a known AS.  This supports one AS
>
OK

> 3 Hybrid use a JWT that contains an issuer as the token but with a single opaque claim that is used as a ID by the AS.  The RS receives the token looks at the issuer and sends the token to the issuer for introspection.   The  introspection endpoint checks the signature and looks up the reference to provide the introspection response as in 2.   This supports multiple AS.
>
> I think Juston was recommending 3 as something he has done.
Thanks for clarifying it, that was what 'jti' was for I believe, very 
interesting, I did not get the first time I read it for sure :-).
But this is a non-interoperable solution, right ? I.e, it depends on a 
given AS preparing a token this way, would other AS be able to do it too ?

Thanks, Sergey
>
> John B.
>
>> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin  wrote:
>>
>> Hi
>>
>> After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided.
>>
>> My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token.
>>
>> I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about.
>>
>> But the recent replies with respect to using JWS or JWE tokens have confused me.
>>
>> 1. AccessToken as JWS JWT Token:
>>
>> RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ?
>> Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it.
>>
>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it).
>> The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS.
>>
>> So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS.
>>
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>



From nobody Tue Mar 15 06:33:47 2016
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 EAC4C12D6EB for ; Tue, 15 Mar 2016 06:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 eDRaparuHb4M for ; Tue, 15 Mar 2016 06:33:42 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 C13F312D8A5 for ; Tue, 15 Mar 2016 06:33:41 -0700 (PDT)
X-AuditID: 1209190f-a1bff70000007696-df-56e80f343354
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 74.C6.30358.43F08E65; Tue, 15 Mar 2016 09:33:40 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u2FDXdn9007131; Tue, 15 Mar 2016 09:33:40 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2FDXcFf009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Mar 2016 09:33:39 -0400
To: Sergey Beryozkin , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com> <56E80EC7.5080207@gmail.com>
From: Justin Richer 
Message-ID: <56E80F2F.80807@mit.edu>
Date: Tue, 15 Mar 2016 09:33:35 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E80EC7.5080207@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixG6nomvC/yLM4NZdFYuTb1+xWfxbam+x +u5fNgdmj52z7rJ7LFnyk8nj9u2NLAHMUVw2Kak5mWWpRfp2CVwZM9fOYC/YrFSxfe01tgbG DukuRk4OCQETiQt/TjJ2MXJxCAm0MUnMn/uWHcLZyCgx7/USKOc2k8ScZ/dZQVqEBdwklhze xwhiiwj4Sjx4958Vougwq8S1/h1gRcwCQhIfLjWxgNhsAqoS09e0MHUxcnDwCqhI9O3zBDFZ gMInDpeCVIgKxEgcf3cObCSvgKDEyZlPWEBKOAU0JY73s0AMtJW4M3c3M4QtL7H97RzmCYwC s5B0zEJSNgtJ2QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhBgcspyb+D cU6D9yFGAQ5GJR7eGVLPw4RYE8uKK3MPMUpyMCmJ8qo9BArxJeWnVGYkFmfEF5XmpBYfYpTg YFYS4eXmeBEmxJuSWFmVWpQPk5LmYFES52VkYGAQEkhPLEnNTk0tSC2CycpwcChJ8F7iBWoU LEpNT61Iy8wpQUgzcXCCDOcBGl4NUsNbXJCYW5yZDpE/xagoJc5bApIQAElklObB9YISS8Lb w6avGMWBXhHmFeQDquIBJiW47ldAg5mABveEPwMZXJKIkJJqYJxj3cxS/uV1hd63ksboOfIa tW6NF+S6rhqyxDne2PyVYa/5lKRfvMqed7jdP6feCM24b8tz7Ixj/JbMQP17tRd/z7E8wOb8 WKKEYbNgTYLLxc+zdHfWfCw8cLB4c+KivjUuajJ/X9WUCYS/F/ml97dWbwnbodePZF0nnJgU rLqRiSdZ7JS0txJLcUaioRZzUXEiAM1LppcHAwAA
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:33:46 -0000

Hi Sergey, one comment inline

On 3/15/2016 9:31 AM, Sergey Beryozkin wrote:
> Hi John, Justin
> On 15/03/16 13:12, John Bradley wrote:
>> Access tokens are opaque to the client not the RS.
>>
> But only if they are self-contained as in the option 1 below, right ?

No. They're non-opaque to the RS in all cases. In that, the RS needs to 
be able to figure out what information the token represents. That 
doesn't mean that the RS can *parse* the token, but it needs to be able 
to find all associated security info about the token (scopes, users, 
clients, expirations) in order to make it work.


>> You have three basic design choices.
>> 1 Use a token that the RS can locally validate.  JWT or SAML are 
>> standard options or you could do your own custom format and use a 
>> HMAC to integrity protect them.  If using astandard token format this 
>> supports multiple AS.
>
> OK.
>>
>> 2 Use a completely opaque token and introspect it at a known AS.  
>> This supports one AS
>>
> OK
>
>> 3 Hybrid use a JWT that contains an issuer as the token but with a 
>> single opaque claim that is used as a ID by the AS.  The RS receives 
>> the token looks at the issuer and sends the token to the issuer for 
>> introspection.   The introspection endpoint checks the signature and 
>> looks up the reference to provide the introspection response as in 
>> 2.   This supports multiple AS.
>>
>> I think Juston was recommending 3 as something he has done.
> Thanks for clarifying it, that was what 'jti' was for I believe, very 
> interesting, I did not get the first time I read it for sure :-).
> But this is a non-interoperable solution, right ? I.e, it depends on a 
> given AS preparing a token this way, would other AS be able to do it 
> too ?
>
> Thanks, Sergey
>>
>> John B.
>>
>>> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin 
>>>  wrote:
>>>
>>> Hi
>>>
>>> After following the recent thread on multiple authorization servers, 
>>> but also reading some other related threads, I have a question 
>>> related to when the token introspection can be avoided.
>>>
>>> My understanding has been that given that access tokens are opaque 
>>> the RS does not know anything about its content, hence that was the 
>>> purpose of the token introspection spec: provide an interoperable 
>>> way for RS to submit a token to AS and get the token data for RS to 
>>> make a final decision about this token.
>>>
>>> I think if the access tokens are really opaque, i.e, they are 
>>> sequences RS can not look into, then having the introspection option 
>>> is the only way to check what the token is really about.
>>>
>>> But the recent replies with respect to using JWS or JWE tokens have 
>>> confused me.
>>>
>>> 1. AccessToken as JWS JWT Token:
>>>
>>> RS can easily look into it, but Justin mentioned that in one case 
>>> they first validate this JWS token and then forward it for some 
>>> further introspection. Why start introspecting if the token has been 
>>> validated and its content is visible ?
>>> Perhaps because some token data which are sensitive are only visible 
>>> in the introspection response ? If yes then why use a self-contained 
>>> token if some more external data are associated with it.
>>>
>>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple 
>>> of times recently, Jonh B. suggested in the other thread the 
>>> introspection may not be needed (sorry if I misread it).
>>> The question here, how can RS deal with a JWE token, it would need 
>>> to share the decrypting key with AS.
>>>
>>> So, is introspection needed only for the completely opaque tokens or 
>>> it is also needed for JWS and JWE tokens. I'd say it might be 
>>> reasonable to skip it in case of JWS, depending on the specific 
>>> requirements (as the expiry, issuer, will be typically set in JWS 
>>> JWT), while with JWE I can not see how RS can avoid introspecting 
>>> unless it shares the secret/private key with AS.
>>>
>>>
>>> Thanks, Sergey
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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


From nobody Tue Mar 15 06:35:33 2016
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 5B56B12D9EA for ; Tue, 15 Mar 2016 06:35:29 -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, FREEMAIL_FROM=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 (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 QIeUmzZGy6sF for ; Tue, 15 Mar 2016 06:35:22 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 5A8B712D6EB for ; Tue, 15 Mar 2016 06:35:22 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id l68so145194034wml.0 for ; Tue, 15 Mar 2016 06:35:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KCrFdcVVhqcKd2fhL8RLV3bA5YLUHY2r9ZSCLiK1Gv4=; b=kVTv1gDi98C6E87EVkWd57LUDNHjOYTJWDpnqrQGNOt47bLLwhq84AMtRMESANGjBr /QCBWniCui19SP95OgFLD2WxFXuKuBQVmfjhYVCdx8w/CyED2PpP6UWhFB0Jn1A8VShN nZ7umaxo7H6/HfEe/awSyYB7VpIf6ZxOQ/5SUtgU567+jOrvvXJceQkV1hGx2GVxszHw ecih9pWzUvihl5R7d7iH6wr9CM0Jnl4eBR8V74r+HSt2usyO4NIggVRksW/4rwyJ8Hj3 YAvt4WekL9s8lCchy+xzsZkI5I6E8ReauSW/zGSxCRI0drS3OOTpQbiqWmpdePiRpuXj OCyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KCrFdcVVhqcKd2fhL8RLV3bA5YLUHY2r9ZSCLiK1Gv4=; b=jDPJJgrZxCBxduO6pS6dl6sjc4z+j2m/vuu7dCLwYVwGjs7LXFmjCp9fEfdm1bt9pe TuWJxvHsdIhTFO7Y1NJrk9FUUZ1yaJhbJExmcbYZQywwCwBO4cubT6d5lv/N6MoCOXHK z30qD55e3aubyZzQsQGfxHajvEoIin/s/N7ySoUBrtwyYx+HghQd4S+4ZuEy9RRL15N2 YLVPrVzeFJyC1g4XGwefdXOEu/8dnCBNjz9WSusQ1ObmrTlgyLJAQwaLe2mKrl95Fx0+ FXcArNB5oovx7gtNVcjbsT0FpijSlNRRLVa+/JIvQzf2pSoH1tonvXb6gtQ+jYZD86Zq +fwA==
X-Gm-Message-State: AD7BkJKErO/nALwVlYtU03y9c4DirCO7vo+ChFSMQTlRtxO7wHx57r+EE+CECx4xFxjs3g==
X-Received: by 10.28.17.198 with SMTP id 189mr23715385wmr.47.1458048920921; Tue, 15 Mar 2016 06:35:20 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id hq2sm27073668wjb.3.2016.03.15.06.35.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 06:35:20 -0700 (PDT)
To: Justin Richer , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com> <56E80BAE.4030309@mit.edu>
From: Sergey Beryozkin 
Message-ID: <56E80F97.2030608@gmail.com>
Date: Tue, 15 Mar 2016 13:35:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E80BAE.4030309@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:35:29 -0000

Hi Justin

On 15/03/16 13:18, Justin Richer wrote:
> And don't forget option 4: look it up in a database because the RS and
> AS are in the same box.
Sometimes I feel like I understand OAuth2 and today I'm feeling like 
I've no idea  what it is :-).

Are AS and RS meant to be collocated ? I thought it was a demo situation 
only :-)

Cheers, Sergey

>
>   -- Justin
>
> On 3/15/2016 9:12 AM, John Bradley wrote:
>> Access tokens are opaque to the client not the RS.
>>
>> You have three basic design choices.
>> 1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format this supports multiple AS.
>>
>> 2 Use a completely opaque token and introspect it at a known AS.  This supports one AS
>>
>> 3 Hybrid use a JWT that contains an issuer as the token but with a single opaque claim that is used as a ID by the AS.  The RS receives the token looks at the issuer and sends the token to the issuer for introspection.   The  introspection endpoint checks the signature and looks up the reference to provide the introspection response as in 2.   This supports multiple AS.
>>
>> I think Juston was recommending 3 as something he has done.
>>
>> John B.
>>
>>> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin  wrote:
>>>
>>> Hi
>>>
>>> After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided.
>>>
>>> My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token.
>>>
>>> I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about.
>>>
>>> But the recent replies with respect to using JWS or JWE tokens have confused me.
>>>
>>> 1. AccessToken as JWS JWT Token:
>>>
>>> RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ?
>>> Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it.
>>>
>>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it).
>>> The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS.
>>>
>>> So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS.
>>>
>>>
>>> Thanks, Sergey
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>


From nobody Tue Mar 15 06:37:00 2016
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 ACD4E12D8A5 for ; Tue, 15 Mar 2016 06:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 P9pXVp7RrdWp for ; Tue, 15 Mar 2016 06:36:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 BAC1E12D6EB for ; Tue, 15 Mar 2016 06:36:56 -0700 (PDT)
X-AuditID: 12074425-a83ff700000064bb-68-56e80ff7d8b4
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id C0.C8.25787.7FF08E65; Tue, 15 Mar 2016 09:36:55 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u2FDas51012286; Tue, 15 Mar 2016 09:36:55 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2FDarC5010281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Mar 2016 09:36:54 -0400
To: Sergey Beryozkin , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com> <56E80BAE.4030309@mit.edu> <56E80F97.2030608@gmail.com>
From: Justin Richer 
Message-ID: <56E80FF2.203@mit.edu>
Date: Tue, 15 Mar 2016 09:36:50 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E80F97.2030608@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrvud/0WYwZRmJYuTb1+xWfxbam+x +u5fNgdmj52z7rJ7LFnyk8nj9u2NLAHMUVw2Kak5mWWpRfp2CVwZ05buZC24qVRx6MMR1gbG LdJdjJwcEgImEj++PGDsYuTiEBJoY5KY3XOBFcLZyChx9/kcJgjnNpNE/7cVbCAtwgJuEksO 72MEsUUEfCUevPsP1XGPVeLv/a0sIAlmASGJD5eawGw2AVWJ6WtamEBsXgEliSXLFrGD2CxA 8Un/J4PViArESBx/d44RokZQ4uTMJ0BxDg5OAU2JSdu1IUbaStyZu5sZwpaX2P52DvMERoFZ SDpmISmbhaRsASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0LvdzMEr3UlNJNjODgdVHdwTjn r9chRgEORiUe3hlSz8OEWBPLiitzDzFKcjApifJG870IE+JLyk+pzEgszogvKs1JLT7EKMHB rCTCy80BlONNSaysSi3Kh0lJc7AoifMyMjAwCAmkJ5akZqemFqQWwWRlODiUJHiPgwwVLEpN T61Iy8wpQUgzcXCCDOcBGv4CpIa3uCAxtzgzHSJ/ilFRSpw3BCQhAJLIKM2D6wUll4S3h01f MYoDvSLMawdMNUI8wMQE1/0KaDAT0OCe8Gcgg0sSEVJSDYxVd+ekvciXSRFfdyT95VIunp0/ DmmWcokpH2IwO1xXHhB5/s31gozAoq9W529/OHUn2NdP9Nq2+K0N5syeItcf1+v6XJRw27Zp 5fmlU93D6wXXf/n3NIhLffJ5AcHUn8wnp5qVzb3NGqB//dbz8taEU5J/Uky+idSVZIRO2l1m /WuS1DY1u0NKLMUZiYZazEXFiQCI71nTCQMAAA==
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:36:59 -0000

On 3/15/2016 9:35 AM, Sergey Beryozkin wrote:
> Hi Justin
>
> On 15/03/16 13:18, Justin Richer wrote:
>> And don't forget option 4: look it up in a database because the RS and
>> AS are in the same box.
> Sometimes I feel like I understand OAuth2 and today I'm feeling like 
> I've no idea  what it is :-).
>
> Are AS and RS meant to be collocated ? I thought it was a demo 
> situation only :-)
>
> Cheers, Sergey

They're conceptually separate, but they can be served by the same 
machine and therefore have trusted, proprietary, back-end communications 
between them that don't need to be interoperable. It's not just for 
demos, and it's actually one of the most common (if not the most common) 
deployment of OAuth 2.

  -- Justin


>
>>
>>   -- Justin
>>
>> On 3/15/2016 9:12 AM, John Bradley wrote:
>>> Access tokens are opaque to the client not the RS.
>>>
>>> You have three basic design choices.
>>> 1 Use a token that the RS can locally validate.  JWT or SAML are 
>>> standard options or you could do your own custom format and use a 
>>> HMAC to integrity protect them.  If using astandard token format 
>>> this supports multiple AS.
>>>
>>> 2 Use a completely opaque token and introspect it at a known AS.  
>>> This supports one AS
>>>
>>> 3 Hybrid use a JWT that contains an issuer as the token but with a 
>>> single opaque claim that is used as a ID by the AS. The RS receives 
>>> the token looks at the issuer and sends the token to the issuer for 
>>> introspection.   The  introspection endpoint checks the signature 
>>> and looks up the reference to provide the introspection response as 
>>> in 2.   This supports multiple AS.
>>>
>>> I think Juston was recommending 3 as something he has done.
>>>
>>> John B.
>>>
>>>> On Mar 15, 2016, at 10:01 AM, Sergey 
>>>> Beryozkin  wrote:
>>>>
>>>> Hi
>>>>
>>>> After following the recent thread on multiple authorization 
>>>> servers, but also reading some other related threads, I have a 
>>>> question related to when the token introspection can be avoided.
>>>>
>>>> My understanding has been that given that access tokens are opaque 
>>>> the RS does not know anything about its content, hence that was the 
>>>> purpose of the token introspection spec: provide an interoperable 
>>>> way for RS to submit a token to AS and get the token data for RS to 
>>>> make a final decision about this token.
>>>>
>>>> I think if the access tokens are really opaque, i.e, they are 
>>>> sequences RS can not look into, then having the introspection 
>>>> option is the only way to check what the token is really about.
>>>>
>>>> But the recent replies with respect to using JWS or JWE tokens have 
>>>> confused me.
>>>>
>>>> 1. AccessToken as JWS JWT Token:
>>>>
>>>> RS can easily look into it, but Justin mentioned that in one case 
>>>> they first validate this JWS token and then forward it for some 
>>>> further introspection. Why start introspecting if the token has 
>>>> been validated and its content is visible ?
>>>> Perhaps because some token data which are sensitive are only 
>>>> visible in the introspection response ? If yes then why use a 
>>>> self-contained token if some more external data are associated with 
>>>> it.
>>>>
>>>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple 
>>>> of times recently, Jonh B. suggested in the other thread the 
>>>> introspection may not be needed (sorry if I misread it).
>>>> The question here, how can RS deal with a JWE token, it would need 
>>>> to share the decrypting key with AS.
>>>>
>>>> So, is introspection needed only for the completely opaque tokens 
>>>> or it is also needed for JWS and JWE tokens. I'd say it might be 
>>>> reasonable to skip it in case of JWS, depending on the specific 
>>>> requirements (as the expiry, issuer, will be typically set in JWS 
>>>> JWT), while with JWE I can not see how RS can avoid introspecting 
>>>> unless it shares the secret/private key with AS.
>>>>
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>


From nobody Tue Mar 15 06:39:45 2016
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 0378A12D8A5 for ; Tue, 15 Mar 2016 06:39:44 -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, FREEMAIL_FROM=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 (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 jr0ux99lkIlB for ; Tue, 15 Mar 2016 06:39:40 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 0114912D5AF for ; Tue, 15 Mar 2016 06:39:40 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id l68so27034587wml.1 for ; Tue, 15 Mar 2016 06:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=cw7ZNPoP3pDk426z94XbzYOQuIpKYpKCyfvpF1Lwv7g=; b=u1C8Sy4K2O+zYkufElecmziaXgoYy27jnKCH0t6abTaEogRVk5nIsl9nqTjhnjLitr lTl/CaoSBLpKtvT1eR+HiIZXzXA8CEA2YPiufXUHDp26F7r3vH1PIEMCtkwCD1jZgy/y KQRWIm5Rmb4/zFjcf4vJ0j7yHirlNv5adb8Sq/gHkEGp3sCQtM5gsynW3SPFJ0eFiPK/ 16uZt6ejjpqjGzkgA9aIMB+kD9L6Dv/tUT25GFFmd8B58G94gqU8yLXOE+PY+4Q8+7C8 XLa2fEU75R6jCogg9e0LegRKUlDkTrlmBuBu8ZUxQzsUMhCDgdgbVEE9Hg0ffsLfOn/x +F1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cw7ZNPoP3pDk426z94XbzYOQuIpKYpKCyfvpF1Lwv7g=; b=HLBEpxNXLthT/j9pdkKwEHmeb4YOHm1Jl7rtJLjRWT1x3uDUMqgVXBVMLD47x7jxGb O7aK3EP3YZD9LWFOi2eRv7nwvHWs3u3KtvPOnG1FcuTgCQXZoGHj5y0NS204GMF38XTD Q9e1YwJLyDbNwkq5L/euiQFhSHdkLgKShQzSfaCHbOzzdl2+8o+THVanV1pZoNqfCaRL zqy9mvSw9EE+K9ikObgcmfyPLTwgcmkreitR6V8bx0dOKbCpG3Ba1tiT+wqHtiG8PgGn oM92CyZ9RaVSDVB+nCG1+erzr7ugxx5bgo86cJ6RzndY3nKtm8BJ1Rcu8LvMJLj7AZEI KgBQ==
X-Gm-Message-State: AD7BkJKEbXzgqANN5VYiuFZ1WoJPAvJFUSAkOxXKsuZQL8TSlGQjLnLnproPoqINApR+GQ==
X-Received: by 10.194.84.66 with SMTP id w2mr30480588wjy.6.1458049177772; Tue, 15 Mar 2016 06:39:37 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id gk4sm27129034wjd.7.2016.03.15.06.39.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 06:39:37 -0700 (PDT)
To: Justin Richer , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com> <56E80EC7.5080207@gmail.com> <56E80F2F.80807@mit.edu>
From: Sergey Beryozkin 
Message-ID: <56E81098.4090405@gmail.com>
Date: Tue, 15 Mar 2016 13:39:36 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E80F2F.80807@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:39:44 -0000

Hi Justin

It does help, thanks, I was really meaning to ask whether RS was able to 
parse it or not itself, without getting the external introspection 
support, but using a wrong term, 'opaque' for it :-).


Thanks
Sergey
On 15/03/16 13:33, Justin Richer wrote:
> Hi Sergey, one comment inline
>
> On 3/15/2016 9:31 AM, Sergey Beryozkin wrote:
>> Hi John, Justin
>> On 15/03/16 13:12, John Bradley wrote:
>>> Access tokens are opaque to the client not the RS.
>>>
>> But only if they are self-contained as in the option 1 below, right ?
>
> No. They're non-opaque to the RS in all cases. In that, the RS needs to
> be able to figure out what information the token represents. That
> doesn't mean that the RS can *parse* the token, but it needs to be able
> to find all associated security info about the token (scopes, users,
> clients, expirations) in order to make it work.
>
>
>>> You have three basic design choices.
>>> 1 Use a token that the RS can locally validate.  JWT or SAML are
>>> standard options or you could do your own custom format and use a
>>> HMAC to integrity protect them.  If using astandard token format this
>>> supports multiple AS.
>>
>> OK.
>>>
>>> 2 Use a completely opaque token and introspect it at a known AS. This
>>> supports one AS
>>>
>> OK
>>
>>> 3 Hybrid use a JWT that contains an issuer as the token but with a
>>> single opaque claim that is used as a ID by the AS.  The RS receives
>>> the token looks at the issuer and sends the token to the issuer for
>>> introspection.   The introspection endpoint checks the signature and
>>> looks up the reference to provide the introspection response as in
>>> 2.   This supports multiple AS.
>>>
>>> I think Juston was recommending 3 as something he has done.
>> Thanks for clarifying it, that was what 'jti' was for I believe, very
>> interesting, I did not get the first time I read it for sure :-).
>> But this is a non-interoperable solution, right ? I.e, it depends on a
>> given AS preparing a token this way, would other AS be able to do it
>> too ?
>>
>> Thanks, Sergey
>>>
>>> John B.
>>>
>>>> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin
>>>>  wrote:
>>>>
>>>> Hi
>>>>
>>>> After following the recent thread on multiple authorization servers,
>>>> but also reading some other related threads, I have a question
>>>> related to when the token introspection can be avoided.
>>>>
>>>> My understanding has been that given that access tokens are opaque
>>>> the RS does not know anything about its content, hence that was the
>>>> purpose of the token introspection spec: provide an interoperable
>>>> way for RS to submit a token to AS and get the token data for RS to
>>>> make a final decision about this token.
>>>>
>>>> I think if the access tokens are really opaque, i.e, they are
>>>> sequences RS can not look into, then having the introspection option
>>>> is the only way to check what the token is really about.
>>>>
>>>> But the recent replies with respect to using JWS or JWE tokens have
>>>> confused me.
>>>>
>>>> 1. AccessToken as JWS JWT Token:
>>>>
>>>> RS can easily look into it, but Justin mentioned that in one case
>>>> they first validate this JWS token and then forward it for some
>>>> further introspection. Why start introspecting if the token has been
>>>> validated and its content is visible ?
>>>> Perhaps because some token data which are sensitive are only visible
>>>> in the introspection response ? If yes then why use a self-contained
>>>> token if some more external data are associated with it.
>>>>
>>>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple
>>>> of times recently, Jonh B. suggested in the other thread the
>>>> introspection may not be needed (sorry if I misread it).
>>>> The question here, how can RS deal with a JWE token, it would need
>>>> to share the decrypting key with AS.
>>>>
>>>> So, is introspection needed only for the completely opaque tokens or
>>>> it is also needed for JWS and JWE tokens. I'd say it might be
>>>> reasonable to skip it in case of JWS, depending on the specific
>>>> requirements (as the expiry, issuer, will be typically set in JWS
>>>> JWT), while with JWE I can not see how RS can avoid introspecting
>>>> unless it shares the secret/private key with AS.
>>>>
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>


From nobody Tue Mar 15 06:49:08 2016
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 E7EE812D574 for ; Tue, 15 Mar 2016 06:49:07 -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, FREEMAIL_FROM=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 (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 pSHNfJ8ue2Tk for ; Tue, 15 Mar 2016 06:49:06 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 E03DC12D5B9 for ; Tue, 15 Mar 2016 06:49:05 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id l68so151588508wml.0 for ; Tue, 15 Mar 2016 06:49:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=nIhN0v0p1PnEYkNy/7cwoGJM6sT1BDIiicKneK2Di30=; b=YYbZHkLSAr9xiNuKSaqOvzhj1IN6/E2x+PqftGjg0DYCzMjYWGHP8vq9L6EuLmXGl2 hS1uFoN8juoWa9BRQzgYeDJMFYMiu7lYT9G0SldoZXFs+VvivGUy6fDXp6NonhhhDZMq frACu4O3IYXq73RuJvBDrRDGtbcNOW9v0rLET9dLKvRx6FL/yAdqmnmRjs+qbC4L7cje NENbMXy42HpcqKCMbvNRN8BNlNYGgD+h3kWYiKcpu3VKsRbLhbElB4WFEebVK2TaogAk oh+K7jRHnh99TUxu4YUEa2SLyvfQI46koD9xgzpIZIlafYSaArE2kZYHY0uD25eNYBar LrSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nIhN0v0p1PnEYkNy/7cwoGJM6sT1BDIiicKneK2Di30=; b=XK2oDmFg1A4I92brHMWK5EUlZwqi80YlrtpyrUVkqXKyKWmYgyM3ErzT2zDu/V8/z8 83cTVObDep8MnnbdJhS+NG2kRp4UmGpbkQyxVBtIZ0CVJWUMbdxt5+H1T50IzBfoEgbW 9QREQbLh3HraiU7tG39XLOe8lxz57XA5QAIA5b1W3JXQdK6QJJ82Q8QSN9fLDDue5kQV ZwNT2hxkxeLMLjy9AK5r9CkMiLXpcEUU9DYRsjopUTakbntPd0hx+tK7okZgG+oUPnwV hmXKisTRt45KeZXReou2ixm1K365woOjmSKz1M0pNL+FABV/SRO01B3LrzKg+KT3yOyD KHGw==
X-Gm-Message-State: AD7BkJLyKBvqivG0Yy3yg4JRrksKl3rPFvP8rkuJ80BwfirEj3gvDH1t0/xSDGGzyhRecA==
X-Received: by 10.28.134.137 with SMTP id i131mr25374147wmd.62.1458049744430;  Tue, 15 Mar 2016 06:49:04 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id e14sm21083751wmi.21.2016.03.15.06.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 06:49:03 -0700 (PDT)
To: Justin Richer , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com> <56E80BAE.4030309@mit.edu> <56E80F97.2030608@gmail.com> <56E80FF2.203@mit.edu>
From: Sergey Beryozkin 
Message-ID: <56E812CF.4070203@gmail.com>
Date: Tue, 15 Mar 2016 13:49:03 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E80FF2.203@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 13:49:08 -0000

Hi Justin

I guess it depends on what the customer requirements are, with the AS 
vendor neutrality being one of the variables - something that we had to 
deal with recently.
Or if the RS stack is flexible in a way that it can be easily adapted to 
work with AS from multiple vendors. I can see how it works.

Thanks, Sergey

On 15/03/16 13:36, Justin Richer wrote:
>
> On 3/15/2016 9:35 AM, Sergey Beryozkin wrote:
>> Hi Justin
>>
>> On 15/03/16 13:18, Justin Richer wrote:
>>> And don't forget option 4: look it up in a database because the RS and
>>> AS are in the same box.
>> Sometimes I feel like I understand OAuth2 and today I'm feeling like
>> I've no idea  what it is :-).
>>
>> Are AS and RS meant to be collocated ? I thought it was a demo
>> situation only :-)
>>
>> Cheers, Sergey
>
> They're conceptually separate, but they can be served by the same
> machine and therefore have trusted, proprietary, back-end communications
> between them that don't need to be interoperable. It's not just for
> demos, and it's actually one of the most common (if not the most common)
> deployment of OAuth 2.
>
>   -- Justin
>
>
>>
>>>
>>>   -- Justin
>>>
>>> On 3/15/2016 9:12 AM, John Bradley wrote:
>>>> Access tokens are opaque to the client not the RS.
>>>>
>>>> You have three basic design choices.
>>>> 1 Use a token that the RS can locally validate.  JWT or SAML are
>>>> standard options or you could do your own custom format and use a
>>>> HMAC to integrity protect them.  If using astandard token format
>>>> this supports multiple AS.
>>>>
>>>> 2 Use a completely opaque token and introspect it at a known AS.
>>>> This supports one AS
>>>>
>>>> 3 Hybrid use a JWT that contains an issuer as the token but with a
>>>> single opaque claim that is used as a ID by the AS. The RS receives
>>>> the token looks at the issuer and sends the token to the issuer for
>>>> introspection.   The  introspection endpoint checks the signature
>>>> and looks up the reference to provide the introspection response as
>>>> in 2.   This supports multiple AS.
>>>>
>>>> I think Juston was recommending 3 as something he has done.
>>>>
>>>> John B.
>>>>
>>>>> On Mar 15, 2016, at 10:01 AM, Sergey
>>>>> Beryozkin  wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> After following the recent thread on multiple authorization
>>>>> servers, but also reading some other related threads, I have a
>>>>> question related to when the token introspection can be avoided.
>>>>>
>>>>> My understanding has been that given that access tokens are opaque
>>>>> the RS does not know anything about its content, hence that was the
>>>>> purpose of the token introspection spec: provide an interoperable
>>>>> way for RS to submit a token to AS and get the token data for RS to
>>>>> make a final decision about this token.
>>>>>
>>>>> I think if the access tokens are really opaque, i.e, they are
>>>>> sequences RS can not look into, then having the introspection
>>>>> option is the only way to check what the token is really about.
>>>>>
>>>>> But the recent replies with respect to using JWS or JWE tokens have
>>>>> confused me.
>>>>>
>>>>> 1. AccessToken as JWS JWT Token:
>>>>>
>>>>> RS can easily look into it, but Justin mentioned that in one case
>>>>> they first validate this JWS token and then forward it for some
>>>>> further introspection. Why start introspecting if the token has
>>>>> been validated and its content is visible ?
>>>>> Perhaps because some token data which are sensitive are only
>>>>> visible in the introspection response ? If yes then why use a
>>>>> self-contained token if some more external data are associated with
>>>>> it.
>>>>>
>>>>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple
>>>>> of times recently, Jonh B. suggested in the other thread the
>>>>> introspection may not be needed (sorry if I misread it).
>>>>> The question here, how can RS deal with a JWE token, it would need
>>>>> to share the decrypting key with AS.
>>>>>
>>>>> So, is introspection needed only for the completely opaque tokens
>>>>> or it is also needed for JWS and JWE tokens. I'd say it might be
>>>>> reasonable to skip it in case of JWS, depending on the specific
>>>>> requirements (as the expiry, issuer, will be typically set in JWS
>>>>> JWT), while with JWE I can not see how RS can avoid introspecting
>>>>> unless it shares the secret/private key with AS.
>>>>>
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>


From nobody Tue Mar 15 07:13:16 2016
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 B6F4512DA93 for ; Tue, 15 Mar 2016 07:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 DHlfY7iXG7wM for ; Tue, 15 Mar 2016 07:13:06 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 3A55312D5B9 for ; Tue, 15 Mar 2016 07:12:56 -0700 (PDT)
Received: by mail-qg0-x231.google.com with SMTP id w104so15116796qge.1 for ; Tue, 15 Mar 2016 07:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=moS3gjqLiSvvoE76UVHS4vqA2/sLulTQLneXJkv4YaE=; b=prXVmzSgbOtinBnn3S4dtVJzwD9SYN0F9t5hr94eVkIovmN6/jAAWOMdn/AW/OCGEO kQoqCcQi4B+Rpz0R4WTKzK9yXL7XmiLDIGQNogInmUHmy30WeEHfXGeJMbstHRRY1deo /9RAu/HjSUwdVJY9w/YhrDN+sOKCJQq+VYf8s03qZt2nZtKbJ0hmhch7BNAybha3b/4V msiHbH1qTUDWrgNRUBhuPz/l1b5qfGuO6I5ULr4UaqVwH2JhnLpV+xKrfT458fAaTupN U7CT4fgIaXdUCYVIkBHEXPBGTSpYiPK9EjqoDazOcOCQGcsnUrPLCjXh/yRViXiV6T3I KzCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=moS3gjqLiSvvoE76UVHS4vqA2/sLulTQLneXJkv4YaE=; b=iLuzlotMW8eCvlbAxnaaffqXe0z8SDZ9N/bhWcxDqbmxaLp1GfYXakWv4eNqZwxRjY +WmiYdhhpXDs8QwJ1XKdhKPaq3dN+9I/34WJRDp7uKsyf4XBtDWwNsQV0IzWr6LwunlY /EZp4gyrCs329DjUBUot2Ib7/Dqku9UVbsKRTW6e0XtKr6QZnUlwOIQneZkoBPQDq7YF 1y5RbAYxXXrQHMaSfFb+1tb7TQ25kFpoFhU8ycHm3dGHnSDJcs0bKqBt9zCPfIlThw6G SIMQoP9CBqWsO170JwH1pNUUB1sZdjAC2lI5f39NYRStytSgihVsEmkqcWybBJlWhZVz oD4A==
X-Gm-Message-State: AD7BkJLAosnGtIQ7Pm1FZpnoz+oydjWaFdsBP9aeD1eC9bzbgYtMFql5ga1EimuMc0Tdxw==
X-Received: by 10.140.29.202 with SMTP id b68mr37971473qgb.100.1458051175299;  Tue, 15 Mar 2016 07:12:55 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.44.172]) by smtp.gmail.com with ESMTPSA id f83sm12813373qkb.25.2016.03.15.07.12.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 07:12:54 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_390A1AE1-BA9A-4E1F-A76C-DB9008E1CF42"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56E812CF.4070203@gmail.com>
Date: Tue, 15 Mar 2016 11:12:49 -0300
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com> <56E80BAE.4030309@mit.edu> <56E80F97.2030608@gmail.com> <56E80FF2.203@mit.edu> <56E812CF.4070203@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 14:13:11 -0000

--Apple-Mail=_390A1AE1-BA9A-4E1F-A76C-DB9008E1CF42
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

One of the things JWT allows is interoperable access tokens from =
multiple AS.  =20

The OAuth specs have always been a bit hand-wavy about access tokens =
saying that they are a local implementation decision.

You can use JWT or introspection or a database lookup, but leave it to =
the implementation to decide.

With RS that are truly separate from AS and may be accepting tokens from =
multiple AS interoperability is perhaps becoming more of an issue.

At some point it might be worth the WG at-least laying out the options =
for developers in one place.

John B.


> On Mar 15, 2016, at 10:49 AM, Sergey Beryozkin  =
wrote:
>=20
> Hi Justin
>=20
> I guess it depends on what the customer requirements are, with the AS =
vendor neutrality being one of the variables - something that we had to =
deal with recently.
> Or if the RS stack is flexible in a way that it can be easily adapted =
to work with AS from multiple vendors. I can see how it works.
>=20
> Thanks, Sergey
>=20
> On 15/03/16 13:36, Justin Richer wrote:
>>=20
>> On 3/15/2016 9:35 AM, Sergey Beryozkin wrote:
>>> Hi Justin
>>>=20
>>> On 15/03/16 13:18, Justin Richer wrote:
>>>> And don't forget option 4: look it up in a database because the RS =
and
>>>> AS are in the same box.
>>> Sometimes I feel like I understand OAuth2 and today I'm feeling like
>>> I've no idea  what it is :-).
>>>=20
>>> Are AS and RS meant to be collocated ? I thought it was a demo
>>> situation only :-)
>>>=20
>>> Cheers, Sergey
>>=20
>> They're conceptually separate, but they can be served by the same
>> machine and therefore have trusted, proprietary, back-end =
communications
>> between them that don't need to be interoperable. It's not just for
>> demos, and it's actually one of the most common (if not the most =
common)
>> deployment of OAuth 2.
>>=20
>>  -- Justin
>>=20
>>=20
>>>=20
>>>>=20
>>>>  -- Justin
>>>>=20
>>>> On 3/15/2016 9:12 AM, John Bradley wrote:
>>>>> Access tokens are opaque to the client not the RS.
>>>>>=20
>>>>> You have three basic design choices.
>>>>> 1 Use a token that the RS can locally validate.  JWT or SAML are
>>>>> standard options or you could do your own custom format and use a
>>>>> HMAC to integrity protect them.  If using astandard token format
>>>>> this supports multiple AS.
>>>>>=20
>>>>> 2 Use a completely opaque token and introspect it at a known AS.
>>>>> This supports one AS
>>>>>=20
>>>>> 3 Hybrid use a JWT that contains an issuer as the token but with a
>>>>> single opaque claim that is used as a ID by the AS. The RS =
receives
>>>>> the token looks at the issuer and sends the token to the issuer =
for
>>>>> introspection.   The  introspection endpoint checks the signature
>>>>> and looks up the reference to provide the introspection response =
as
>>>>> in 2.   This supports multiple AS.
>>>>>=20
>>>>> I think Juston was recommending 3 as something he has done.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>> On Mar 15, 2016, at 10:01 AM, Sergey
>>>>>> Beryozkin  wrote:
>>>>>>=20
>>>>>> Hi
>>>>>>=20
>>>>>> After following the recent thread on multiple authorization
>>>>>> servers, but also reading some other related threads, I have a
>>>>>> question related to when the token introspection can be avoided.
>>>>>>=20
>>>>>> My understanding has been that given that access tokens are =
opaque
>>>>>> the RS does not know anything about its content, hence that was =
the
>>>>>> purpose of the token introspection spec: provide an interoperable
>>>>>> way for RS to submit a token to AS and get the token data for RS =
to
>>>>>> make a final decision about this token.
>>>>>>=20
>>>>>> I think if the access tokens are really opaque, i.e, they are
>>>>>> sequences RS can not look into, then having the introspection
>>>>>> option is the only way to check what the token is really about.
>>>>>>=20
>>>>>> But the recent replies with respect to using JWS or JWE tokens =
have
>>>>>> confused me.
>>>>>>=20
>>>>>> 1. AccessToken as JWS JWT Token:
>>>>>>=20
>>>>>> RS can easily look into it, but Justin mentioned that in one case
>>>>>> they first validate this JWS token and then forward it for some
>>>>>> further introspection. Why start introspecting if the token has
>>>>>> been validated and its content is visible ?
>>>>>> Perhaps because some token data which are sensitive are only
>>>>>> visible in the introspection response ? If yes then why use a
>>>>>> self-contained token if some more external data are associated =
with
>>>>>> it.
>>>>>>=20
>>>>>> 2. AccessToken as JWE JWT Token: this option was mentioned a =
couple
>>>>>> of times recently, Jonh B. suggested in the other thread the
>>>>>> introspection may not be needed (sorry if I misread it).
>>>>>> The question here, how can RS deal with a JWE token, it would =
need
>>>>>> to share the decrypting key with AS.
>>>>>>=20
>>>>>> So, is introspection needed only for the completely opaque tokens
>>>>>> or it is also needed for JWS and JWE tokens. I'd say it might be
>>>>>> reasonable to skip it in case of JWS, depending on the specific
>>>>>> requirements (as the expiry, issuer, will be typically set in JWS
>>>>>> JWT), while with JWE I can not see how RS can avoid introspecting
>>>>>> unless it shares the secret/private key with AS.
>>>>>>=20
>>>>>>=20
>>>>>> Thanks, Sergey
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_390A1AE1-BA9A-4E1F-A76C-DB9008E1CF42
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxNDEyNDlaMCMGCSqGSIb3DQEJBDEWBBTU+YcvKPRHrMT7nSbTQkUI
D6anoDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAElb+7zNmad3JaDzT6aGk7n1uzQQHTGrj8cCpi0+9+BnhBPTXZC62Z
4nfFLftMIl0mSO/eyFaSRs+xRj2sWnGTs9G1rxHopR7QaStLya2LiKHluzheIEQ1+OahJdpZDj1g
SY1RZtQndHhwAUMt/dBBye5jTZEDaDcazVI3U78ODxHiATGcnZRkwGz6XGQ826J8VLR3xFQkZl76
ap9WWgAyvbXnktHkgwl9w8c9MqdNUNMHo4Ar5qQs1dUWEEPPgJ3T4qK+91g2QMP6qTYeM2DDvl9K
44pH0+theLfBDoRTyIfYHHNngWTlhSX2CTIfr0PpSo8yj2+TRhZcx+zrcH0PAAAAAAAA
--Apple-Mail=_390A1AE1-BA9A-4E1F-A76C-DB9008E1CF42--


From nobody Tue Mar 15 07:57:38 2016
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 7344F12D86F for ; Tue, 15 Mar 2016 07:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 zwKfIOSDFydV for ; Tue, 15 Mar 2016 07:57:34 -0700 (PDT)
Received: from omr-a003e.mx.aol.com (omr-a003e.mx.aol.com [204.29.186.57]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C93812D545 for ; Tue, 15 Mar 2016 07:57:34 -0700 (PDT)
Received: from mtaout-aah02.mx.aol.com (mtaout-aah02.mx.aol.com [172.27.1.142]) by omr-a003e.mx.aol.com (Outbound Mail Relay) with ESMTP id 7C1DC3800083; Tue, 15 Mar 2016 10:57:33 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aah02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 11A603800009E; Tue, 15 Mar 2016 10:57:33 -0400 (EDT)
To: John Bradley , Sergey Beryozkin 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E822DC.9010109@aol.com>
Date: Tue, 15 Mar 2016 10:57:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <8B00AE61-8CFA-48B7-AED8-12B2AF64D69A@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------080108090500020207010905"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458053853; bh=s1qoKC5W46p1sfS+Nya0cEaoKGeT4NoACwuGX2VhAww=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ase4uaJgw7OnD5u3VeoKETBhIz66dhbNgXtyMD8LgR4kMkWIPmFtzKzt/Gm/3B5AR GZd9EsVvd6oSjI+1oYZJNMm1jvoRSTlLORYtTU6CviMToD4x0wJEY5zSTNXLQJt4oM 7k4Gty9aCbNgZ7+2A1zwQcNpXfJulSqnDHUNdUMc=
x-aol-sid: 3039ac1b018e56e822dd07da
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 14:57:36 -0000

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

We have also implemented option 3. In our case, the RS is supporting our 
own AS and an external trusted AS. The hybrid JWT allows us to know 
where to validate the token and also allows the external AS to protect 
it's token in a way that is not visible to us.

Thanks,
George

On 3/15/16 9:12 AM, John Bradley wrote:
> Access tokens are opaque to the client not the RS.
>
> You have three basic design choices.
> 1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format this supports multiple AS.
>
> 2 Use a completely opaque token and introspect it at a known AS.  This supports one AS
>
> 3 Hybrid use a JWT that contains an issuer as the token but with a single opaque claim that is used as a ID by the AS.  The RS receives the token looks at the issuer and sends the token to the issuer for introspection.   The  introspection endpoint checks the signature and looks up the reference to provide the introspection response as in 2.   This supports multiple AS.
>
> I think Juston was recommending 3 as something he has done.
>
> John B.
>
>> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin  wrote:
>>
>> Hi
>>
>> After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided.
>>
>> My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token.
>>
>> I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about.
>>
>> But the recent replies with respect to using JWS or JWE tokens have confused me.
>>
>> 1. AccessToken as JWS JWT Token:
>>
>> RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ?
>> Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it.
>>
>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it).
>> The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS.
>>
>> So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS.
>>
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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


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


  
    
  
  
    We have also implemented
      option 3. In our case, the RS is supporting our own AS and an
      external trusted AS. The hybrid JWT allows us to know where to
      validate the token and also allows the external AS to protect it's
      token in a way that is not visible to us.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/15/16 9:12 AM, John Bradley wrote:
    
    
    
    
    
      
    Access tokens are opaque to the client not the RS.

You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format this supports multiple AS.

2 Use a completely opaque token and introspect it at a known AS.  This supports one AS

3 Hybrid use a JWT that contains an issuer as the token but with a single opaque claim that is used as a ID by the AS.  The RS receives the token looks at the issuer and sends the token to the issuer for introspection.   The  introspection endpoint checks the signature and looks up the reference to provide the introspection response as in 2.   This supports multiple AS.

I think Juston was recommending 3 as something he has done.

John B.


    
      
    
        
    On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

Hi

After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided.

My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token.

I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about.

But the recent replies with respect to using JWS or JWE tokens have confused me.

1. AccessToken as JWS JWT Token:

RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ?
Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it.

2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS.

So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS.


Thanks, Sergey





_______________________________________________
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

    
    
    
    
    
  


--------------080108090500020207010905--


From nobody Tue Mar 15 08:00:55 2016
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 120D412D62E for ; Tue, 15 Mar 2016 08:00:54 -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=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 NBP5vZUTaT0w for ; Tue, 15 Mar 2016 08:00:46 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 9DF7A12D58B for ; Tue, 15 Mar 2016 08:00:42 -0700 (PDT)
Received: by mail-ig0-x22f.google.com with SMTP id vf5so89688267igb.0 for ; Tue, 15 Mar 2016 08:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GVOL4QMlO1BbNCz2nkSXqFHjlKUINB5ClprEA5tibMo=; b=Y5C4Ab4Lx7S1Y0+x7xj9b2HRyuL4oN+v4x2n5nHj+/QhZkW+qRJKyeZoV/K9Opa8e4 9kqcM5GWe+4wWRdcdXharkO5G5+zUkr2eoZjwVb0ORF/Wg+4AqMCqMyFTahJo9+hD5RM e+nKO5OA2WS+hDChX2ma/Rt4G9boI9T8sgFcc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GVOL4QMlO1BbNCz2nkSXqFHjlKUINB5ClprEA5tibMo=; b=BJ9m5cQatv/68PAJ1LWFGnkqER3iVlRrFuBiqml7GWDfpdAqjHohK9ZckVGu/lVZJN wjg0VfCVcRHZXxY8q2QXDUFn/uCyyV3kvxQ6rVxlD8JQk/Ap+GKbj8W+a4TB+j7CYh/b rtmj1A2LwKZo06lnf/TNUqX4y2/CTeQ7gjut/W0e1NBntv8yjJBLJEPm6W/I4zJs7O+7 7ixGbTsF03XVQ9EEKLMcbDHdgYHDzJQLr/XB+/181EfQ6Pdzeac+t+y9O/JcMPCaOhPx ElO5Rxa5pyW7Il+pnqK9rSmhfRYkBeru6bnDTd3WKPtLWsJM2R83zTYy4PWdT63TrmP5 WJsQ==
X-Gm-Message-State: AD7BkJIiznaEANEQr4WJYl6KgvnEJs86jt9fO8pmpdfRhCltCZBGwznCQ/mQEpvrSLTPce+i+rRvGmNGlD+YxI9n
X-Received: by 10.50.60.34 with SMTP id e2mr25376086igr.77.1458054041831; Tue, 15 Mar 2016 08:00:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 15 Mar 2016 08:00:12 -0700 (PDT)
In-Reply-To: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <56E73A7C.3040405@pingidentity.com> 
From: Brian Campbell 
Date: Tue, 15 Mar 2016 09:00:12 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=047d7b10ce3b3a2c8c052e17a945
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 15:00:54 -0000

--047d7b10ce3b3a2c8c052e17a945
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Discovery in general for OAuth isn't well understood. This conversation and
others like it around the 'discovery' draft demonstrate that. But
publishing AS metadata is something that is understood and already in wide
use for Connect. The rough consensus (except for a very few but vocal
dissenters) on this list over the last few weeks/months has been that
draft-ietf-oauth-discovery should describing AS metadata and its location.
It's been suggested that the title reflect that scope and I might even
suggest that the document identifier be changed to avoid further
confusion.

The IDP mixup is addressed by the AS identifying itself to the client in
the authorization response (it has a few other things in it that arguably
shouldn't be in or should be elsewhere but that's a different question).
The Mix-Up Mitigation draft uses the issuer value to do that. Issuer
becomes a logical name/identifier for an AS. And that can tie it to AS
metadata or even discovery if/when that exists. But discovery or AS
metadata isn't necessary there. Yes Tony, we'd all like to see a
comprehensive solution but conflating different and unrelated things is
only making matters worse (as I'm sure you are well aware).

A 'bad RS' phishing for legitimate access tokens is a different kind of
endpoint confusion. Most deployments now have a static relationship defined
between RS and AS so it's more of a potential problem in the future.
Despite the concern voiced about it the potential (as far as I can tell
anyway), draft-hunt-oauth-bound-config provides a very nice attack vector
for such a 'bad RS' by pointing to an AS to obtain tokens it could misuse
at legitimate RS(s). John has alluded to this.

There have been a number of incremental updates/extensions to OAuth 2.0 and
there look to be more coming.  Concerns have been expressed over the number
of documents and implements knowing what to use when. I don't think the
answer is to try and jam unrelated new stuff into new docs to keep the
number of docs low is a good idea though. I'd much prefer to have concise
and cohesive documents. The larger issue of confusion around too many
documents should be addressed at a higher level. For example, something
like an implementation guide or even something like an OAuth 2.1 that
describes the available extensions and when/why one would use them.



On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadalin 
wrote:

> I would really like to see a comprehensive solution not this piece work,
> so we know what we are solving and what we are not.
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hans Zandbelt
> Sent: Monday, March 14, 2016 3:26 PM
> To: Phil Hunt (IDM) ; John Bradley <
> ve7jtb@ve7jtb.com>
> Cc: oauth 
> Subject: Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-bound-config-00.txt
>
> On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:
> 
> > On Mar 14, 2016, at 14:13, John Bradley  > > wrote:
> >> Any client that has the resource and issuer hard coded probably
> >> doesn't need discovery.
> > We agree
>
> Yet any client that has hard coded a resource and 2 issuers doesn't need
> discovery either but is vulnerable to the IDP mixup attack.
>
> I'd really like to see the two being addressed independently of each
> other, regardless of the fact that a Discovery solution *could* solve the
> IDP mixup attack as well.
>
> Hans.
>
> --
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com | Ping Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie=
tf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.co=
m%7c8cd9a8b2e020444382a708d34c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1=
&sdata=3D1dsstJfhduQ3mZERUx6%2fO3OE241RK7ataalg6RY6JmA%3d
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--047d7b10ce3b3a2c8c052e17a945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Discovery in general for OAuth isn't well un=
derstood. This=20
conversation and others like it around the 'discovery' draft demons=
trate
 that. But publishing AS metadata is something that is understood and=20
already in wide use for Connect. The rough consensus (except for
 a very few but vocal dissenters) on this list over the last few=20
weeks/months has been that draft-ietf-oauth-discovery should describing=20
AS metadata and its location. It's been suggested that the title reflec=
t
 that scope and I might even suggest that the document identifier be=20
changed to avoid further confusion.=C2=A0 

    The IDP mixup is=20
addressed by the AS identifying itself to the client in the=20
authorization response (it has a few other things in it that arguably shoul=
dn't be in or should be elsewhere but that's a different question).=
 The Mix-Up Mitigation draft uses the issuer=20
value to do that. Issuer becomes a logical name/identifier for an AS.=20
And that can tie it to AS metadata or even discovery if/when that=20
exists. But discovery or AS metadata isn't necessary there. Yes Tony,=
=20
we'd all like to see a  comprehensive solution but conflating different=
 and unrelated things is only making matters worse (as I'm sure you are=
 well aware).

    A 'bad RS' phishing for legitimate =
access tokens is a different kind of endpoint confusion. Most deployments n=
ow have a static relationship defined between RS and AS so it's more of=
 a potential problem in the future. Despite the concern voiced about it the=
 potential (as far as I can tell anyway), draft-hunt-oauth-bound-config pro=
vides a very nice attack vector for such a 'bad RS' by pointing to =
an AS to obtain tokens it could misuse at legitimate RS(s). John has allude=
d to this.

    There have been a number of incremental =
updates/extensions to OAuth 2.0 and there look to be more coming.=C2=A0 Con=
cerns have been expressed over the number of documents and implements knowi=
ng what to use when. I don't think the answer is to try and jam unrelat=
ed new stuff into new docs to keep the number of docs low is a good idea th=
ough. I'd much prefer to have concise and cohesive documents. The large=
r issue of confusion around too many documents should be addressed at a hig=
her level. For example, something like an implementation guide or even some=
thing like an OAuth 2.1 that describes the available extensions and when/wh=
y one would use them. 

    =C2=A0
    On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadali=
n <tonynad@microsoft.com> wrote:
    I would really like to see a comprehensive so=
lution not this piece work, so we know what we are solving and what we are =
not.
    

    
-----Original Message-----
    
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hans Zandbelt
    
Sent: Monday, March 14, 2016 3:26 PM
    
To: Phil Hunt (IDM) <phil.hunt@oracle.com>; John Bradley <ve7jtb@ve7jtb.com>
    
Cc: oauth <oauth@iet=
f.org>
    
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound=
-config-00.txt
    

    
    On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:
    
<snip>
    
> On Mar 14, 2016, at 14:13, John Bradley <ve7jtb@ve7jtb.com
    
> <mailto:ve7j=
tb@ve7jtb.com>> wrote:
    
>> Any client that has the resource and issuer hard coded probably
>> doesn't need discovery.
    
> We agree
    

    
Yet any client that has hard coded a resource and 2 issuers doesn't nee=
d discovery either but is vulnerable to the IDP mixup attack.
    

    
I'd really like to see the two being addressed independently of each ot=
her, regardless of the fact that a Discovery solution *could* solve the IDP=
 mixup attack as well.
    

    
Hans.
    

    
--
    
Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Technic=
al Architect
    
hzandbelt@p=
ingidentity.com | Ping Identity
    

    
_______________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
    https://na01.safelinks.protect=
ion.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foa=
uth&data=3D01%7c01%7ctonynad%40microsoft.com%7c8cd9a8b2e020444382a708d3=
4c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D1dsstJfhduQ3mZE=
RUx6%2fO3OE241RK7ataalg6RY6JmA%3d
    


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


    

--047d7b10ce3b3a2c8c052e17a945--


From nobody Tue Mar 15 08:10:14 2016
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 6D97112D985 for ; Tue, 15 Mar 2016 08:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 hSV1N49QUgkx for ; Tue, 15 Mar 2016 08:10:08 -0700 (PDT)
Received: from omr-a015e.mx.aol.com (omr-a015e.mx.aol.com [204.29.186.63]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D37B12DABE for ; Tue, 15 Mar 2016 08:09:47 -0700 (PDT)
Received: from mtaout-mce02.mx.aol.com (mtaout-mce02.mx.aol.com [172.29.27.206]) by omr-a015e.mx.aol.com (Outbound Mail Relay) with ESMTP id B18E4380008E; Tue, 15 Mar 2016 11:09:46 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mce02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 02955380000B1; Tue, 15 Mar 2016 11:09:45 -0400 (EDT)
To: Hans Zandbelt , Justin Richer , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E825B9.6090400@aol.com>
Date: Tue, 15 Mar 2016 11:09:45 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E7494F.906@pingidentity.com>
Content-Type: multipart/alternative; boundary="------------050403030902090000060600"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458054586; bh=Yd9aebyj1ptfFaF+nGQDYMo8b0mjEkWa1eaG6VwTag4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=h3FIXy4E+SdbeihUIoIIJYqSdnzIMtWFcSZQ5PvdX+luDpSxyyy/aV8iOxb3SF6Cb 6wnq28IJCDuwV0DjPPwY+7YfWZd3zrq7UYVWUoAd+vWo3A/0MvpiFt6/RXeZLe6str 6bM1zJhQocFqx2AkI4pxR0l9IB7GSoDV7XEecopk=
x-aol-sid: 3039ac1d1bce56e825b938a6
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 15:10:12 -0000

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

I worry about two directions I see in this thread...

1. Client's accessing resources dynamically so that discovery is 
required to know the correct AS, etc. This is pretty much the classic 
use case for UMA and I'd rather not re-invent the wheel.

2. Creating a tight coupling between RS and AS such that RS endpoint 
changes must be continually communicated to the AS. If an RS supports 
multiple AS's then the RS has to deal with "guaranteed" delivery. The AS 
needs an endpoint to receive such communications. If not dynamic via 
APIs, then deployment of the new RS is bound by the associated AS's 
getting and deploying the new endpoints. Can both endpoints of the RS be 
supported within the AS for some period of time, etc. This is an 
operation nightmare and almost assuredly going to go wrong in production.

Maybe an OAuth2 "audience binding" spec is what's needed for those 
deployments that require this. I believe that is what John Bradley is 
suggesting.

Thanks,
George

On 3/14/16 7:29 PM, Hans Zandbelt wrote:
> +1, I've found the very same in OAuth deployments that I was involved 
> in; the hard part is to give names and descriptions to these concepts 
> so that they cover all use cases and can be applied unambiguously
>
> Hans.
>
> On 3/14/16 10:44 PM, Justin Richer wrote:
>> I agree that this is valuable, and not just for PoP. In all honesty,
>> it’s not even really required for PoP to function in many cases — it’s
>> just an optimization for one particular kind of key distribution
>> mechanism in that case.
>>
>> In the years of deployment experience with OAuth 2, I think we’ve really
>> got three different kinds of things that currently get folded into
>> “scope†that we might want to try separating out better:
>>
>>
>>   - What things do I want to access? (photos, profile)
>>   - What actions do I want to take on these things? (read, write, 
>> delete)
>>   - How long do I want these tokens to work?
>> (offline_access/refresh_token, one time use, next hour, etc)
>>
>>
>> I think the first one is close to the audience/resource parameters that
>> have been bandied about a few times, including in the current token
>> exchange document. We should be consistent across drafts in that regard.
>> The second is more traditional scope-ish. The third has been patched in
>> with things like “offline_access†in certain APIs.
>>
>> Just another vector to think about if we’re going to be adding things
>> like “audience†or “resource†or both to the token requests.
>>
>>   — Justin
>>
>>
>>> On Mar 14, 2016, at 6:26 PM, John Bradley >> > wrote:
>>>
>>> Yes I will work on another proposal for allowing clients to specify
>>> what resource they want a token for and providing the meta-data to the
>>> client about the resources that a token is valid for.
>>>
>>> We have part of it in the POP key distribution spec and talked about
>>> separating it, as it is used more places than just for assigning keys.
>>> I know some AS use different token formats for different RS so are
>>> all-ready needing to pass the resource in the request to avoid making
>>> a mess of scopes.
>>>
>>> John B.
>>>
>>>
>>>
>>>
>>>
>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>> > wrote:
>>>>
>>>> Inline
>>>>
>>>> Phil
>>>>
>>>> On Mar 14, 2016, at 14:13, John Bradley >>> > wrote:
>>>>
>>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>>> The other was to mitigate the client mixup attack.  The request was
>>>>> to do the latter without requiring the former for clients that don’t
>>>>> otherwise need discovery.
>>>> There is no mandate for any of this. See
>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
>>>>
>>>>>
>>>>> Returning the issuer and client_id from the authorization endpoint
>>>>> and the client checking them can be done by the client without
>>>>> discovery.
>>>>
>>>> How does this address the issue of whether the client is talking to
>>>> the wrong endpoint?
>>>>>
>>>>> Any client that has the resource and issuer hard coded probably
>>>>> doesn’t need discovery.
>>>> We agree
>>>>
>>>>
>>>>> One of the things that a client will need discovery for is to find
>>>>> the RS, so requiring the client to know the RS URI before getting
>>>>> the AS config seems backwards to me.
>>>> How can you make an assumption on order? You seem to be conflating
>>>> authentication with authorization by assuming the identity drives
>>>> what the resource is.
>>>>
>>>> There are lots of applications that require user rights but are not
>>>> identify centric. For example a document service.
>>>>>
>>>>> Unless the client tells the AS where it intends to use the token we
>>>>> will be leaving a security hole because the bearer tokens will have
>>>>> too loose an audience if they have one at all.
>>>> This is the biggest risk we have IMHO.
>>>>>
>>>>> True you are telling the AS (Webfinger service) what the RS is but
>>>>> that is not at a place that is useful in the token production 
>>>>> process.
>>>>
>>>> This has nothing to do with token production.
>>>>
>>>> What we want to ensure is whether an honest client is correctly
>>>> configured and has not been mislead - eg by a phishing page.
>>>>>
>>>>> I also think there are use cases where the AS doesn’t know all the
>>>>> possible RS.   That is not something that a out of band check can
>>>>> address.
>>>>
>>>> May be. Lets identify them.
>>>>
>>>>> There are also cases where a token might be good at multiple RS
>>>>> endpoints intentionally.
>>>>
>>>>>  In your solution the client would need to make a discovery request
>>>>> for each endpoint.
>>>> Sure. Otherwise how would it know if there is one AS or a pool of AS
>>>> servers assigned to each instance?
>>>>> Those requests lack the context of who the client and resource owner
>>>>> are.  I think that will be a problem in some use cases.
>>>>
>>>> Not sure I agree. This is about discovering a valid set of endpoints.
>>>> For mitm, we mainly want to check the hostname is correct. If a
>>>> client chooses evil.com  the cert can be valid and
>>>> TLS will pass. How does it otherwise know it is supposed to talk to
>>>> res.example.com ?
>>>>>
>>>>> If this is added to the token endpoint it would be checked when code
>>>>> or refresh are exchanged, not every time the token is used.
>>>> Your proposal requires rhe client to check. I am not clear how the AS
>>>> can know the exact uri. It is far easier to validate than to lookup
>>>> since as you say the client may be authorized to use multiple ASs.
>>>>> With a out of band check the client would never know if a RS was
>>>>> removed/revoked.
>>>>
>>>> Not sure that is in scope.
>>>>
>>>> None of the current proposals address this issue.
>>>>>
>>>>> I don’t see checking when refreshing a token as something that is a
>>>>> huge burden.
>>>>
>>>> Still its a lot more than once.
>>>>
>>>> Why don't you draft another alternative?
>>>>>
>>>>> If the server wants to do the check on it’s side then we could
>>>>> require the client to send the RS URI in the token request. that way
>>>>> you really know the client is not going to get a token for the wrong
>>>>> RS endpoint.
>>>>> If you check out of band in discovery you really have no idea if the
>>>>> client is checking.
>>>>
>>>> In the new webfinger draft, the client isn't checking. The service
>>>> provider simply does not disclose oauth information to misconfigured
>>>> clients.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >>>>> > wrote:
>>>>>>
>>>>>> Thanks to Mike and John for their feedback.  I’ll take each in turn:
>>>>>>
>>>>>> Mike,
>>>>>>
>>>>>> Regarding your suggested amendments
>>>>>>
>>>>>> Item 1: Returning the config URL would create two problems. One,it
>>>>>> makes bound discovery a two-step process - that adds complexity.
>>>>>>  It seems far simpler to mandate TLS (which I think it already does
>>>>>> in the security considerations).
>>>>>>
>>>>>> The two-step process allows the current discovery process to
>>>>>> continue. I disagree with this. This is why I put forward an
>>>>>> “alternate" draft that is almost the same but simply adds the check
>>>>>> before returning the configuration data.  I worry that developers
>>>>>> would have no incentive to do the two-step approach. They would
>>>>>> just start at step 2 which in turn puts AS’s at risk of exposing
>>>>>> tokens because it works. This makes OAuth promiscuous.
>>>>>>
>>>>>> Regarding existing implementations. Most of those implementations
>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use of
>>>>>> OIDC's discovery spec because the UserInfo endpoint is well defined
>>>>>> and the likelihood of a client mis-informed about the resource
>>>>>> endpoint is not there.  IMO This does not apply to the broader
>>>>>> OAuth community.
>>>>>>
>>>>>> Item 2:  It may be appropriate to have a separate configuration
>>>>>> registry specification, but I think we should hold off until we
>>>>>> have a complete solution and then make the decision what drafts
>>>>>> should exist and how many pieces.  A big concern is the perceived
>>>>>> complexity of multiple solutions and multiple drafts.
>>>>>>
>>>>>> As to John Bradley’s comments:
>>>>>>
>>>>>> Re: Discovery is the wrong place to mitigate threats.
>>>>>> I’m confused by this.  Our mandate was to solve a security threat
>>>>>> by having a discovery specification to prevent clients being
>>>>>> mis-lead about endpoints (of which resource service is one) in an
>>>>>> oauth protected exchange.  Maybe what you mean is we should not use
>>>>>> .well-known of any kind and we should just create a “/Configâ€
>>>>>> endpoint to OAuth?
>>>>>>
>>>>>> Re: Your proposal for MITM mitigation
>>>>>> You propose that instead the resource endpoint check should be in
>>>>>> the oauth protocol itself.  The difference is that validation is
>>>>>> transferred back to the client to get it right. As well, without
>>>>>> the client informing the AS, I can’t see a way for the AS to know
>>>>>> what endpoint the client is using.  The webfinger approach does
>>>>>> this once and only requires that the host name be checked in many
>>>>>> cases.
>>>>>>
>>>>>> As a principle, the members have discussed many times that the AS
>>>>>> service should do validation when possible — this was particularly
>>>>>> true at the Germany meeting when this came up. This is why I prefer
>>>>>> the client tell the service provider what it intends to do and the
>>>>>> service provider can fail that request immediately if necessary. We
>>>>>> don’t have to depend on the developer getting the spec correct to
>>>>>> fail the correct way.
>>>>>>
>>>>>> I worry that adding more parameters to the authz and token protocol
>>>>>> flows increases complexity and attack surface. It also means per
>>>>>> authorization validation has to take place vs. a one-time
>>>>>> validation at config time.  Placing it in the configuration lookup
>>>>>> phase (whether via web finger or just a special OAuth endpoint)
>>>>>> seems more appropriate and far less complex - as the request itself
>>>>>> is simple and has only one parameter. Here we are not considered
>>>>>> about legitimacy of the client. we’re just concerned with the issue
>>>>>> "has the client been correctly informed?â€
>>>>>>
>>>>>> That said, it may be that when we consider all the use cases, some
>>>>>> combination of AS protocol and discovery may be both needed. I’m
>>>>>> not ready to make conclusions about this.  The current
>>>>>> oauth-discovery spec seems to put future generic clients at risk
>>>>>> and that is my primary concern.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com 
>>>>>> phil.hunt@oracle.com 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>> >
>>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks for posting this, Phil.  It provides a concrete example of
>>>>>>> a way that protected resource discovery could be added to
>>>>>>> authorization server metadata discovery, and as such, should
>>>>>>> provide useful input for working group discussions on this topic.
>>>>>>> It’s always great when someone takes the time to write an actual
>>>>>>> draft that can be examined and implemented, and I appreciate you
>>>>>>> doing that.
>>>>>>> The content of your draft points out that there appears to be
>>>>>>> complete agreement on what the authorization server metadata
>>>>>>> format should be, which is great!  I’ll note that Section 3 of
>>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server
>>>>>>> Metadata†is an exact copy of Section 2 of
>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>>>>>>> applying a correction suggested by the working group. To me this
>>>>>>> suggests that the authorization server metadata definitions in
>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative
>>>>>>> content of the draft) are clearly ready for standardization, since
>>>>>>> even your alternative proposal includes them verbatim.
>>>>>>> Reading your draft, the problem I have with it is that you are
>>>>>>> returning the AS metadata only as a WebFinger response, rather
>>>>>>> than as an https-protected resource published by the authorization
>>>>>>> server.  The choice to only return this via WebFinger makes your
>>>>>>> draft incompatible with most deployed implementations of OAuth
>>>>>>> metadata, including the 22 implementations using it listed
>>>>>>> athttp://openid.net/certification/(see the “OP Config†column in
>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft’s “ADALâ€
>>>>>>> library, which uses the metadata path for client configuration.
>>>>>>> Without having ASs provide the metadata as an https-protected
>>>>>>> resource, implementations such as ADAL can’t use it for client
>>>>>>> configuration as the currently do.
>>>>>>> Therefore, I would request that you make these minor revisions to
>>>>>>> your draft and republish, so as to provide a unified way forward
>>>>>>> that is compatible with all known existing OAuth Discovery
>>>>>>> deployments:
>>>>>>> 1.Modify your section 2 “Authorization Server WebFinger Discoveryâ€
>>>>>>> to have the WebFinger request return the issuer identifier for the
>>>>>>> AS as the “WebFinger “rel†value, rather than returning the
>>>>>>> metadata values by value as the “properties†value.
>>>>>>> 2.Reference the metadata definitions from Section 2 of
>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in your
>>>>>>> Section 3.
>>>>>>> That would have the advantage of paring your draft down to only
>>>>>>> the new things that it proposes, enabling them to be more clearly
>>>>>>> understood and evaluated on their own merits.  I look forward to
>>>>>>> the discussions of ways of performing additional kinds of OAuth
>>>>>>> discovery, and consider your draft a valuable input to those
>>>>>>> discussions.
>>>>>>> Best wishes,
>>>>>>> -- Mike
>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*John 
>>>>>>> Bradley
>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>> *To:*Phil Hunt >
>>>>>>> *Cc:*oauth >
>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>> As I have told Phil off list.
>>>>>>> Discovery is the wrong place to try and provide security against
>>>>>>> man in the middle attacks on the RS.
>>>>>>> This requires the client to know what the RS URI is before
>>>>>>> retrieving the information on the AS Configuration.
>>>>>>> The proposal Mike and I have been working on requires the client
>>>>>>> to have a notion of what API it is looking for and retrieve the
>>>>>>> .well-known file for that API from the issuer.   That allows a
>>>>>>> protocol like Connect to register its own config file that can
>>>>>>> point to the RS.
>>>>>>> If the API specific well known is not available the client can try
>>>>>>> the default oauth-server one.
>>>>>>> That then allows us to deal with restricting where AT are
>>>>>>> presented as part of the protocol rather then dragging discovery
>>>>>>> in as a requirement.
>>>>>>> In my opinion the resource the token is targeted to should be
>>>>>>> separated from the scope and returned as part of the meta-data
>>>>>>> about the AT along with scopes granted and expiry time.   We
>>>>>>> should also have a input parameter for resources so that a client
>>>>>>> can restrict tokens issued to a subset of the ones granted by the
>>>>>>> refresh token.   It would then also be possible to ask a AS for a
>>>>>>> token for a unregistered RS and have the AS produce a JWT access
>>>>>>> token with the resource as an audience if policy allows.
>>>>>>> That however was supposed to be dealt with as part of the mixed up
>>>>>>> client set of mitigations.
>>>>>>> In that the goal was to mitigate the attacks by returning
>>>>>>> meta-data about the tokens, and not to require discovery.
>>>>>>> We intend to return “iss†and “cleint_id†for the code, and I
>>>>>>> intend to discuss at the F2F returning resource for AT as well.
>>>>>>> Those mitigate the attack.
>>>>>>> I will continue to resist mixing up discovery of configuration
>>>>>>> meta-data with mitigation of the attacks.
>>>>>>> We return meta-data about the tokens now, because AT are opaque to
>>>>>>> the client, we neglected to include some of the information for
>>>>>>> the client needs to be secure.   We just need to add that in to
>>>>>>> the existing flows.
>>>>>>> While Phil’s proposal is easier for the AS to implement as an add
>>>>>>> on, it puts more of a burden on the client needing to potentially
>>>>>>> change how it stores the relationships between AS and RS to
>>>>>>> prevent compromise, I think the solution should be biased towards
>>>>>>> simplicity on the client side.
>>>>>>> If we return the resources as part of the existing meta data the
>>>>>>> client checks that against the resource it intends to send the
>>>>>>> token to and if it is not in the list then it can’t send the
>>>>>>> token.  Simple check every time it gets a new AT, no optionality.
>>>>>>> I am not saying anything new Nat has been advocating basically
>>>>>>> this for some time, and dis submit a draft.   I prefer to return
>>>>>>> the info in the existing format rather than as link headers,  but
>>>>>>> that is the largest difference between what Nat and I are saying
>>>>>>> with respect to resource.
>>>>>>> That is the core of my problem with Phil’s draft.
>>>>>>> I guess we will need to have a long conversation in BA.
>>>>>>> Regards
>>>>>>> John B.
>>>>>>>
>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt >>>>>>     > wrote:
>>>>>>>     This draft is a proposed alternate proposal for
>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same
>>>>>>>     registry for OAuth Config Metadata as the authors believe that
>>>>>>>     both solutions are not required, or depending on WG discussion
>>>>>>>     they will be merged. The intent is to provide a simple
>>>>>>>     complete draft for consideration.
>>>>>>>     How it works...
>>>>>>>     Given that a client has previously discovered an OAuth
>>>>>>>     protected resource, the bound configuration method allows a
>>>>>>>     client to return the configuration for an oauth authorization
>>>>>>>     server that can issue tokens for the resource URI specified by
>>>>>>>     the client.  The AS is not required to be in the same domain.
>>>>>>>      The AS is however required to know if it can issue tokens for
>>>>>>>     a resource service (which presumes some agreement exists on
>>>>>>>     tokens etc).
>>>>>>>     The draft does not require that the resource exist (e.g. for
>>>>>>>     unconfigured or new user based resources). It only requires
>>>>>>>     that the AS service provider agrees it can issue tokens.
>>>>>>>     From a security perspective, returning the OAuth service
>>>>>>>     configuration for a specified resource URI serves to confirm
>>>>>>>     the client is in possession of a valid resource URI ensuring
>>>>>>>     the client has received a valid set of endpoints for the
>>>>>>>     resource and the associated oauth services.
>>>>>>>     I propose that the WG consider the alternate draft carefully
>>>>>>>     as well as other submissions and evaluate the broader
>>>>>>>     discovery problem before proceeding with WGLC on OAuth 
>>>>>>> Discovery.
>>>>>>>     Thanks!
>>>>>>>     Phil
>>>>>>>     @independentid
>>>>>>>     www.independentid.com 
>>>>>>>     phil.hunt@oracle.com 
>>>>>>>
>>>>>>>
>>>>>>>         Begin forwarded message:
>>>>>>>         *From:*internet-drafts@ietf.org
>>>>>>>         
>>>>>>>         *Subject: New Version Notification for
>>>>>>>         draft-hunt-oauth-bound-config-00.txt*
>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>         *To:*"Phil Hunt" >>>>>>         >, "Anthony Nadalin"
>>>>>>>         >,
>>>>>>>         "Tony Nadalin" >>>>>>         >
>>>>>>>
>>>>>>>
>>>>>>>         A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>>>>>>>         has been successfully submitted by Phil Hunt and posted 
>>>>>>> to the
>>>>>>>         IETF repository.
>>>>>>>
>>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>>         Revision:00
>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>         Document date:2016-03-13
>>>>>>>         Group:Individual Submission
>>>>>>>         Pages:22
>>>>>>>         URL:
>>>>>>> https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>         Status:
>>>>>>> https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>         Htmlized:
>>>>>>> https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>
>>>>>>>
>>>>>>>         Abstract:
>>>>>>>           This specification defines a mechanism for the client of
>>>>>>>         an OAuth 2.0
>>>>>>>           protected resource service to obtain the configuration
>>>>>>>         details of an
>>>>>>>           OAuth 2.0 authorization server that is capable of
>>>>>>>         authorizing access
>>>>>>>           to a specific resource service.  The information
>>>>>>>         includes the OAuth
>>>>>>>           2.0 component endpoint location URIs and as well as
>>>>>>>         authorization
>>>>>>>           server capabilities.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>         Please note that it may take a couple of minutes from the
>>>>>>>         time of submission
>>>>>>>         until the htmlized version and diff are available
>>>>>>>         attools.ietf.org .
>>>>>>>
>>>>>>>         The IETF Secretariat
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     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
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>


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


  
    
  
  
    I worry about two
      directions I see in this thread...
    
      
    
      1. Client's accessing resources dynamically so that discovery is
      required to know the correct AS, etc. This is pretty much the
      classic use case for UMA and I'd rather not re-invent the wheel.
    
      
    
      2. Creating a tight coupling between RS and AS such that RS
      endpoint changes must be continually communicated to the AS. If an
      RS supports multiple AS's then the RS has to deal with
      "guaranteed" delivery. The AS needs an endpoint to receive such
      communications. If not dynamic via APIs, then deployment of the
      new RS is bound by the associated AS's getting and deploying the
      new endpoints. Can both endpoints of the RS be supported within
      the AS for some period of time, etc. This is an operation
      nightmare and almost assuredly going to go wrong in production.
    
      
    
      Maybe an OAuth2 "audience binding" spec is what's needed for those
      deployments that require this. I believe that is what John Bradley
      is suggesting.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/14/16 7:29 PM, Hans Zandbelt
      wrote:
    
    
    
    
    +1,
      I've found the very same in OAuth deployments that I was involved
      in; the hard part is to give names and descriptions to these
      concepts so that they cover all use cases and can be applied
      unambiguously
      
    
      
    
      Hans.
      
    
      
    
      On 3/14/16 10:44 PM, Justin Richer wrote:
      
    
      
    I agree that this is valuable, and not
        just for PoP. In all honesty,
        
    
        it’s not even really required for PoP to function in many cases
        — it’s
        
    
        just an optimization for one particular kind of key distribution
        
    
        mechanism in that case.
        
    
        
    
        In the years of deployment experience with OAuth 2, I think
        we’ve really
        
    
        got three different kinds of things that currently get folded
        into
        
    
        “scope†that we might want to try separating out better:
        
    
        
    
        
    
          - What things do I want to access? (photos, profile)
        
    
          - What actions do I want to take on these things? (read,
        write, delete)
        
    
          - How long do I want these tokens to work?
        
    
        (offline_access/refresh_token, one time use, next hour, etc)
        
    
        
    
        
    
        I think the first one is close to the audience/resource
        parameters that
        
    
        have been bandied about a few times, including in the current
        token
        
    
        exchange document. We should be consistent across drafts in that
        regard.
        
    
        The second is more traditional scope-ish. The third has been
        patched in
        
    
        with things like “offline_access†in certain APIs.
        
    
        
    
        Just another vector to think about if we’re going to be adding
        things
        
    
        like “audience†or “resource†or both to the token requests.
        
    
        
    
          — Justin
        
    
        
    
        
    
        
    On Mar 14, 2016, at 6:26 PM, John
          Bradley <ve7jtb@ve7jtb.com
          
    
          <mailto:ve7jtb@ve7jtb.com>> wrote:
          
    
          
    
          Yes I will work on another proposal for allowing clients to
          specify
          
    
          what resource they want a token for and providing the
          meta-data to the
          
    
          client about the resources that a token is valid for.
          
    
          
    
          We have part of it in the POP key distribution spec and talked
          about
          
    
          separating it, as it is used more places than just for
          assigning keys.
          
    
          I know some AS use different token formats for different RS so
          are
          
    
          all-ready needing to pass the resource in the request to avoid
          making
          
    
          a mess of scopes.
          
    
          
    
          John B.
          
    
          
    
          
    
          
    
          
    
          
    
          
    On Mar 14, 2016, at 7:17 PM, Phil Hunt
            (IDM) <phil.hunt@oracle.com
            
    
            <mailto:phil.hunt@oracle.com>> wrote:
            
    
            
    
            Inline
            
    
            
    
            Phil
            
    
            
    
            On Mar 14, 2016, at 14:13, John Bradley
            <ve7jtb@ve7jtb.com
            
    
            <mailto:ve7jtb@ve7jtb.com>> wrote:
            
    
            
    
            
    We had two mandates.  One was to
              provide a spec for AS metadata.
              
    
              The other was to mitigate the client mixup attack.  The
              request was
              
    
              to do the latter without requiring the former for clients
              that don’t
              
    
              otherwise need discovery.
              
    
            
    
            There is no mandate for any of this. See
            
    
http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
            
    
            
    
              
    
              Returning the issuer and client_id from the authorization
              endpoint
              
    
              and the client checking them can be done by the client
              without
              
    
              discovery.
              
    
            
    
            
    
            How does this address the issue of whether the client is
            talking to
            
    
            the wrong endpoint?
            
    
            
    
              
    
              Any client that has the resource and issuer hard coded
              probably
              
    
              doesn’t need discovery.
              
    
            
    
            We agree
            
    
            
    
            
    
            
    One of the things that a client will
              need discovery for is to find
              
    
              the RS, so requiring the client to know the RS URI before
              getting
              
    
              the AS config seems backwards to me.
              
    
            
    
            How can you make an assumption on order? You seem to be
            conflating
            
    
            authentication with authorization by assuming the identity
            drives
            
    
            what the resource is.
            
    
            
    
            There are lots of applications that require user rights but
            are not
            
    
            identify centric. For example a document service.
            
    
            
    
              
    
              Unless the client tells the AS where it intends to use the
              token we
              
    
              will be leaving a security hole because the bearer tokens
              will have
              
    
              too loose an audience if they have one at all.
              
    
            
    
            This is the biggest risk we have IMHO.
            
    
            
    
              
    
              True you are telling the AS (Webfinger service) what the
              RS is but
              
    
              that is not at a place that is useful in the token
              production process.
              
    
            
    
            
    
            This has nothing to do with token production.
            
    
            
    
            What we want to ensure is whether an honest client is
            correctly
            
    
            configured and has not been mislead - eg by a phishing page.
            
    
            
    
              
    
              I also think there are use cases where the AS doesn’t know
              all the
              
    
              possible RS.   That is not something that a out of band
              check can
              
    
              address.
              
    
            
    
            
    
            May be. Lets identify them.
            
    
            
    
            
    There are also cases where a token
              might be good at multiple RS
              
    
              endpoints intentionally.
              
    
            
    
            
    
            
     In your solution the client would
              need to make a discovery request
              
    
              for each endpoint.
              
    
            
    
            Sure. Otherwise how would it know if there is one AS or a
            pool of AS
            
    
            servers assigned to each instance?
            
    
            
    Those requests lack the context of
              who the client and resource owner
              
    
              are.  I think that will be a problem in some use cases.
              
    
            
    
            
    
            Not sure I agree. This is about discovering a valid set of
            endpoints.
            
    
            For mitm, we mainly want to check the hostname is correct.
            If a
            
    
            client chooses evil.com <http://evil.com/> the cert
            can be valid and
            
    
            TLS will pass. How does it otherwise know it is supposed to
            talk to
            
    
            res.example.com <http://res.example.com/>?
            
    
            
    
              
    
              If this is added to the token endpoint it would be checked
              when code
              
    
              or refresh are exchanged, not every time the token is
              used.
              
    
            
    
            Your proposal requires rhe client to check. I am not clear
            how the AS
            
    
            can know the exact uri. It is far easier to validate than to
            lookup
            
    
            since as you say the client may be authorized to use
            multiple ASs.
            
    
            
    With a out of band check the client
              would never know if a RS was
              
    
              removed/revoked.
              
    
            
    
            
    
            Not sure that is in scope.
            
    
            
    
            None of the current proposals address this issue.
            
    
            
    
              
    
              I don’t see checking when refreshing a token as something
              that is a
              
    
              huge burden.
              
    
            
    
            
    
            Still its a lot more than once.
            
    
            
    
            Why don't you draft another alternative?
            
    
            
    
              
    
              If the server wants to do the check on it’s side then we
              could
              
    
              require the client to send the RS URI in the token
              request. that way
              
    
              you really know the client is not going to get a token for
              the wrong
              
    
              RS endpoint.
              
    
              If you check out of band in discovery you really have no
              idea if the
              
    
              client is checking.
              
    
            
    
            
    
            In the new webfinger draft, the client isn't checking. The
            service
            
    
            provider simply does not disclose oauth information to
            misconfigured
            
    
            clients.
            
    
            
    
              
    
              John B.
              
    
              
    
              
    
              
    On Mar 14, 2016, at 3:56 PM, Phil
                Hunt <phil.hunt@oracle.com
                
    
                <mailto:phil.hunt@oracle.com>> wrote:
                
    
                
    
                Thanks to Mike and John for their feedback.  I’ll take
                each in turn:
                
    
                
    
                Mike,
                
    
                
    
                Regarding your suggested amendments
                
    
                
    
                Item 1: Returning the config URL would create two
                problems. One,it
                
    
                makes bound discovery a two-step process - that adds
                complexity.
                
    
                 It seems far simpler to mandate TLS (which I think it
                already does
                
    
                in the security considerations).
                
    
                
    
                The two-step process allows the current discovery
                process to
                
    
                continue. I disagree with this. This is why I put
                forward an
                
    
                “alternate" draft that is almost the same but simply
                adds the check
                
    
                before returning the configuration data.  I worry that 
                developers
                
    
                would have no incentive to do the two-step approach.
                They would
                
    
                just start at step 2 which in turn puts AS’s at risk of
                exposing
                
    
                tokens because it works. This makes OAuth promiscuous.
                
    
                
    
                Regarding existing implementations. Most of those
                implementations
                
    
                are for OIDC.  I think it makes sense for OIDF to
                continue use of
                
    
                OIDC's discovery spec because the UserInfo endpoint is
                well defined
                
    
                and the likelihood of a client mis-informed about the
                resource
                
    
                endpoint is not there.  IMO This does not apply to the
                broader
                
    
                OAuth community.
                
    
                
    
                Item 2:  It may be appropriate to have a separate
                configuration
                
    
                registry specification, but I think we should hold off
                until we
                
    
                have a complete solution and then make the decision what
                drafts
                
    
                should exist and how many pieces.  A big concern is the
                perceived
                
    
                complexity of multiple solutions and multiple drafts.
                
    
                
    
                As to John Bradley’s comments:
                
    
                
    
                Re: Discovery is the wrong place to mitigate threats.
                
    
                I’m confused by this.  Our mandate was to solve a
                security threat
                
    
                by having a discovery specification to prevent clients
                being
                
    
                mis-lead about endpoints (of which resource service is
                one) in an
                
    
                oauth protected exchange.  Maybe what you mean is we
                should not use
                
    
                .well-known of any kind and we should just create a
                “/Configâ€
                
    
                endpoint to OAuth?
                
    
                
    
                Re: Your proposal for MITM mitigation
                
    
                You propose that instead the resource endpoint check
                should be in
                
    
                the oauth protocol itself.  The difference is that
                validation is
                
    
                transferred back to the client to get it right. As well,
                without
                
    
                the client informing the AS, I can’t see a way for the
                AS to know
                
    
                what endpoint the client is using.  The webfinger
                approach does
                
    
                this once and only requires that the host name be
                checked in many
                
    
                cases.
                
    
                
    
                As a principle, the members have discussed many times
                that the AS
                
    
                service should do validation when possible — this was
                particularly
                
    
                true at the Germany meeting when this came up. This is
                why I prefer
                
    
                the client tell the service provider what it intends to
                do and the
                
    
                service provider can fail that request immediately if
                necessary. We
                
    
                don’t have to depend on the developer getting the spec
                correct to
                
    
                fail the correct way.
                
    
                
    
                I worry that adding more parameters to the authz and
                token protocol
                
    
                flows increases complexity and attack surface. It also
                means per
                
    
                authorization validation has to take place vs. a
                one-time
                
    
                validation at config time.  Placing it in the
                configuration lookup
                
    
                phase (whether via web finger or just a special OAuth
                endpoint)
                
    
                seems more appropriate and far less complex - as the
                request itself
                
    
                is simple and has only one parameter. Here we are not
                considered
                
    
                about legitimacy of the client. we’re just concerned
                with the issue
                
    
                "has the client been correctly informed?â€
                
    
                
    
                That said, it may be that when we consider all the use
                cases, some
                
    
                combination of AS protocol and discovery may be both
                needed. I’m
                
    
                not ready to make conclusions about this.  The current
                
    
                oauth-discovery spec seems to put future generic clients
                at risk
                
    
                and that is my primary concern.
                
    
                
    
                Best Regards,
                
    
                
    
                Phil
                
    
                
    
                @independentid
                
    
                www.independentid.com
                <http://www.independentid.com/>
                
    
                phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 13, 2016, at 10:28 PM,
                  Mike Jones
                  
    
                  <Michael.Jones@microsoft.com
                  <mailto:Michael.Jones@microsoft.com>>
                  
    
                  wrote:
                  
    
                  
    
                  Thanks for posting this, Phil.  It provides a concrete
                  example of
                  
    
                  a way that protected resource discovery could be added
                  to
                  
    
                  authorization server metadata discovery, and as such,
                  should
                  
    
                  provide useful input for working group discussions on
                  this topic.
                  
    
                  It’s always great when someone takes the time to write
                  an actual
                  
    
                  draft that can be examined and implemented, and I
                  appreciate you
                  
    
                  doing that.
                  
    
                  The content of your draft points out that there
                  appears to be
                  
    
                  complete agreement on what the authorization server
                  metadata
                  
    
                  format should be, which is great!  I’ll note that
                  Section 3 of
                  
    
                  draft-hunt-oauth-bound-config-00 titled “Authorization
                  Server
                  
    
                  Metadata†is an exact copy of Section 2 of
                  
    
                  draft-ietf-oauth-discovery-01 (with the same title),
                  modulo
                  
    
                  applying a correction suggested by the working group. 
                  To me this
                  
    
                  suggests that the authorization server metadata
                  definitions in
                  
    
                  draft-ietf-oauth-discovery (which is now the whole
                  normative
                  
    
                  content of the draft) are clearly ready for
                  standardization, since
                  
    
                  even your alternative proposal includes them verbatim.
                  
    
                  Reading your draft, the problem I have with it is that
                  you are
                  
    
                  returning the AS metadata only as a WebFinger
                  response, rather
                  
    
                  than as an https-protected resource published by the
                  authorization
                  
    
                  server.  The choice to only return this via WebFinger
                  makes your
                  
    
                  draft incompatible with most deployed implementations
                  of OAuth
                  
    
                  metadata, including the 22 implementations using it
                  listed
                  
    
                  athttp://openid.net/certification/(see the “OP Configâ€
                  column in
                  
    
                  the table) andOAuth 2.0 libraries such as Microsoft’s
                  “ADALâ€
                  
    
                  library, which uses the metadata path for client
                  configuration.
                  
    
                  Without having ASs provide the metadata as an
                  https-protected
                  
    
                  resource, implementations such as ADAL can’t use it
                  for client
                  
    
                  configuration as the currently do.
                  
    
                  Therefore, I would request that you make these minor
                  revisions to
                  
    
                  your draft and republish, so as to provide a unified
                  way forward
                  
    
                  that is compatible with all known existing OAuth
                  Discovery
                  
    
                  deployments:
                  
    
                  1.Modify your section 2 “Authorization Server
                  WebFinger Discoveryâ€
                  
    
                  to have the WebFinger request return the issuer
                  identifier for the
                  
    
                  AS as the “WebFinger “rel†value, rather than
                  returning the
                  
    
                  metadata values by value as the “properties†value.
                  
    
                  2.Reference the metadata definitions from Section 2 of
                  
    
                  draft-ietf-oauth-discovery, rather than duplicating
                  them in your
                  
    
                  Section 3.
                  
    
                  That would have the advantage of paring your draft
                  down to only
                  
    
                  the new things that it proposes, enabling them to be
                  more clearly
                  
    
                  understood and evaluated on their own merits.  I look
                  forward to
                  
    
                  the discussions of ways of performing additional kinds
                  of OAuth
                  
    
                  discovery, and consider your draft a valuable input to
                  those
                  
    
                  discussions.
                  
    
                                                                           
                  Best wishes,
                  
    
                                                                           
                  -- Mike
                  
    
                  *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf
                  Of*John Bradley
                  
    
                  *Sent:*Sunday, March 13, 2016 6:45 PM
                  
    
                  *To:*Phil Hunt <phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>>
                  
    
                  *Cc:*oauth <oauth@ietf.org
                  <mailto:oauth@ietf.org>>
                  
    
                  *Subject:*Re: [OAUTH-WG] New Version Notification for
                  
    
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  As I have told Phil off list.
                  
    
                  Discovery is the wrong place to try and provide
                  security against
                  
    
                  man in the middle attacks on the RS.
                  
    
                  This requires the client to know what the RS URI is
                  before
                  
    
                  retrieving the information on the AS Configuration.
                  
    
                  The proposal Mike and I have been working on requires
                  the client
                  
    
                  to have a notion of what API it is looking for and
                  retrieve the
                  
    
                  .well-known file for that API from the issuer.   That
                  allows a
                  
    
                  protocol like Connect to register its own config file
                  that can
                  
    
                  point to the RS.
                  
    
                  If the API specific well known is not available the
                  client can try
                  
    
                  the default oauth-server one.
                  
    
                  That then allows us to deal with restricting where AT
                  are
                  
    
                  presented as part of the protocol rather then dragging
                  discovery
                  
    
                  in as a requirement.
                  
    
                  In my opinion the resource the token is targeted to
                  should be
                  
    
                  separated from the scope and returned as part of the
                  meta-data
                  
    
                  about the AT along with scopes granted and expiry
                  time.   We
                  
    
                  should also have a input parameter for resources so
                  that a client
                  
    
                  can restrict tokens issued to a subset of the ones
                  granted by the
                  
    
                  refresh token.   It would then also be possible to ask
                  a AS for a
                  
    
                  token for a unregistered RS and have the AS produce a
                  JWT access
                  
    
                  token with the resource as an audience if policy
                  allows.
                  
    
                  That however was supposed to be dealt with as part of
                  the mixed up
                  
    
                  client set of mitigations.
                  
    
                  In that the goal was to mitigate the attacks by
                  returning
                  
    
                  meta-data about the tokens, and not to require
                  discovery.
                  
    
                  We intend to return “iss†and “cleint_id†for the
                  code, and I
                  
    
                  intend to discuss at the F2F returning resource for AT
                  as well.
                  
    
                  Those mitigate the attack.
                  
    
                  I will continue to resist mixing up discovery of
                  configuration
                  
    
                  meta-data with mitigation of the attacks.
                  
    
                  We return meta-data about the tokens now, because AT
                  are opaque to
                  
    
                  the client, we neglected to include some of the
                  information for
                  
    
                  the client needs to be secure.   We just need to add
                  that in to
                  
    
                  the existing flows.
                  
    
                  While Phil’s proposal is easier for the AS to
                  implement as an add
                  
    
                  on, it puts more of a burden on the client needing to
                  potentially
                  
    
                  change how it stores the relationships between AS and
                  RS to
                  
    
                  prevent compromise, I think the solution should be
                  biased towards
                  
    
                  simplicity on the client side.
                  
    
                  If we return the resources as part of the existing
                  meta data the
                  
    
                  client checks that against the resource it intends to
                  send the
                  
    
                  token to and if it is not in the list then it can’t
                  send the
                  
    
                  token.  Simple check every time it gets a new AT, no
                  optionality.
                  
    
                  I am not saying anything new Nat has been advocating
                  basically
                  
    
                  this for some time, and dis submit a draft.   I prefer
                  to return
                  
    
                  the info in the existing format rather than as link
                  headers,  but
                  
    
                  that is the largest difference between what Nat and I
                  are saying
                  
    
                  with respect to resource.
                  
    
                  That is the core of my problem with Phil’s draft.
                  
    
                  I guess we will need to have a long conversation in
                  BA.
                  
    
                  Regards
                  
    
                  John B.
                  
    
                  
    
                      On Mar 13, 2016, at 8:12 PM, Phil Hunt
                  <phil.hunt@oracle.com
                  
    
                      <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                      This draft is a proposed alternate proposal for
                  
    
                      draft-ietf-oauth-discovery.  As such, it contains
                  the same
                  
    
                      registry for OAuth Config Metadata as the authors
                  believe that
                  
    
                      both solutions are not required, or depending on
                  WG discussion
                  
    
                      they will be merged. The intent is to provide a
                  simple
                  
    
                      complete draft for consideration.
                  
    
                      How it works...
                  
    
                      Given that a client has previously discovered an
                  OAuth
                  
    
                      protected resource, the bound configuration method
                  allows a
                  
    
                      client to return the configuration for an oauth
                  authorization
                  
    
                      server that can issue tokens for the resource URI
                  specified by
                  
    
                      the client.  The AS is not required to be in the
                  same domain.
                  
    
                       The AS is however required to know if it can
                  issue tokens for
                  
    
                      a resource service (which presumes some agreement
                  exists on
                  
    
                      tokens etc).
                  
    
                      The draft does not require that the resource exist
                  (e.g. for
                  
    
                      unconfigured or new user based resources). It only
                  requires
                  
    
                      that the AS service provider agrees it can issue
                  tokens.
                  
    
                      From a security perspective, returning the OAuth
                  service
                  
    
                      configuration for a specified resource URI serves
                  to confirm
                  
    
                      the client is in possession of a valid resource
                  URI ensuring
                  
    
                      the client has received a valid set of endpoints
                  for the
                  
    
                      resource and the associated oauth services.
                  
    
                      I propose that the WG consider the alternate draft
                  carefully
                  
    
                      as well as other submissions and evaluate the
                  broader
                  
    
                      discovery problem before proceeding with WGLC on
                  OAuth Discovery.
                  
    
                      Thanks!
                  
    
                      Phil
                  
    
                      @independentid
                  
    
                      www.independentid.com
                  <http://www.independentid.com/>
                  
    
                      phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                          Begin forwarded message:
                  
    
                          *From:*internet-drafts@ietf.org
                  
    
                          <mailto:internet-drafts@ietf.org>
                  
    
                          *Subject: New Version Notification for
                  
    
                          draft-hunt-oauth-bound-config-00.txt*
                  
    
                          *Date:*March 13, 2016 at 3:53:37 PM PDT
                  
    
                          *To:*"Phil Hunt" <phil.hunt@yahoo.com
                  
    
                          <mailto:phil.hunt@yahoo.com>>,
                  "Anthony Nadalin"
                  
    
                          <tonynad@microsoft.com
                  <mailto:tonynad@microsoft.com>>,
                  
    
                          "Tony Nadalin" <tonynad@microsoft.com
                  
    
                          <mailto:tonynad@microsoft.com>>
                  
    
                  
    
                  
    
                          A new version of I-D,
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                          has been successfully submitted by Phil Hunt
                  and posted to the
                  
    
                          IETF repository.
                  
    
                  
    
                          Name:draft-hunt-oauth-bound-config
                  
    
                          Revision:00
                  
    
                          Title:OAuth 2.0 Bound Configuration Lookup
                  
    
                          Document date:2016-03-13
                  
    
                          Group:Individual Submission
                  
    
                          Pages:22
                  
    
                          URL:
                  
    
                         
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                          Status:
                  
    
                         
                  https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                  
    
                          Htmlized:
                  
    
                         
                  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                  
    
                  
    
                  
    
                          Abstract:
                  
    
                            This specification defines a mechanism for
                  the client of
                  
    
                          an OAuth 2.0
                  
    
                            protected resource service to obtain the
                  configuration
                  
    
                          details of an
                  
    
                            OAuth 2.0 authorization server that is
                  capable of
                  
    
                          authorizing access
                  
    
                            to a specific resource service.  The
                  information
                  
    
                          includes the OAuth
                  
    
                            2.0 component endpoint location URIs and as
                  well as
                  
    
                          authorization
                  
    
                            server capabilities.
                  
    
                  
    
                  
    
                  
    
                  
    
                          Please note that it may take a couple of
                  minutes from the
                  
    
                          time of submission
                  
    
                          until the htmlized version and diff are
                  available
                  
    
                          attools.ietf.org
                  <http://tools.ietf.org/>.
                  
    
                  
    
                          The IETF Secretariat
                  
    
                  
    
                      _______________________________________________
                  
    
                      OAuth mailing list
                  
    
                      OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                      https://www.ietf.org/mailman/listinfo/oauth
                  
    
                
    
                
    
              
    
              
    
            
    
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.org <mailto:OAuth@ietf.org>
          
    
          https://www.ietf.org/mailman/listinfo/oauth
          
    
        
    
        
    
        
    
        
    
        _______________________________________________
        
    
        OAuth mailing list
        
    
        OAuth@ietf.org
        
    
        https://www.ietf.org/mailman/listinfo/oauth
        
    
        
    
      
    
      
    
    
    
    
    
  


--------------050403030902090000060600--


From nobody Tue Mar 15 08:37:46 2016
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 504B712DB21 for ; Tue, 15 Mar 2016 08:37:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 zY8jv8mzgEDp for ; Tue, 15 Mar 2016 08:37:35 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 6091E12DAF5 for ; Tue, 15 Mar 2016 08:37:16 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id w104so17537691qge.1 for ; Tue, 15 Mar 2016 08:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=3iu2hevN3ls2V442OZ4Gfk8T12PZ9uGK4qwyh2QXt3k=; b=drj+hxSHWTI2E6DTp/RDV3DD/Q3+fGCQVBUjBXE3v28cCdJgZT0VKWZ6iMX/YKirV4 XcNpEVj8WozUaWVs8MELH/YXuwybnUW6tdO2Q+ccSY7i3f1pfmC0dNGg0WwxA2EP6KO9 /xAF1/zadQKlp26cwyoMiFahHK/ZEwFgBTwPYy09Z+T2p1/JPo8Uz9McIKNBQRVJ2Xu9 YYEkvQEChfG+bINGu6F8YfEAdywyRlOmJmhzK7cd9JQVfYvq4uJSmSK2CI82FXbqTVuO 7gxAWt9Qqi9ZS0NGoOUb9rPn3Q0PqT4yZCQuAq3uD0by/G0boW5UoVxlANaSqfKARO1+ CKKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3iu2hevN3ls2V442OZ4Gfk8T12PZ9uGK4qwyh2QXt3k=; b=IZ7nLJ4ng6vG56+4sY8JV5dMD6E0dYCnnOrumdFhm++5JUxEWrvh8eJ2F2cMLqO6R4 GO276N71G75C5HDjlYGnMIHLXEtGOtBijoZQn4fMAaMAWftChU0f5hbLFKIdQ4b/UCFx th7LNtIBnuESrwnEdPYe8XIeBjPMOY54taT+4cN0rA5nGKx3PisnW+BeXMrkzIFcCUcm aoQ7p2IPztGEMtUHy6AGEyobZ9g21dWYbi+82xuuSY1DRSM7Vmg6x16MAdHl/33+LEd+ u+ciQIozklCFG/fZIuCAVlrHY9n1z9jcWzWJnsYALA1I4ioY3zREfuSdDGrOR5Ul3Ubj Y8qA==
X-Gm-Message-State: AD7BkJLpJr1K5gMTkCmCwuAY5hyVA7pSMNNpxyNRhl10NvDI9MUqrKs0hYuM/9qsLpnfxg==
X-Received: by 10.140.91.245 with SMTP id z108mr37820795qgd.99.1458056235304;  Tue, 15 Mar 2016 08:37:15 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.44.172]) by smtp.gmail.com with ESMTPSA id u102sm12903226qge.27.2016.03.15.08.37.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 08:37:14 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_096A2006-179D-4CF7-A7A6-700DE52499AB"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56E825B9.6090400@aol.com>
Date: Tue, 15 Mar 2016 12:37:06 -0300
Message-Id: <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 15:37:45 -0000

--Apple-Mail=_096A2006-179D-4CF7-A7A6-700DE52499AB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_92077476-4E5A-4704-A47F-A837F8A076E1"


--Apple-Mail=_92077476-4E5A-4704-A47F-A837F8A076E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes,  I think bearer tokens with no audience are a bad idea.

The AS needs to infer an audience from the scopes snd/or have the client =
specify the desired audience.

If the AT has a audience or audiences then as long as the endpoint URI =
are provided as meta-data with the token, the client can determine if it =
is sending the token to the correct place.

I think Phil would prefer the server rather than the client do the =
check, but the client always needs to take some responsibility to not =
leak tokens giving them to the wrong RS or the code to the wrong token =
endpoint is leaking.

I imagine that claims based access tokens are going to become more =
popular and the static relationship between one RS and one AS will not =
be the majority of deployments over time.=20

In any case where the client is configured up front to know the RS and =
the AS it seems like that would not require Phil=E2=80=99s Solution, but =
that is the only case supported by that discovery.
 =20
If the client itself is bad there is not much you can do to stop it from =
passing on the AT in way way it wants.  That however is a different =
problem and needs claimed URI or attestations to prevent client =
spoofing.
William and I are working on that in the mobile best practices draft.

John B.


> On Mar 15, 2016, at 12:09 PM, George Fletcher  =
wrote:
>=20
> I worry about two directions I see in this thread...
>=20
> 1. Client's accessing resources dynamically so that discovery is =
required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>=20
> 2. Creating a tight coupling between RS and AS such that RS endpoint =
changes must be continually communicated to the AS. If an RS supports =
multiple AS's then the RS has to deal with "guaranteed" delivery. The AS =
needs an endpoint to receive such communications. If not dynamic via =
APIs, then deployment of the new RS is bound by the associated AS's =
getting and deploying the new endpoints. Can both endpoints of the RS be =
supported within the AS for some period of time, etc. This is an =
operation nightmare and almost assuredly going to go wrong in =
production.
>=20
> Maybe an OAuth2 "audience binding" spec is what's needed for those =
deployments that require this. I believe that is what John Bradley is =
suggesting.
>=20
> Thanks,
> George
>=20
> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>> +1, I've found the very same in OAuth deployments that I was involved =
in; the hard part is to give names and descriptions to these concepts so =
that they cover all use cases and can be applied unambiguously=20
>>=20
>> Hans.=20
>>=20
>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>> I agree that this is valuable, and not just for PoP. In all honesty,=20=

>>> it=E2=80=99s not even really required for PoP to function in many =
cases =E2=80=94 it=E2=80=99s=20
>>> just an optimization for one particular kind of key distribution=20
>>> mechanism in that case.=20
>>>=20
>>> In the years of deployment experience with OAuth 2, I think we=E2=80=99=
ve really=20
>>> got three different kinds of things that currently get folded into=20=

>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:=20
>>>=20
>>>=20
>>>   - What things do I want to access? (photos, profile)=20
>>>   - What actions do I want to take on these things? (read, write, =
delete)=20
>>>   - How long do I want these tokens to work?=20
>>> (offline_access/refresh_token, one time use, next hour, etc)=20
>>>=20
>>>=20
>>> I think the first one is close to the audience/resource parameters =
that=20
>>> have been bandied about a few times, including in the current token=20=

>>> exchange document. We should be consistent across drafts in that =
regard.=20
>>> The second is more traditional scope-ish. The third has been patched =
in=20
>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.=20=

>>>=20
>>> Just another vector to think about if we=E2=80=99re going to be =
adding things=20
>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.=20
>>>=20
>>>   =E2=80=94 Justin=20
>>>=20
>>>=20
>>>> On Mar 14, 2016, at 6:26 PM, John Bradley =20
>>>>  > wrote:=20
>>>>=20
>>>> Yes I will work on another proposal for allowing clients to specify=20=

>>>> what resource they want a token for and providing the meta-data to =
the=20
>>>> client about the resources that a token is valid for.=20
>>>>=20
>>>> We have part of it in the POP key distribution spec and talked =
about=20
>>>> separating it, as it is used more places than just for assigning =
keys.=20
>>>> I know some AS use different token formats for different RS so are=20=

>>>> all-ready needing to pass the resource in the request to avoid =
making=20
>>>> a mess of scopes.=20
>>>>=20
>>>> John B.=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) =20
>>>>>  > =
wrote:=20
>>>>>=20
>>>>> Inline=20
>>>>>=20
>>>>> Phil=20
>>>>>=20
>>>>> On Mar 14, 2016, at 14:13, John Bradley =20
>>>>>  > wrote:=20
>>>>>=20
>>>>>> We had two mandates.  One was to provide a spec for AS metadata.=20=

>>>>>> The other was to mitigate the client mixup attack.  The request =
was=20
>>>>>> to do the latter without requiring the former for clients that =
don=E2=80=99t=20
>>>>>> otherwise need discovery.=20
>>>>> There is no mandate for any of this. See=20
>>>>> =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =
=20
>>>>>>=20
>>>>>> Returning the issuer and client_id from the authorization =
endpoint=20
>>>>>> and the client checking them can be done by the client without=20
>>>>>> discovery.=20
>>>>>=20
>>>>> How does this address the issue of whether the client is talking =
to=20
>>>>> the wrong endpoint?=20
>>>>>>=20
>>>>>> Any client that has the resource and issuer hard coded probably=20=

>>>>>> doesn=E2=80=99t need discovery.=20
>>>>> We agree=20
>>>>>=20
>>>>>=20
>>>>>> One of the things that a client will need discovery for is to =
find=20
>>>>>> the RS, so requiring the client to know the RS URI before getting=20=

>>>>>> the AS config seems backwards to me.=20
>>>>> How can you make an assumption on order? You seem to be conflating=20=

>>>>> authentication with authorization by assuming the identity drives=20=

>>>>> what the resource is.=20
>>>>>=20
>>>>> There are lots of applications that require user rights but are =
not=20
>>>>> identify centric. For example a document service.=20
>>>>>>=20
>>>>>> Unless the client tells the AS where it intends to use the token =
we=20
>>>>>> will be leaving a security hole because the bearer tokens will =
have=20
>>>>>> too loose an audience if they have one at all.=20
>>>>> This is the biggest risk we have IMHO.=20
>>>>>>=20
>>>>>> True you are telling the AS (Webfinger service) what the RS is =
but=20
>>>>>> that is not at a place that is useful in the token production =
process.=20
>>>>>=20
>>>>> This has nothing to do with token production.=20
>>>>>=20
>>>>> What we want to ensure is whether an honest client is correctly=20
>>>>> configured and has not been mislead - eg by a phishing page.=20
>>>>>>=20
>>>>>> I also think there are use cases where the AS doesn=E2=80=99t =
know all the=20
>>>>>> possible RS.   That is not something that a out of band check can=20=

>>>>>> address.=20
>>>>>=20
>>>>> May be. Lets identify them.=20
>>>>>=20
>>>>>> There are also cases where a token might be good at multiple RS=20=

>>>>>> endpoints intentionally.=20
>>>>>=20
>>>>>>  In your solution the client would need to make a discovery =
request=20
>>>>>> for each endpoint.=20
>>>>> Sure. Otherwise how would it know if there is one AS or a pool of =
AS=20
>>>>> servers assigned to each instance?=20
>>>>>> Those requests lack the context of who the client and resource =
owner=20
>>>>>> are.  I think that will be a problem in some use cases.=20
>>>>>=20
>>>>> Not sure I agree. This is about discovering a valid set of =
endpoints.=20
>>>>> For mitm, we mainly want to check the hostname is correct. If a=20
>>>>> client chooses evil.com   the =
cert can be valid and=20
>>>>> TLS will pass. How does it otherwise know it is supposed to talk =
to=20
>>>>> res.example.com  =
?=20
>>>>>>=20
>>>>>> If this is added to the token endpoint it would be checked when =
code=20
>>>>>> or refresh are exchanged, not every time the token is used.=20
>>>>> Your proposal requires rhe client to check. I am not clear how the =
AS=20
>>>>> can know the exact uri. It is far easier to validate than to =
lookup=20
>>>>> since as you say the client may be authorized to use multiple ASs.=20=

>>>>>> With a out of band check the client would never know if a RS was=20=

>>>>>> removed/revoked.=20
>>>>>=20
>>>>> Not sure that is in scope.=20
>>>>>=20
>>>>> None of the current proposals address this issue.=20
>>>>>>=20
>>>>>> I don=E2=80=99t see checking when refreshing a token as something =
that is a=20
>>>>>> huge burden.=20
>>>>>=20
>>>>> Still its a lot more than once.=20
>>>>>=20
>>>>> Why don't you draft another alternative?=20
>>>>>>=20
>>>>>> If the server wants to do the check on it=E2=80=99s side then we =
could=20
>>>>>> require the client to send the RS URI in the token request. that =
way=20
>>>>>> you really know the client is not going to get a token for the =
wrong=20
>>>>>> RS endpoint.=20
>>>>>> If you check out of band in discovery you really have no idea if =
the=20
>>>>>> client is checking.=20
>>>>>=20
>>>>> In the new webfinger draft, the client isn't checking. The service=20=

>>>>> provider simply does not disclose oauth information to =
misconfigured=20
>>>>> clients.=20
>>>>>>=20
>>>>>> John B.=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt =20
>>>>>>>  > =
wrote:=20
>>>>>>>=20
>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take =
each in turn:=20
>>>>>>>=20
>>>>>>> Mike,=20
>>>>>>>=20
>>>>>>> Regarding your suggested amendments=20
>>>>>>>=20
>>>>>>> Item 1: Returning the config URL would create two problems. =
One,it=20
>>>>>>> makes bound discovery a two-step process - that adds complexity.=20=

>>>>>>>  It seems far simpler to mandate TLS (which I think it already =
does=20
>>>>>>> in the security considerations).=20
>>>>>>>=20
>>>>>>> The two-step process allows the current discovery process to=20
>>>>>>> continue. I disagree with this. This is why I put forward an=20
>>>>>>> =E2=80=9Calternate" draft that is almost the same but simply =
adds the check=20
>>>>>>> before returning the configuration data.  I worry that  =
developers=20
>>>>>>> would have no incentive to do the two-step approach. They would=20=

>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at risk of =
exposing=20
>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>=20
>>>>>>> Regarding existing implementations. Most of those =
implementations=20
>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use =
of=20
>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well =
defined=20
>>>>>>> and the likelihood of a client mis-informed about the resource=20=

>>>>>>> endpoint is not there.  IMO This does not apply to the broader=20=

>>>>>>> OAuth community.=20
>>>>>>>=20
>>>>>>> Item 2:  It may be appropriate to have a separate configuration=20=

>>>>>>> registry specification, but I think we should hold off until we=20=

>>>>>>> have a complete solution and then make the decision what drafts=20=

>>>>>>> should exist and how many pieces.  A big concern is the =
perceived=20
>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>=20
>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>=20
>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a =
security threat=20
>>>>>>> by having a discovery specification to prevent clients being=20
>>>>>>> mis-lead about endpoints (of which resource service is one) in =
an=20
>>>>>>> oauth protected exchange.  Maybe what you mean is we should not =
use=20
>>>>>>> .well-known of any kind and we should just create a =
=E2=80=9C/Config=E2=80=9D=20
>>>>>>> endpoint to OAuth?=20
>>>>>>>=20
>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>> You propose that instead the resource endpoint check should be =
in=20
>>>>>>> the oauth protocol itself.  The difference is that validation is=20=

>>>>>>> transferred back to the client to get it right. As well, without=20=

>>>>>>> the client informing the AS, I can=E2=80=99t see a way for the =
AS to know=20
>>>>>>> what endpoint the client is using.  The webfinger approach does=20=

>>>>>>> this once and only requires that the host name be checked in =
many=20
>>>>>>> cases.=20
>>>>>>>=20
>>>>>>> As a principle, the members have discussed many times that the =
AS=20
>>>>>>> service should do validation when possible =E2=80=94 this was =
particularly=20
>>>>>>> true at the Germany meeting when this came up. This is why I =
prefer=20
>>>>>>> the client tell the service provider what it intends to do and =
the=20
>>>>>>> service provider can fail that request immediately if necessary. =
We=20
>>>>>>> don=E2=80=99t have to depend on the developer getting the spec =
correct to=20
>>>>>>> fail the correct way.=20
>>>>>>>=20
>>>>>>> I worry that adding more parameters to the authz and token =
protocol=20
>>>>>>> flows increases complexity and attack surface. It also means per=20=

>>>>>>> authorization validation has to take place vs. a one-time=20
>>>>>>> validation at config time.  Placing it in the configuration =
lookup=20
>>>>>>> phase (whether via web finger or just a special OAuth endpoint)=20=

>>>>>>> seems more appropriate and far less complex - as the request =
itself=20
>>>>>>> is simple and has only one parameter. Here we are not considered=20=

>>>>>>> about legitimacy of the client. we=E2=80=99re just concerned =
with the issue=20
>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>=20
>>>>>>> That said, it may be that when we consider all the use cases, =
some=20
>>>>>>> combination of AS protocol and discovery may be both needed. =
I=E2=80=99m=20
>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>> oauth-discovery spec seems to put future generic clients at risk=20=

>>>>>>> and that is my primary concern.=20
>>>>>>>=20
>>>>>>> Best Regards,=20
>>>>>>>=20
>>>>>>> Phil=20
>>>>>>>=20
>>>>>>> @independentid=20
>>>>>>> www.independentid.com  =
 =20
>>>>>>> phil.hunt@oracle.com  =
 =20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>  =
 =
>=20
>>>>>>>> wrote:=20
>>>>>>>>=20
>>>>>>>> Thanks for posting this, Phil.  It provides a concrete example =
of=20
>>>>>>>> a way that protected resource discovery could be added to=20
>>>>>>>> authorization server metadata discovery, and as such, should=20
>>>>>>>> provide useful input for working group discussions on this =
topic.=20
>>>>>>>> It=E2=80=99s always great when someone takes the time to write =
an actual=20
>>>>>>>> draft that can be examined and implemented, and I appreciate =
you=20
>>>>>>>> doing that.=20
>>>>>>>> The content of your draft points out that there appears to be=20=

>>>>>>>> complete agreement on what the authorization server metadata=20
>>>>>>>> format should be, which is great!  I=E2=80=99ll note that =
Section 3 of=20
>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization =
Server=20
>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo=20
>>>>>>>> applying a correction suggested by the working group.  To me =
this=20
>>>>>>>> suggests that the authorization server metadata definitions in=20=

>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative=20
>>>>>>>> content of the draft) are clearly ready for standardization, =
since=20
>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>> Reading your draft, the problem I have with it is that you are=20=

>>>>>>>> returning the AS metadata only as a WebFinger response, rather=20=

>>>>>>>> than as an https-protected resource published by the =
authorization=20
>>>>>>>> server.  The choice to only return this via WebFinger makes =
your=20
>>>>>>>> draft incompatible with most deployed implementations of OAuth=20=

>>>>>>>> metadata, including the 22 implementations using it listed=20
>>>>>>>> athttp://openid.net/certification/(see the =E2=80=9COP =
Config=E2=80=9D column in=20
>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D=20
>>>>>>>> library, which uses the metadata path for client configuration.=20=

>>>>>>>> Without having ASs provide the metadata as an https-protected=20=

>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use it for =
client=20
>>>>>>>> configuration as the currently do.=20
>>>>>>>> Therefore, I would request that you make these minor revisions =
to=20
>>>>>>>> your draft and republish, so as to provide a unified way =
forward=20
>>>>>>>> that is compatible with all known existing OAuth Discovery=20
>>>>>>>> deployments:=20
>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server WebFinger =
Discovery=E2=80=9D=20
>>>>>>>> to have the WebFinger request return the issuer identifier for =
the=20
>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, =
rather than returning the=20
>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D =
value.=20
>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in =
your=20
>>>>>>>> Section 3.=20
>>>>>>>> That would have the advantage of paring your draft down to only=20=

>>>>>>>> the new things that it proposes, enabling them to be more =
clearly=20
>>>>>>>> understood and evaluated on their own merits.  I look forward =
to=20
>>>>>>>> the discussions of ways of performing additional kinds of OAuth=20=

>>>>>>>> discovery, and consider your draft a valuable input to those=20
>>>>>>>> discussions.=20
>>>>>>>>                                                           Best =
wishes,=20
>>>>>>>>                                                           -- =
Mike=20
>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org =
]*On Behalf Of*John Bradley=20
>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>> *To:*Phil Hunt   =
>=20
>>>>>>>> *Cc:*oauth  =
 >=20
>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>> As I have told Phil off list.=20
>>>>>>>> Discovery is the wrong place to try and provide security =
against=20
>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>> This requires the client to know what the RS URI is before=20
>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>> The proposal Mike and I have been working on requires the =
client=20
>>>>>>>> to have a notion of what API it is looking for and retrieve the=20=

>>>>>>>> .well-known file for that API from the issuer.   That allows a=20=

>>>>>>>> protocol like Connect to register its own config file that can=20=

>>>>>>>> point to the RS.=20
>>>>>>>> If the API specific well known is not available the client can =
try=20
>>>>>>>> the default oauth-server one.=20
>>>>>>>> That then allows us to deal with restricting where AT are=20
>>>>>>>> presented as part of the protocol rather then dragging =
discovery=20
>>>>>>>> in as a requirement.=20
>>>>>>>> In my opinion the resource the token is targeted to should be=20=

>>>>>>>> separated from the scope and returned as part of the meta-data=20=

>>>>>>>> about the AT along with scopes granted and expiry time.   We=20
>>>>>>>> should also have a input parameter for resources so that a =
client=20
>>>>>>>> can restrict tokens issued to a subset of the ones granted by =
the=20
>>>>>>>> refresh token.   It would then also be possible to ask a AS for =
a=20
>>>>>>>> token for a unregistered RS and have the AS produce a JWT =
access=20
>>>>>>>> token with the resource as an audience if policy allows.=20
>>>>>>>> That however was supposed to be dealt with as part of the mixed =
up=20
>>>>>>>> client set of mitigations.=20
>>>>>>>> In that the goal was to mitigate the attacks by returning=20
>>>>>>>> meta-data about the tokens, and not to require discovery.=20
>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=
=80=9D for the code, and I=20
>>>>>>>> intend to discuss at the F2F returning resource for AT as well.=20=

>>>>>>>> Those mitigate the attack.=20
>>>>>>>> I will continue to resist mixing up discovery of configuration=20=

>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>> We return meta-data about the tokens now, because AT are opaque =
to=20
>>>>>>>> the client, we neglected to include some of the information for=20=

>>>>>>>> the client needs to be secure.   We just need to add that in to=20=

>>>>>>>> the existing flows.=20
>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS to implement =
as an add=20
>>>>>>>> on, it puts more of a burden on the client needing to =
potentially=20
>>>>>>>> change how it stores the relationships between AS and RS to=20
>>>>>>>> prevent compromise, I think the solution should be biased =
towards=20
>>>>>>>> simplicity on the client side.=20
>>>>>>>> If we return the resources as part of the existing meta data =
the=20
>>>>>>>> client checks that against the resource it intends to send the=20=

>>>>>>>> token to and if it is not in the list then it can=E2=80=99t =
send the=20
>>>>>>>> token.  Simple check every time it gets a new AT, no =
optionality.=20
>>>>>>>> I am not saying anything new Nat has been advocating basically=20=

>>>>>>>> this for some time, and dis submit a draft.   I prefer to =
return=20
>>>>>>>> the info in the existing format rather than as link headers,  =
but=20
>>>>>>>> that is the largest difference between what Nat and I are =
saying=20
>>>>>>>> with respect to resource.=20
>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20
>>>>>>>> I guess we will need to have a long conversation in BA.=20
>>>>>>>> Regards=20
>>>>>>>> John B.=20
>>>>>>>>=20
>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt =
=20
>>>>>>>>      =
> wrote:=20
>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same=20=

>>>>>>>>     registry for OAuth Config Metadata as the authors believe =
that=20
>>>>>>>>     both solutions are not required, or depending on WG =
discussion=20
>>>>>>>>     they will be merged. The intent is to provide a simple=20
>>>>>>>>     complete draft for consideration.=20
>>>>>>>>     How it works...=20
>>>>>>>>     Given that a client has previously discovered an OAuth=20
>>>>>>>>     protected resource, the bound configuration method allows a=20=

>>>>>>>>     client to return the configuration for an oauth =
authorization=20
>>>>>>>>     server that can issue tokens for the resource URI specified =
by=20
>>>>>>>>     the client.  The AS is not required to be in the same =
domain.=20
>>>>>>>>      The AS is however required to know if it can issue tokens =
for=20
>>>>>>>>     a resource service (which presumes some agreement exists on=20=

>>>>>>>>     tokens etc).=20
>>>>>>>>     The draft does not require that the resource exist (e.g. =
for=20
>>>>>>>>     unconfigured or new user based resources). It only requires=20=

>>>>>>>>     that the AS service provider agrees it can issue tokens.=20
>>>>>>>>     =46rom a security perspective, returning the OAuth service=20=

>>>>>>>>     configuration for a specified resource URI serves to =
confirm=20
>>>>>>>>     the client is in possession of a valid resource URI =
ensuring=20
>>>>>>>>     the client has received a valid set of endpoints for the=20
>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>     I propose that the WG consider the alternate draft =
carefully=20
>>>>>>>>     as well as other submissions and evaluate the broader=20
>>>>>>>>     discovery problem before proceeding with WGLC on OAuth =
Discovery.=20
>>>>>>>>     Thanks!=20
>>>>>>>>     Phil=20
>>>>>>>>     @independentid=20
>>>>>>>>     www.independentid.com  =
 =20
>>>>>>>>     phil.hunt@oracle.com  =
 =20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         Begin forwarded message:=20
>>>>>>>>         *From:*internet-drafts@ietf.org=20
>>>>>>>>          =
=20
>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>         *To:*"Phil Hunt" =20
>>>>>>>>          =
>, "Anthony Nadalin"=20
>>>>>>>>          =
 >,=20
>>>>>>>>         "Tony Nadalin" =20
>>>>>>>>          =
>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>         has been successfully submitted by Phil Hunt and posted =
to the=20
>>>>>>>>         IETF repository.=20
>>>>>>>>=20
>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>         Revision:00=20
>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>         Group:Individual Submission=20
>>>>>>>>         Pages:22=20
>>>>>>>>         URL:=20
>>>>>>>>         =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>>>>>>         Status:=20
>>>>>>>>         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =
=20
>>>>>>>>         Htmlized:=20
>>>>>>>>         =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =
=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         Abstract:=20
>>>>>>>>           This specification defines a mechanism for the client =
of=20
>>>>>>>>         an OAuth 2.0=20
>>>>>>>>           protected resource service to obtain the =
configuration=20
>>>>>>>>         details of an=20
>>>>>>>>           OAuth 2.0 authorization server that is capable of=20
>>>>>>>>         authorizing access=20
>>>>>>>>           to a specific resource service.  The information=20
>>>>>>>>         includes the OAuth=20
>>>>>>>>           2.0 component endpoint location URIs and as well as=20=

>>>>>>>>         authorization=20
>>>>>>>>           server capabilities.=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         Please note that it may take a couple of minutes from =
the=20
>>>>>>>>         time of submission=20
>>>>>>>>         until the htmlized version and diff are available=20
>>>>>>>>         attools.ietf.org  =
.=20
>>>>>>>>=20
>>>>>>>>         The IETF Secretariat=20
>>>>>>>>=20
>>>>>>>>     _______________________________________________=20
>>>>>>>>     OAuth mailing list=20
>>>>>>>>     OAuth@ietf.org  =
 =20
>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>>>=20
>>>>>>=20
>>>>=20
>>>> _______________________________________________=20
>>>> OAuth mailing list=20
>>>> OAuth@ietf.org   =
=20
>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________=20
>>> OAuth mailing list=20
>>> OAuth@ietf.org =20
>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>=20
>>=20
>=20


--Apple-Mail=_92077476-4E5A-4704-A47F-A837F8A076E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes,  I think bearer tokens with no audience are a bad =
idea.

    The AS needs =
to infer an audience from the scopes snd/or have the client specify the =
desired audience.

    If the AT has a audience or audiences then as long as the =
endpoint URI are provided as meta-data with the token, the client can =
determine if it is sending the token to the correct place.

    I think Phil would =
prefer the server rather than the client do the check, but the client =
always needs to take some responsibility to not leak tokens giving them =
to the wrong RS or the code to the wrong token endpoint is =
leaking.

    I =
imagine that claims based access tokens are going to become more popular =
and the static relationship between one RS and one AS will not be the =
majority of deployments over time. 

    In any case where the client is =
configured up front to know the RS and the AS it seems like that would =
not require Phil=E2=80=99s Solution, but that is the only case supported =
by that discovery.
      
    If the client itself is bad there is not much you can do to =
stop it from passing on the AT in way way it wants.  That however =
is a different problem and needs claimed URI or attestations to prevent =
client spoofing.
    William and I are working on that =
in the mobile best practices draft.

    John B.


    On Mar 15, 2016, at 12:09 PM, =
George Fletcher <gffletch@aol.com> wrote:

    
 =20
    
 =20
  
    
    I worry about =
two
      directions I see in this thread...
    
      
    
      1. Client's accessing resources dynamically so that discovery is
      required to know the correct AS, etc. This is pretty much the
      classic use case for UMA and I'd rather not re-invent the =
wheel.
    
      
    
      2. Creating a tight coupling between RS and AS such that RS
      endpoint changes must be continually communicated to the AS. If an
      RS supports multiple AS's then the RS has to deal with
      "guaranteed" delivery. The AS needs an endpoint to receive such
      communications. If not dynamic via APIs, then deployment of the
      new RS is bound by the associated AS's getting and deploying the
      new endpoints. Can both endpoints of the RS be supported within
      the AS for some period of time, etc. This is an operation
      nightmare and almost assuredly going to go wrong in production.
    
      
    
      Maybe an OAuth2 "audience binding" spec is what's needed for those
      deployments that require this. I believe that is what John Bradley
      is suggesting.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/14/16 7:29 PM, Hans Zandbelt
      wrote:
    
    
    
    
    +1,
      I've found the very same in OAuth deployments that I was involved
      in; the hard part is to give names and descriptions to these
      concepts so that they cover all use cases and can be applied
      unambiguously
      
    
      
    
      Hans.
      
    
      
    
      On 3/14/16 10:44 PM, Justin Richer wrote:
      
    
      
    I agree that this is =
valuable, and not
        just for PoP. In all honesty,
        
    
        it=E2=80=99s not even really required for PoP to function in =
many cases
        =E2=80=94 it=E2=80=99s
        
    
        just an optimization for one particular kind of key distribution
        
    
        mechanism in that case.
        
    
        
    
        In the years of deployment experience with OAuth 2, I think
        we=E2=80=99ve really
        
    
        got three different kinds of things that currently get folded
        into
        
    
        =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:
        
    
        
    
        
    
          - What things do I want to access? (photos, profile)
        
    
          - What actions do I want to take on these things? (read,
        write, delete)
        
    
          - How long do I want these tokens to work?
        
    
        (offline_access/refresh_token, one time use, next hour, etc)
        
    
        
    
        
    
        I think the first one is close to the audience/resource
        parameters that
        
    
        have been bandied about a few times, including in the current
        token
        
    
        exchange document. We should be consistent across drafts in that
        regard.
        
    
        The second is more traditional scope-ish. The third has been
        patched in
        
    
        with things like =E2=80=9Coffline_access=E2=80=9D in certain =
APIs.
        
    
        
    
        Just another vector to think about if we=E2=80=99re going to be =
adding
        things
        
    
        like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.
        
    
        
    
          =E2=80=94 Justin
        
    
        
    
        
    
        
    On Mar 14, 2016, at 6:26 =
PM, John
          Bradley <ve7jtb@ve7jtb.com
          
    
          <mailto:ve7jtb@ve7jtb.com>>=
 wrote:
          
    
          
    
          Yes I will work on another proposal for allowing clients to
          specify
          
    
          what resource they want a token for and providing the
          meta-data to the
          
    
          client about the resources that a token is valid for.
          
    
          
    
          We have part of it in the POP key distribution spec and talked
          about
          
    
          separating it, as it is used more places than just for
          assigning keys.
          
    
          I know some AS use different token formats for different RS so
          are
          
    
          all-ready needing to pass the resource in the request to avoid
          making
          
    
          a mess of scopes.
          
    
          
    
          John B.
          
    
          
    
          
    
          
    
          
    
          
    
          
    On Mar 14, 2016, at 7:17 =
PM, Phil Hunt
            (IDM) <phil.hunt@oracle.com
            
    
            <mailto:phil.hunt@oracle.com>> wrote:
            
    
            
    
            Inline
            
    
            
    
            Phil
            
    
            
    
            On Mar 14, 2016, at 14:13, John Bradley
            <    ve7jtb@ve7jtb.com
            
    
            <mailto:ve7jtb@ve7jtb.com>>=
 wrote:
            
    
            
    
            
    We had two =
mandates.  One was to
              provide a spec for AS metadata.
              
    
              The other was to mitigate the client mixup attack.  =
The
              request was
              
    
              to do the latter without requiring the former for clients
              that don=E2=80=99t
              
    
              otherwise need discovery.
              
    
            
    
            There is no mandate for any of this. See
            
    
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt
            
    
            
    
              
    
              Returning the issuer and client_id from the authorization
              endpoint
              
    
              and the client checking them can be done by the client
              without
              
    
              discovery.
              
    
            
    
            
    
            How does this address the issue of whether the client is
            talking to
            
    
            the wrong endpoint?
            
    
            
    
              
    
              Any client that has the resource and issuer hard coded
              probably
              
    
              doesn=E2=80=99t need discovery.
              
    
            
    
            We agree
            
    
            
    
            
    
            
    One of the things that =
a client will
              need discovery for is to find
              
    
              the RS, so requiring the client to know the RS URI before
              getting
              
    
              the AS config seems backwards to me.
              
    
            
    
            How can you make an assumption on order? You seem to be
            conflating
            
    
            authentication with authorization by assuming the identity
            drives
            
    
            what the resource is.
            
    
            
    
            There are lots of applications that require user rights but
            are not
            
    
            identify centric. For example a document service.
            
    
            
    
              
    
              Unless the client tells the AS where it intends to use the
              token we
              
    
              will be leaving a security hole because the bearer tokens
              will have
              
    
              too loose an audience if they have one at all.
              
    
            
    
            This is the biggest risk we have IMHO.
            
    
            
    
              
    
              True you are telling the AS (Webfinger service) what the
              RS is but
              
    
              that is not at a place that is useful in the token
              production process.
              
    
            
    
            
    
            This has nothing to do with token production.
            
    
            
    
            What we want to ensure is whether an honest client is
            correctly
            
    
            configured and has not been mislead - eg by a phishing page.
            
    
            
    
              
    
              I also think there are use cases where the AS doesn=E2=80=99=
t know
              all the
              
    
              possible RS.   That is not something that a out =
of band
              check can
              
    
              address.
              
    
            
    
            
    
            May be. Lets identify them.
            
    
            
    
            
    There are also cases =
where a token
              might be good at multiple RS
              
    
              endpoints intentionally.
              
    
            
    
            
    
            
     In your solution =
the client would
              need to make a discovery request
              
    
              for each endpoint.
              
    
            
    
            Sure. Otherwise how would it know if there is one AS or a
            pool of AS
            
    
            servers assigned to each instance?
            
    
            
    Those requests lack the =
context of
              who the client and resource owner
              
    
              are.  I think that will be a problem in some use =
cases.
              
    
            
    
            
    
            Not sure I agree. This is about discovering a valid set of
            endpoints.
            
    
            For mitm, we mainly want to check the hostname is correct.
            If a
            
    
            client chooses evil.com <http://evil.com/> the cert
            can be valid and
            
    
            TLS will pass. How does it otherwise know it is supposed to
            talk to
            
    
            res.example.com <http://res.example.com/>?
            
    
            
    
              
    
              If this is added to the token endpoint it would be checked
              when code
              
    
              or refresh are exchanged, not every time the token is
              used.
              
    
            
    
            Your proposal requires rhe client to check. I am not clear
            how the AS
            
    
            can know the exact uri. It is far easier to validate than to
            lookup
            
    
            since as you say the client may be authorized to use
            multiple ASs.
            
    
            
    With a out of band =
check the client
              would never know if a RS was
              
    
              removed/revoked.
              
    
            
    
            
    
            Not sure that is in scope.
            
    
            
    
            None of the current proposals address this issue.
            
    
            
    
              
    
              I don=E2=80=99t see checking when refreshing a token as =
something
              that is a
              
    
              huge burden.
              
    
            
    
            
    
            Still its a lot more than once.
            
    
            
    
            Why don't you draft another alternative?
            
    
            
    
              
    
              If the server wants to do the check on it=E2=80=99s side =
then we
              could
              
    
              require the client to send the RS URI in the token
              request. that way
              
    
              you really know the client is not going to get a token for
              the wrong
              
    
              RS endpoint.
              
    
              If you check out of band in discovery you really have no
              idea if the
              
    
              client is checking.
              
    
            
    
            
    
            In the new webfinger draft, the client isn't checking. The
            service
            
    
            provider simply does not disclose oauth information to
            misconfigured
            
    
            clients.
            
    
            
    
              
    
              John B.
              
    
              
    
              
    
              
    On Mar 14, 2016, at =
3:56 PM, Phil
                Hunt <phil.hunt@oracle.com
                
    
                <mailto:phil.hunt@oracle.com>> wrote:
                
    
                
    
                Thanks to Mike and John for their feedback.  I=E2=80=99=
ll take
                each in turn:
                
    
                
    
                Mike,
                
    
                
    
                Regarding your suggested amendments
                
    
                
    
                Item 1: Returning the config URL would create two
                problems. One,it
                
    
                makes bound discovery a two-step process - that adds
                complexity.
                
    
                 It seems far simpler to mandate TLS (which I think =
it
                already does
                
    
                in the security considerations).
                
    
                
    
                The two-step process allows the current discovery
                process to
                
    
                continue. I disagree with this. This is why I put
                forward an
                
    
                =E2=80=9Calternate" draft that is almost the same but =
simply
                adds the check
                
    
                before returning the configuration data.  I worry =
that 
                developers
                
    
                would have no incentive to do the two-step approach.
                They would
                
    
                just start at step 2 which in turn puts AS=E2=80=99s at =
risk of
                exposing
                
    
                tokens because it works. This makes OAuth promiscuous.
                
    
                
    
                Regarding existing implementations. Most of those
                implementations
                
    
                are for OIDC.  I think it makes sense for OIDF to
                continue use of
                
    
                OIDC's discovery spec because the UserInfo endpoint is
                well defined
                
    
                and the likelihood of a client mis-informed about the
                resource
                
    
                endpoint is not there.  IMO This does not apply to =
the
                broader
                
    
                OAuth community.
                
    
                
    
                Item 2:  It may be appropriate to have a separate
                configuration
                
    
                registry specification, but I think we should hold off
                until we
                
    
                have a complete solution and then make the decision what
                drafts
                
    
                should exist and how many pieces.  A big concern is =
the
                perceived
                
    
                complexity of multiple solutions and multiple drafts.
                
    
                
    
                As to John Bradley=E2=80=99s comments:
                
    
                
    
                Re: Discovery is the wrong place to mitigate threats.
                
    
                I=E2=80=99m confused by this.  Our mandate was to =
solve a
                security threat
                
    
                by having a discovery specification to prevent clients
                being
                
    
                mis-lead about endpoints (of which resource service is
                one) in an
                
    
                oauth protected exchange.  Maybe what you mean is =
we
                should not use
                
    
                .well-known of any kind and we should just create a
                =E2=80=9C/Config=E2=80=9D
                
    
                endpoint to OAuth?
                
    
                
    
                Re: Your proposal for MITM mitigation
                
    
                You propose that instead the resource endpoint check
                should be in
                
    
                the oauth protocol itself.  The difference is that
                validation is
                
    
                transferred back to the client to get it right. As well,
                without
                
    
                the client informing the AS, I can=E2=80=99t see a way =
for the
                AS to know
                
    
                what endpoint the client is using.  The webfinger
                approach does
                
    
                this once and only requires that the host name be
                checked in many
                
    
                cases.
                
    
                
    
                As a principle, the members have discussed many times
                that the AS
                
    
                service should do validation when possible =E2=80=94 =
this was
                particularly
                
    
                true at the Germany meeting when this came up. This is
                why I prefer
                
    
                the client tell the service provider what it intends to
                do and the
                
    
                service provider can fail that request immediately if
                necessary. We
                
    
                don=E2=80=99t have to depend on the developer getting =
the spec
                correct to
                
    
                fail the correct way.
                
    
                
    
                I worry that adding more parameters to the authz and
                token protocol
                
    
                flows increases complexity and attack surface. It also
                means per
                
    
                authorization validation has to take place vs. a
                one-time
                
    
                validation at config time.  Placing it in the
                configuration lookup
                
    
                phase (whether via web finger or just a special OAuth
                endpoint)
                
    
                seems more appropriate and far less complex - as the
                request itself
                
    
                is simple and has only one parameter. Here we are not
                considered
                
    
                about legitimacy of the client. we=E2=80=99re just =
concerned
                with the issue
                
    
                "has the client been correctly informed?=E2=80=9D
                
    
                
    
                That said, it may be that when we consider all the use
                cases, some
                
    
                combination of AS protocol and discovery may be both
                needed. I=E2=80=99m
                
    
                not ready to make conclusions about this.  The =
current
                
    
                oauth-discovery spec seems to put future generic clients
                at risk
                
    
                and that is my primary concern.
                
    
                
    
                Best Regards,
                
    
                
    
                Phil
                
    
                
    
                @independentid
                
    
                    www.independentid.com
                <http://www.independentid.com/&g=
t;
                
    
                phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 13, 2016, at =
10:28 PM,
                  Mike Jones
                  
    
                  <    Michael.Jones@microsoft.com
                  <mailto:Michael.Jones@micro=
soft.com>>
                  
    
                  wrote:
                  
    
                  
    
                  Thanks for posting this, Phil.  It provides a =
concrete
                  example of
                  
    
                  a way that protected resource discovery could be added
                  to
                  
    
                  authorization server metadata discovery, and as such,
                  should
                  
    
                  provide useful input for working group discussions on
                  this topic.
                  
    
                  It=E2=80=99s always great when someone takes the time =
to write
                  an actual
                  
    
                  draft that can be examined and implemented, and I
                  appreciate you
                  
    
                  doing that.
                  
    
                  The content of your draft points out that there
                  appears to be
                  
    
                  complete agreement on what the authorization server
                  metadata
                  
    
                  format should be, which is great!  I=E2=80=99ll =
note that
                  Section 3 of
                  
    
                  draft-hunt-oauth-bound-config-00 titled =
=E2=80=9CAuthorization
                  Server
                  
    
                  Metadata=E2=80=9D is an exact copy of Section 2 of
                  
    
                  draft-ietf-oauth-discovery-01 (with the same title),
                  modulo
                  
    
                  applying a correction suggested by the working =
group. 
                  To me this
                  
    
                  suggests that the authorization server metadata
                  definitions in
                  
    
                  draft-ietf-oauth-discovery (which is now the whole
                  normative
                  
    
                  content of the draft) are clearly ready for
                  standardization, since
                  
    
                  even your alternative proposal includes them verbatim.
                  
    
                  Reading your draft, the problem I have with it is that
                  you are
                  
    
                  returning the AS metadata only as a WebFinger
                  response, rather
                  
    
                  than as an https-protected resource published by the
                  authorization
                  
    
                  server.  The choice to only return this via =
WebFinger
                  makes your
                  
    
                  draft incompatible with most deployed implementations
                  of OAuth
                  
    
                  metadata, including the 22 implementations using it
                  listed
                  
    
                  athttp://openid.net/certification/(see the =E2=80=9COP =
Config=E2=80=9D
                  column in
                  
    
                  the table) andOAuth 2.0 libraries such as =
Microsoft=E2=80=99s
                  =E2=80=9CADAL=E2=80=9D
                  
    
                  library, which uses the metadata path for client
                  configuration.
                  
    
                  Without having ASs provide the metadata as an
                  https-protected
                  
    
                  resource, implementations such as ADAL can=E2=80=99t =
use it
                  for client
                  
    
                  configuration as the currently do.
                  
    
                  Therefore, I would request that you make these minor
                  revisions to
                  
    
                  your draft and republish, so as to provide a unified
                  way forward
                  
    
                  that is compatible with all known existing OAuth
                  Discovery
                  
    
                  deployments:
                  
    
                  1.Modify your section 2 =E2=80=9CAuthorization Server
                  WebFinger Discovery=E2=80=9D
                  
    
                  to have the WebFinger request return the issuer
                  identifier for the
                  
    
                  AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D =
value, rather than
                  returning the
                  
    
                  metadata values by value as the =E2=80=9Cproperties=E2=80=
=9D value.
                  
    
                  2.Reference the metadata definitions from Section 2 of
                  
    
                  draft-ietf-oauth-discovery, rather than duplicating
                  them in your
                  
    
                  Section 3.
                  
    
                  That would have the advantage of paring your draft
                  down to only
                  
    
                  the new things that it proposes, enabling them to be
                  more clearly
                  
    
                  understood and evaluated on their own merits.  I =
look
                  forward to
                  
    
                  the discussions of ways of performing additional kinds
                  of OAuth
                  
    
                  discovery, and consider your draft a valuable input to
                  those
                  
    
                  discussions.
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  Best wishes,
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  -- Mike
                  
    
                  *From:*OAuth [mailto:oauth-bounces@ietf.org]*=
On Behalf
                  Of*John Bradley
                  
    
                  *Sent:*Sunday, March 13, 2016 6:45 PM
                  
    
                  *To:*Phil Hunt <phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>>
                  
    
                  *Cc:*oauth <    oauth@ietf.org
                  <mailto:oauth@ietf.org>>
                  
    
                  *Subject:*Re: [OAUTH-WG] New Version Notification for
                  
    
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  As I have told Phil off list.
                  
    
                  Discovery is the wrong place to try and provide
                  security against
                  
    
                  man in the middle attacks on the RS.
                  
    
                  This requires the client to know what the RS URI is
                  before
                  
    
                  retrieving the information on the AS Configuration.
                  
    
                  The proposal Mike and I have been working on requires
                  the client
                  
    
                  to have a notion of what API it is looking for and
                  retrieve the
                  
    
                  .well-known file for that API from the =
issuer.   That
                  allows a
                  
    
                  protocol like Connect to register its own config file
                  that can
                  
    
                  point to the RS.
                  
    
                  If the API specific well known is not available the
                  client can try
                  
    
                  the default oauth-server one.
                  
    
                  That then allows us to deal with restricting where AT
                  are
                  
    
                  presented as part of the protocol rather then dragging
                  discovery
                  
    
                  in as a requirement.
                  
    
                  In my opinion the resource the token is targeted to
                  should be
                  
    
                  separated from the scope and returned as part of the
                  meta-data
                  
    
                  about the AT along with scopes granted and expiry
                  time.   We
                  
    
                  should also have a input parameter for resources so
                  that a client
                  
    
                  can restrict tokens issued to a subset of the ones
                  granted by the
                  
    
                  refresh token.   It would then also be =
possible to ask
                  a AS for a
                  
    
                  token for a unregistered RS and have the AS produce a
                  JWT access
                  
    
                  token with the resource as an audience if policy
                  allows.
                  
    
                  That however was supposed to be dealt with as part of
                  the mixed up
                  
    
                  client set of mitigations.
                  
    
                  In that the goal was to mitigate the attacks by
                  returning
                  
    
                  meta-data about the tokens, and not to require
                  discovery.
                  
    
                  We intend to return =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Ccleint_id=E2=80=9D for the
                  code, and I
                  
    
                  intend to discuss at the F2F returning resource for AT
                  as well.
                  
    
                  Those mitigate the attack.
                  
    
                  I will continue to resist mixing up discovery of
                  configuration
                  
    
                  meta-data with mitigation of the attacks.
                  
    
                  We return meta-data about the tokens now, because AT
                  are opaque to
                  
    
                  the client, we neglected to include some of the
                  information for
                  
    
                  the client needs to be secure.   We just =
need to add
                  that in to
                  
    
                  the existing flows.
                  
    
                  While Phil=E2=80=99s proposal is easier for the AS to
                  implement as an add
                  
    
                  on, it puts more of a burden on the client needing to
                  potentially
                  
    
                  change how it stores the relationships between AS and
                  RS to
                  
    
                  prevent compromise, I think the solution should be
                  biased towards
                  
    
                  simplicity on the client side.
                  
    
                  If we return the resources as part of the existing
                  meta data the
                  
    
                  client checks that against the resource it intends to
                  send the
                  
    
                  token to and if it is not in the list then it can=E2=80=99=
t
                  send the
                  
    
                  token.  Simple check every time it gets a new AT, =
no
                  optionality.
                  
    
                  I am not saying anything new Nat has been advocating
                  basically
                  
    
                  this for some time, and dis submit a =
draft.   I prefer
                  to return
                  
    
                  the info in the existing format rather than as link
                  headers,  but
                  
    
                  that is the largest difference between what Nat and I
                  are saying
                  
    
                  with respect to resource.
                  
    
                  That is the core of my problem with Phil=E2=80=99s =
draft.
                  
    
                  I guess we will need to have a long conversation in
                  BA.
                  
    
                  Regards
                  
    
                  John B.
                  
    
                  
    
                      On Mar 13, 2016, at 8:12 PM, Phil =
Hunt
                  <phil.hunt@oracle.com
                  
    
                      <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                      This draft is a proposed alternate =
proposal for
                  
    
                      draft-ietf-oauth-discovery.  =
As such, it contains
                  the same
                  
    
                      registry for OAuth Config Metadata =
as the authors
                  believe that
                  
    
                      both solutions are not required, or =
depending on
                  WG discussion
                  
    
                      they will be merged. The intent is =
to provide a
                  simple
                  
    
                      complete draft for consideration.
                  
    
                      How it works...
                  
    
                      Given that a client has previously =
discovered an
                  OAuth
                  
    
                      protected resource, the bound =
configuration method
                  allows a
                  
    
                      client to return the configuration =
for an oauth
                  authorization
                  
    
                      server that can issue tokens for =
the resource URI
                  specified by
                  
    
                      the client.  The AS is not =
required to be in the
                  same domain.
                  
    
                       The AS is however required to =
know if it can
                  issue tokens for
                  
    
                      a resource service (which presumes =
some agreement
                  exists on
                  
    
                      tokens etc).
                  
    
                      The draft does not require that the =
resource exist
                  (e.g. for
                  
    
                      unconfigured or new user based =
resources). It only
                  requires
                  
    
                      that the AS service provider agrees =
it can issue
                  tokens.
                  
    
                      =46rom a security perspective, =
returning the OAuth
                  service
                  
    
                      configuration for a specified =
resource URI serves
                  to confirm
                  
    
                      the client is in possession of a =
valid resource
                  URI ensuring
                  
    
                      the client has received a valid set =
of endpoints
                  for the
                  
    
                      resource and the associated oauth =
services.
                  
    
                      I propose that the WG consider the =
alternate draft
                  carefully
                  
    
                      as well as other submissions and =
evaluate the
                  broader
                  
    
                      discovery problem before proceeding =
with WGLC on
                  OAuth Discovery.
                  
    
                      Thanks!
                  
    
                      Phil
                  
    
                      @independentid
                  
    
                          www.independentid.com
                  <http://www.independentid.com/&g=
t;
                  
    
                      phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                          Begin =
forwarded message:
                  
    
                          *From:*    internet-drafts@ietf.org
                  
    
                          <mailto:internet-drafts@ietf.o=
rg>
                  
    
                          *Subject: =
New Version Notification for
                  
    
                          =
draft-hunt-oauth-bound-config-00.txt*
                  
    
                          =
*Date:*March 13, 2016 at 3:53:37 PM PDT
                  
    
                          *To:*"Phil =
Hunt" <phil.hunt@yahoo.com
                  
    
                          <mailto:phil.hunt@yahoo.com>=
>,
                  "Anthony Nadalin"
                  
    
                          <tonynad@microsoft.com
                  <mailto:tonynad@microsoft.com>=
>,
                  
    
                          "Tony =
Nadalin" <tonynad@microsoft.com
                  
    
                          <mailto:tonynad@microsoft.com>=
>
                  
    
                  
    
                  
    
                          A new =
version of I-D,
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                          has been =
successfully submitted by Phil Hunt
                  and posted to the
                  
    
                          IETF =
repository.
                  
    
                  
    
                          =
Name:draft-hunt-oauth-bound-config
                  
    
                          Revision:00
                  
    
                          Title:OAuth =
2.0 Bound Configuration Lookup
                  
    
                          Document =
date:2016-03-13
                  
    
                          =
Group:Individual Submission
                  
    
                          Pages:22
                  
    
                          URL:
                  
    
                         
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-confi=
g-00.txt
    
                          Status:
                  
    
                         
                  h=
ttps://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                  
    
                          Htmlized:
                  
    
                         
                  http=
s://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                  
    
                  
    
                  
    
                          Abstract:
                  
    
                            =
This specification defines a mechanism for
                  the client of
                  
    
                          an OAuth =
2.0
                  
    
                            =
protected resource service to obtain the
                  configuration
                  
    
                          details of =
an
                  
    
                            =
OAuth 2.0 authorization server that is
                  capable of
                  
    
                          authorizing =
access
                  
    
                            =
to a specific resource service.  The
                  information
                  
    
                          includes =
the OAuth
                  
    
                            =
2.0 component endpoint location URIs and as
                  well as
                  
    
                          =
authorization
                  
    
                            =
server capabilities.
                  
    
                  
    
                  
    
                  
    
                  
    
                          Please note =
that it may take a couple of
                  minutes from the
                  
    
                          time of =
submission
                  
    
                          until the =
htmlized version and diff are
                  available
                  
    
                          attools.ietf.org
                  <http://tools.ietf.org/>.
                  
    
                  
    
                          The IETF =
Secretariat
                  
    
                  
    
                      =
_______________________________________________
                  
    
                      OAuth mailing list
                  
    
                      OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                      https://www.ietf.org/=
mailman/listinfo/oauth
                  
    
                
    
                
    
              
    
              
    
            
    
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.org <mailto:OAuth@ietf.org>
          
    
          https://www.ietf.org/=
mailman/listinfo/oauth
          
    
        
    
        
    
        
    
        
    
        _______________________________________________
        
    
        OAuth mailing list
        
    
        OAuth@ietf.org
        
    
        https://www.ietf.org/=
mailman/listinfo/oauth
        
    
        
    
      
    
      
    
    
    
    
    
  
    



    =

--Apple-Mail=_92077476-4E5A-4704-A47F-A837F8A076E1--

--Apple-Mail=_096A2006-179D-4CF7-A7A6-700DE52499AB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxNTM3MDZaMCMGCSqGSIb3DQEJBDEWBBReyX2QXcAmzOS8B4cawqOv
u8ergTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCGYLSCjXIz3W9Zsoi7PIM1RT8cL1wofdR8DxDBJm6Omb8GModFeFL+
M4bAgbSje0iXKqFofxZsUNOXMSsHLTylbwjJbhXEUqOKqeT0iaXzfVfHatQxD3vUiNFl2cYgM/OC
lPw49CN1CpJPVoNmNMxCQZzIeKLMG1oeNcKegMTexs0alXSWv/bkAr6P08p9q7pP7t0cTbphVWBX
OF8mAByuqLM3EFaTkdzEnSA1QY0ptmobv9eVaAM5LQm0tGXFiVzOPw6GLJ/803YOt+v5P2HK3nV8
8od29DJbwPDapI099e+zHZDXq5axkxv8vhGrc4y2/3tC9rKm0xgMXkpbiUEzAAAAAAAA
--Apple-Mail=_096A2006-179D-4CF7-A7A6-700DE52499AB--


From nobody Tue Mar 15 08:39:11 2016
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 0CEAE12DAE0 for ; Tue, 15 Mar 2016 08:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 pbBzu7jd0iwZ for ; Tue, 15 Mar 2016 08:39:08 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 71B3E12D8B7 for ; Tue, 15 Mar 2016 08:29:36 -0700 (PDT)
X-AuditID: 1209190d-9ebff70000003214-fc-56e82a5f3c25
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 12.0F.12820.F5A28E65; Tue, 15 Mar 2016 11:29:35 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u2FFTYF6024455; Tue, 15 Mar 2016 11:29:34 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2FFTWbp021924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Mar 2016 11:29:34 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <56E80B7B.2010801@gmail.com>
Date: Tue, 15 Mar 2016 11:29:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E805B8.5000305@mit.edu> <56E80B7B.2010801@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrRuv9SLM4NIGIYuTb1+xWfxbau/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZdw7+4GlYKN6xZ3rP1kbGLsUuhg5OSQETCTO zW1h6WLk4hASaGOSmLRgHRuEs5FR4v+Ti1CZh0wSy36eZARpYRZQl/gz7xIziM0roCfx6tZl VhBbWMBD4srGt0wgNpuAqsT0NS1gNqeApsTSfWfZuxg5OFiA4q03ZUBMkDHtJ10gJmpLLFv4 GmqilcSBLStZIdZ+Z5H49mgfG0hCBKjo4utb7BBXy0rs/v2IaQKjwCwkF81CctEsJHMXMDKv YpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECA5TSd4djP/ueh1iFOBgVOLhnSH1 PEyINbGsuDL3EKMkB5OSKG8034swIb6k/JTKjMTijPii0pzU4kOMEhzMSiK83epAOd6UxMqq 1KJ8mJQ0B4uSOG/MzaNhQgLpiSWp2ampBalFMFkZDg4lCV5PTaBGwaLU9NSKtMycEoQ0Ewcn yHAeoOFvQWp4iwsSc4sz0yHypxgVpcR5X2gAJQRAEhmleXC9oDSS8Paw6StGcaBXhHl/g1Tx AFMQXPcroMFMQIN7wp+BDC5JREhJNTBe+cgYscH4b95N3zP8M14LvT+9wy5NaEr5ZGkug2Pz VYPnfFvEmMTf43znX+TDC2cun3vNEuCU+fD33yAtvSUqC25/2V289f5k37XNzwNv60R1ex/j 1XhmyvujUoa30msL01NW1TOCy1rDeCZanHM9t/7d7FOCpRx6yq+K/zEceO8XVmr5OPGTEktx RqKhFnNRcSIAGBRL6v4CAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 15:39:10 -0000

So long as you=E2=80=99re storing the client_id and client_secret in =
your LDAP and not putting a username and password (that normally =
represents a person) into the software, you=E2=80=99re fine. That=E2=80=99=
s just a case of externalizing the client registration to the LDAP =
system =E2=80=94 it=E2=80=99s still registered.=20

Otherwise, if you=E2=80=99re putting a person=E2=80=99s information into =
the client there, you=E2=80=99re doing impersonation. That=E2=80=99s =
bad, don=E2=80=99t do that.

 =E2=80=94 Justin

> On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin  =
wrote:
>=20
> Hi Justin
>=20
> Many thanks for the quick response.
> On 15/03/16 12:53, Justin Richer wrote:
>> Is Alice the client here (the piece of software), or is Alice the
>> resource owner?
> Piece of software, something that needs to run without the human user =
being involved
>> If Alice is the resource owner, then you should
>> absolutely not be using the client credentials flow like this.
>>=20
> Sure.
>=20
>> The client credentials flow is designed for cases where the client is
>> acting on its own behalf, not on behalf of any particular user. It's =
an
>> optimization of the canonical authorization code flow, where there is =
no
>> interaction with the resource owner because there is no resource =
owner
>> as a separate entity. It's most useful for backend systems that would
>> have traditionally used a developer key to get access to bulk data. =
If
>> you're using it for single-user access, you're doing it wrong.
>>=20
> I guess I'm still OK here, as I said, it is a piece of software which =
runs without a user. Like in all web services (SOAP or plain HTTP client =
invocations) where the client sets some credentials and accesses some =
data in the remote service.
>=20
>> Also, you should keep in mind that things that seem "simple" on the
>> surface are often simplified at the cost of making specific security
>> concessions and assumptions. The authorization code flow is "complex"
>> for very good reasons, all of them security focused. You should never
>> pick a different OAuth flow just because it looks simpler, you should
>> only pick them if you're within the use case that it was designed =
for,
>> and therefor the assumptions of its security patterns match.
>>=20
> +1
>> We've seen a *ton* of problems with people picking the implicit flow =
in
>> the real world and using it with clients other than in-browser
>> applications that it was designed for. If you're not in that specific
>> space, you're taking on huge risks.
> Sure, I understand.
>=20
> So, as far as my original question is concerned, given that a client =
piece of software (no human user is involved) uses some credentials to =
get the token with client_credentials, would it be OK to avoid the =
explicit 'Client' registration with AS, given that the authentication =
system employed by AS is already aware of such credentials, I guess yes.
>=20
> Thanks, Sergey
>>=20
>>  -- Justin
>>=20
>> On 3/15/2016 8:37 AM, Sergey Beryozkin wrote:
>>> Hi All
>>>=20
>>> I've alway been thinking of Client Credentials as being the simplest
>>> flow but now that I'm looking at implementing it myself to be used =
in
>>> the real productions, I'm realizing that there's something I do not
>>> understand about it:
>>>=20
>>> Do the clients using Client Credentials flow need to be
>>> OAuth2-registered, even when such clients are already known to the
>>> authentication system ?
>>>=20
>>> For example, there might be some LDAP/etc entry for Alice (name,
>>> password). Now a client is using a client credentials flow to get an
>>> access token:
>>>=20
>>> POST /token HTTP/1.1
>>> Host: server.example.com
>>> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>> Content-Type: application/x-www-form-urlencoded
>>>=20
>>> grant_type=3Dclient_credentials
>>>=20
>>> I hope that in this case no explicit registration (the one typically
>>> required in redirection based flows) is needed, the client (Alice) =
has
>>> been 'implicitly' registered (as far as the notion of OAuth2 client =
is
>>> concerned) in LDAP/etc.
>>>=20
>>> If the explicit registration with OAuth2 AS was still required in =
the
>>> case above then it would lead to a fairly massive duplication of
>>> effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>>>=20
>>> Can someone clarify it please ?
>>>=20
>>> Thanks, Sergey
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=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
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Tue Mar 15 08:41:44 2016
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 50BCD12DAED for ; Tue, 15 Mar 2016 08:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 5J0E4T7lMTvp for ; Tue, 15 Mar 2016 08:41:38 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 851FB12DB2D for ; Tue, 15 Mar 2016 08:41:00 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2FFeuvB017869 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2016 15:40:56 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2FFeumO024244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 15:40:56 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2FFetWu013270; Tue, 15 Mar 2016 15:40:55 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Mar 2016 08:40:53 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_434F6A9C-C46B-43EE-8576-0DFEB81A4633"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <56E825B9.6090400@aol.com>
Date: Tue, 15 Mar 2016 08:40:52 -0700
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 15:41:43 -0000

--Apple-Mail=_434F6A9C-C46B-43EE-8576-0DFEB81A4633
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Regarding 2.

The bound config spec makes no such requirement of knowing the and its =
path structure. =20

If you feel that you have other security measures and that clients will =
always have the proper AS, then you can wildcard the whole resource =
parameter.  It still might be advisable to at least check that your =
clients are using a URL of the form https://*.aol.com/* or =
https://*.partner.com/*.

The benefit is that at least you know the client is intending to wield =
the token somewhere in your domain or your partner=E2=80=99s domain. as =
opposed to something like news.aol.myevildomain.com.

The difference here is that security remains the responsibility of the =
service provider in all cases.  The check is up to the service provider =
rather than the client. This means that we don=E2=80=99t have to rely on =
trusting that the client developer bothered to check the configuration =
(as in other proposals that modify OAuth protocol itself) =E2=80=94 we =
know well they won=E2=80=99t because they won=E2=80=99t have to. The =
server side validation is trivial.  I=E2=80=99m not sure how much easier =
this can be. =20

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 15, 2016, at 8:09 AM, George Fletcher  wrote:
>=20
> I worry about two directions I see in this thread...
>=20
> 1. Client's accessing resources dynamically so that discovery is =
required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>=20
> 2. Creating a tight coupling between RS and AS such that RS endpoint =
changes must be continually communicated to the AS. If an RS supports =
multiple AS's then the RS has to deal with "guaranteed" delivery. The AS =
needs an endpoint to receive such communications. If not dynamic via =
APIs, then deployment of the new RS is bound by the associated AS's =
getting and deploying the new endpoints. Can both endpoints of the RS be =
supported within the AS for some period of time, etc. This is an =
operation nightmare and almost assuredly going to go wrong in =
production.
>=20
> Maybe an OAuth2 "audience binding" spec is what's needed for those =
deployments that require this. I believe that is what John Bradley is =
suggesting.
>=20
> Thanks,
> George
>=20
> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>> +1, I've found the very same in OAuth deployments that I was involved =
in; the hard part is to give names and descriptions to these concepts so =
that they cover all use cases and can be applied unambiguously=20
>>=20
>> Hans.=20
>>=20
>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>> I agree that this is valuable, and not just for PoP. In all honesty,=20=

>>> it=E2=80=99s not even really required for PoP to function in many =
cases =E2=80=94 it=E2=80=99s=20
>>> just an optimization for one particular kind of key distribution=20
>>> mechanism in that case.=20
>>>=20
>>> In the years of deployment experience with OAuth 2, I think we=E2=80=99=
ve really=20
>>> got three different kinds of things that currently get folded into=20=

>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:=20
>>>=20
>>>=20
>>>   - What things do I want to access? (photos, profile)=20
>>>   - What actions do I want to take on these things? (read, write, =
delete)=20
>>>   - How long do I want these tokens to work?=20
>>> (offline_access/refresh_token, one time use, next hour, etc)=20
>>>=20
>>>=20
>>> I think the first one is close to the audience/resource parameters =
that=20
>>> have been bandied about a few times, including in the current token=20=

>>> exchange document. We should be consistent across drafts in that =
regard.=20
>>> The second is more traditional scope-ish. The third has been patched =
in=20
>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.=20=

>>>=20
>>> Just another vector to think about if we=E2=80=99re going to be =
adding things=20
>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.=20
>>>=20
>>>   =E2=80=94 Justin=20
>>>=20
>>>=20
>>>> On Mar 14, 2016, at 6:26 PM, John Bradley =20
>>>>  > wrote:=20
>>>>=20
>>>> Yes I will work on another proposal for allowing clients to specify=20=

>>>> what resource they want a token for and providing the meta-data to =
the=20
>>>> client about the resources that a token is valid for.=20
>>>>=20
>>>> We have part of it in the POP key distribution spec and talked =
about=20
>>>> separating it, as it is used more places than just for assigning =
keys.=20
>>>> I know some AS use different token formats for different RS so are=20=

>>>> all-ready needing to pass the resource in the request to avoid =
making=20
>>>> a mess of scopes.=20
>>>>=20
>>>> John B.=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) =20
>>>>>  > =
wrote:=20
>>>>>=20
>>>>> Inline=20
>>>>>=20
>>>>> Phil=20
>>>>>=20
>>>>> On Mar 14, 2016, at 14:13, John Bradley =20
>>>>>  > wrote:=20
>>>>>=20
>>>>>> We had two mandates.  One was to provide a spec for AS metadata.=20=

>>>>>> The other was to mitigate the client mixup attack.  The request =
was=20
>>>>>> to do the latter without requiring the former for clients that =
don=E2=80=99t=20
>>>>>> otherwise need discovery.=20
>>>>> There is no mandate for any of this. See=20
>>>>> =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =
=20
>>>>>>=20
>>>>>> Returning the issuer and client_id from the authorization =
endpoint=20
>>>>>> and the client checking them can be done by the client without=20
>>>>>> discovery.=20
>>>>>=20
>>>>> How does this address the issue of whether the client is talking =
to=20
>>>>> the wrong endpoint?=20
>>>>>>=20
>>>>>> Any client that has the resource and issuer hard coded probably=20=

>>>>>> doesn=E2=80=99t need discovery.=20
>>>>> We agree=20
>>>>>=20
>>>>>=20
>>>>>> One of the things that a client will need discovery for is to =
find=20
>>>>>> the RS, so requiring the client to know the RS URI before getting=20=

>>>>>> the AS config seems backwards to me.=20
>>>>> How can you make an assumption on order? You seem to be conflating=20=

>>>>> authentication with authorization by assuming the identity drives=20=

>>>>> what the resource is.=20
>>>>>=20
>>>>> There are lots of applications that require user rights but are =
not=20
>>>>> identify centric. For example a document service.=20
>>>>>>=20
>>>>>> Unless the client tells the AS where it intends to use the token =
we=20
>>>>>> will be leaving a security hole because the bearer tokens will =
have=20
>>>>>> too loose an audience if they have one at all.=20
>>>>> This is the biggest risk we have IMHO.=20
>>>>>>=20
>>>>>> True you are telling the AS (Webfinger service) what the RS is =
but=20
>>>>>> that is not at a place that is useful in the token production =
process.=20
>>>>>=20
>>>>> This has nothing to do with token production.=20
>>>>>=20
>>>>> What we want to ensure is whether an honest client is correctly=20
>>>>> configured and has not been mislead - eg by a phishing page.=20
>>>>>>=20
>>>>>> I also think there are use cases where the AS doesn=E2=80=99t =
know all the=20
>>>>>> possible RS.   That is not something that a out of band check can=20=

>>>>>> address.=20
>>>>>=20
>>>>> May be. Lets identify them.=20
>>>>>=20
>>>>>> There are also cases where a token might be good at multiple RS=20=

>>>>>> endpoints intentionally.=20
>>>>>=20
>>>>>>  In your solution the client would need to make a discovery =
request=20
>>>>>> for each endpoint.=20
>>>>> Sure. Otherwise how would it know if there is one AS or a pool of =
AS=20
>>>>> servers assigned to each instance?=20
>>>>>> Those requests lack the context of who the client and resource =
owner=20
>>>>>> are.  I think that will be a problem in some use cases.=20
>>>>>=20
>>>>> Not sure I agree. This is about discovering a valid set of =
endpoints.=20
>>>>> For mitm, we mainly want to check the hostname is correct. If a=20
>>>>> client chooses evil.com   the =
cert can be valid and=20
>>>>> TLS will pass. How does it otherwise know it is supposed to talk =
to=20
>>>>> res.example.com  =
?=20
>>>>>>=20
>>>>>> If this is added to the token endpoint it would be checked when =
code=20
>>>>>> or refresh are exchanged, not every time the token is used.=20
>>>>> Your proposal requires rhe client to check. I am not clear how the =
AS=20
>>>>> can know the exact uri. It is far easier to validate than to =
lookup=20
>>>>> since as you say the client may be authorized to use multiple ASs.=20=

>>>>>> With a out of band check the client would never know if a RS was=20=

>>>>>> removed/revoked.=20
>>>>>=20
>>>>> Not sure that is in scope.=20
>>>>>=20
>>>>> None of the current proposals address this issue.=20
>>>>>>=20
>>>>>> I don=E2=80=99t see checking when refreshing a token as something =
that is a=20
>>>>>> huge burden.=20
>>>>>=20
>>>>> Still its a lot more than once.=20
>>>>>=20
>>>>> Why don't you draft another alternative?=20
>>>>>>=20
>>>>>> If the server wants to do the check on it=E2=80=99s side then we =
could=20
>>>>>> require the client to send the RS URI in the token request. that =
way=20
>>>>>> you really know the client is not going to get a token for the =
wrong=20
>>>>>> RS endpoint.=20
>>>>>> If you check out of band in discovery you really have no idea if =
the=20
>>>>>> client is checking.=20
>>>>>=20
>>>>> In the new webfinger draft, the client isn't checking. The service=20=

>>>>> provider simply does not disclose oauth information to =
misconfigured=20
>>>>> clients.=20
>>>>>>=20
>>>>>> John B.=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt =20
>>>>>>>  > =
wrote:=20
>>>>>>>=20
>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take =
each in turn:=20
>>>>>>>=20
>>>>>>> Mike,=20
>>>>>>>=20
>>>>>>> Regarding your suggested amendments=20
>>>>>>>=20
>>>>>>> Item 1: Returning the config URL would create two problems. =
One,it=20
>>>>>>> makes bound discovery a two-step process - that adds complexity.=20=

>>>>>>>  It seems far simpler to mandate TLS (which I think it already =
does=20
>>>>>>> in the security considerations).=20
>>>>>>>=20
>>>>>>> The two-step process allows the current discovery process to=20
>>>>>>> continue. I disagree with this. This is why I put forward an=20
>>>>>>> =E2=80=9Calternate" draft that is almost the same but simply =
adds the check=20
>>>>>>> before returning the configuration data.  I worry that  =
developers=20
>>>>>>> would have no incentive to do the two-step approach. They would=20=

>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at risk of =
exposing=20
>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>=20
>>>>>>> Regarding existing implementations. Most of those =
implementations=20
>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use =
of=20
>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well =
defined=20
>>>>>>> and the likelihood of a client mis-informed about the resource=20=

>>>>>>> endpoint is not there.  IMO This does not apply to the broader=20=

>>>>>>> OAuth community.=20
>>>>>>>=20
>>>>>>> Item 2:  It may be appropriate to have a separate configuration=20=

>>>>>>> registry specification, but I think we should hold off until we=20=

>>>>>>> have a complete solution and then make the decision what drafts=20=

>>>>>>> should exist and how many pieces.  A big concern is the =
perceived=20
>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>=20
>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>=20
>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a =
security threat=20
>>>>>>> by having a discovery specification to prevent clients being=20
>>>>>>> mis-lead about endpoints (of which resource service is one) in =
an=20
>>>>>>> oauth protected exchange.  Maybe what you mean is we should not =
use=20
>>>>>>> .well-known of any kind and we should just create a =
=E2=80=9C/Config=E2=80=9D=20
>>>>>>> endpoint to OAuth?=20
>>>>>>>=20
>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>> You propose that instead the resource endpoint check should be =
in=20
>>>>>>> the oauth protocol itself.  The difference is that validation is=20=

>>>>>>> transferred back to the client to get it right. As well, without=20=

>>>>>>> the client informing the AS, I can=E2=80=99t see a way for the =
AS to know=20
>>>>>>> what endpoint the client is using.  The webfinger approach does=20=

>>>>>>> this once and only requires that the host name be checked in =
many=20
>>>>>>> cases.=20
>>>>>>>=20
>>>>>>> As a principle, the members have discussed many times that the =
AS=20
>>>>>>> service should do validation when possible =E2=80=94 this was =
particularly=20
>>>>>>> true at the Germany meeting when this came up. This is why I =
prefer=20
>>>>>>> the client tell the service provider what it intends to do and =
the=20
>>>>>>> service provider can fail that request immediately if necessary. =
We=20
>>>>>>> don=E2=80=99t have to depend on the developer getting the spec =
correct to=20
>>>>>>> fail the correct way.=20
>>>>>>>=20
>>>>>>> I worry that adding more parameters to the authz and token =
protocol=20
>>>>>>> flows increases complexity and attack surface. It also means per=20=

>>>>>>> authorization validation has to take place vs. a one-time=20
>>>>>>> validation at config time.  Placing it in the configuration =
lookup=20
>>>>>>> phase (whether via web finger or just a special OAuth endpoint)=20=

>>>>>>> seems more appropriate and far less complex - as the request =
itself=20
>>>>>>> is simple and has only one parameter. Here we are not considered=20=

>>>>>>> about legitimacy of the client. we=E2=80=99re just concerned =
with the issue=20
>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>=20
>>>>>>> That said, it may be that when we consider all the use cases, =
some=20
>>>>>>> combination of AS protocol and discovery may be both needed. =
I=E2=80=99m=20
>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>> oauth-discovery spec seems to put future generic clients at risk=20=

>>>>>>> and that is my primary concern.=20
>>>>>>>=20
>>>>>>> Best Regards,=20
>>>>>>>=20
>>>>>>> Phil=20
>>>>>>>=20
>>>>>>> @independentid=20
>>>>>>> www.independentid.com  =
 =20
>>>>>>> phil.hunt@oracle.com  =
 =20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>  =
 =
>=20
>>>>>>>> wrote:=20
>>>>>>>>=20
>>>>>>>> Thanks for posting this, Phil.  It provides a concrete example =
of=20
>>>>>>>> a way that protected resource discovery could be added to=20
>>>>>>>> authorization server metadata discovery, and as such, should=20
>>>>>>>> provide useful input for working group discussions on this =
topic.=20
>>>>>>>> It=E2=80=99s always great when someone takes the time to write =
an actual=20
>>>>>>>> draft that can be examined and implemented, and I appreciate =
you=20
>>>>>>>> doing that.=20
>>>>>>>> The content of your draft points out that there appears to be=20=

>>>>>>>> complete agreement on what the authorization server metadata=20
>>>>>>>> format should be, which is great!  I=E2=80=99ll note that =
Section 3 of=20
>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization =
Server=20
>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo=20
>>>>>>>> applying a correction suggested by the working group.  To me =
this=20
>>>>>>>> suggests that the authorization server metadata definitions in=20=

>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative=20
>>>>>>>> content of the draft) are clearly ready for standardization, =
since=20
>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>> Reading your draft, the problem I have with it is that you are=20=

>>>>>>>> returning the AS metadata only as a WebFinger response, rather=20=

>>>>>>>> than as an https-protected resource published by the =
authorization=20
>>>>>>>> server.  The choice to only return this via WebFinger makes =
your=20
>>>>>>>> draft incompatible with most deployed implementations of OAuth=20=

>>>>>>>> metadata, including the 22 implementations using it listed=20
>>>>>>>> athttp://openid.net/certification/(see the =E2=80=9COP =
Config=E2=80=9D column in=20
>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D=20
>>>>>>>> library, which uses the metadata path for client configuration.=20=

>>>>>>>> Without having ASs provide the metadata as an https-protected=20=

>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use it for =
client=20
>>>>>>>> configuration as the currently do.=20
>>>>>>>> Therefore, I would request that you make these minor revisions =
to=20
>>>>>>>> your draft and republish, so as to provide a unified way =
forward=20
>>>>>>>> that is compatible with all known existing OAuth Discovery=20
>>>>>>>> deployments:=20
>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server WebFinger =
Discovery=E2=80=9D=20
>>>>>>>> to have the WebFinger request return the issuer identifier for =
the=20
>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, =
rather than returning the=20
>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D =
value.=20
>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in =
your=20
>>>>>>>> Section 3.=20
>>>>>>>> That would have the advantage of paring your draft down to only=20=

>>>>>>>> the new things that it proposes, enabling them to be more =
clearly=20
>>>>>>>> understood and evaluated on their own merits.  I look forward =
to=20
>>>>>>>> the discussions of ways of performing additional kinds of OAuth=20=

>>>>>>>> discovery, and consider your draft a valuable input to those=20
>>>>>>>> discussions.=20
>>>>>>>>                                                           Best =
wishes,=20
>>>>>>>>                                                           -- =
Mike=20
>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org =
]*On Behalf Of*John Bradley=20
>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>> *To:*Phil Hunt   =
>=20
>>>>>>>> *Cc:*oauth  =
 >=20
>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>> As I have told Phil off list.=20
>>>>>>>> Discovery is the wrong place to try and provide security =
against=20
>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>> This requires the client to know what the RS URI is before=20
>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>> The proposal Mike and I have been working on requires the =
client=20
>>>>>>>> to have a notion of what API it is looking for and retrieve the=20=

>>>>>>>> .well-known file for that API from the issuer.   That allows a=20=

>>>>>>>> protocol like Connect to register its own config file that can=20=

>>>>>>>> point to the RS.=20
>>>>>>>> If the API specific well known is not available the client can =
try=20
>>>>>>>> the default oauth-server one.=20
>>>>>>>> That then allows us to deal with restricting where AT are=20
>>>>>>>> presented as part of the protocol rather then dragging =
discovery=20
>>>>>>>> in as a requirement.=20
>>>>>>>> In my opinion the resource the token is targeted to should be=20=

>>>>>>>> separated from the scope and returned as part of the meta-data=20=

>>>>>>>> about the AT along with scopes granted and expiry time.   We=20
>>>>>>>> should also have a input parameter for resources so that a =
client=20
>>>>>>>> can restrict tokens issued to a subset of the ones granted by =
the=20
>>>>>>>> refresh token.   It would then also be possible to ask a AS for =
a=20
>>>>>>>> token for a unregistered RS and have the AS produce a JWT =
access=20
>>>>>>>> token with the resource as an audience if policy allows.=20
>>>>>>>> That however was supposed to be dealt with as part of the mixed =
up=20
>>>>>>>> client set of mitigations.=20
>>>>>>>> In that the goal was to mitigate the attacks by returning=20
>>>>>>>> meta-data about the tokens, and not to require discovery.=20
>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=
=80=9D for the code, and I=20
>>>>>>>> intend to discuss at the F2F returning resource for AT as well.=20=

>>>>>>>> Those mitigate the attack.=20
>>>>>>>> I will continue to resist mixing up discovery of configuration=20=

>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>> We return meta-data about the tokens now, because AT are opaque =
to=20
>>>>>>>> the client, we neglected to include some of the information for=20=

>>>>>>>> the client needs to be secure.   We just need to add that in to=20=

>>>>>>>> the existing flows.=20
>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS to implement =
as an add=20
>>>>>>>> on, it puts more of a burden on the client needing to =
potentially=20
>>>>>>>> change how it stores the relationships between AS and RS to=20
>>>>>>>> prevent compromise, I think the solution should be biased =
towards=20
>>>>>>>> simplicity on the client side.=20
>>>>>>>> If we return the resources as part of the existing meta data =
the=20
>>>>>>>> client checks that against the resource it intends to send the=20=

>>>>>>>> token to and if it is not in the list then it can=E2=80=99t =
send the=20
>>>>>>>> token.  Simple check every time it gets a new AT, no =
optionality.=20
>>>>>>>> I am not saying anything new Nat has been advocating basically=20=

>>>>>>>> this for some time, and dis submit a draft.   I prefer to =
return=20
>>>>>>>> the info in the existing format rather than as link headers,  =
but=20
>>>>>>>> that is the largest difference between what Nat and I are =
saying=20
>>>>>>>> with respect to resource.=20
>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20
>>>>>>>> I guess we will need to have a long conversation in BA.=20
>>>>>>>> Regards=20
>>>>>>>> John B.=20
>>>>>>>>=20
>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt =
=20
>>>>>>>>      =
> wrote:=20
>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same=20=

>>>>>>>>     registry for OAuth Config Metadata as the authors believe =
that=20
>>>>>>>>     both solutions are not required, or depending on WG =
discussion=20
>>>>>>>>     they will be merged. The intent is to provide a simple=20
>>>>>>>>     complete draft for consideration.=20
>>>>>>>>     How it works...=20
>>>>>>>>     Given that a client has previously discovered an OAuth=20
>>>>>>>>     protected resource, the bound configuration method allows a=20=

>>>>>>>>     client to return the configuration for an oauth =
authorization=20
>>>>>>>>     server that can issue tokens for the resource URI specified =
by=20
>>>>>>>>     the client.  The AS is not required to be in the same =
domain.=20
>>>>>>>>      The AS is however required to know if it can issue tokens =
for=20
>>>>>>>>     a resource service (which presumes some agreement exists on=20=

>>>>>>>>     tokens etc).=20
>>>>>>>>     The draft does not require that the resource exist (e.g. =
for=20
>>>>>>>>     unconfigured or new user based resources). It only requires=20=

>>>>>>>>     that the AS service provider agrees it can issue tokens.=20
>>>>>>>>     =46rom a security perspective, returning the OAuth service=20=

>>>>>>>>     configuration for a specified resource URI serves to =
confirm=20
>>>>>>>>     the client is in possession of a valid resource URI =
ensuring=20
>>>>>>>>     the client has received a valid set of endpoints for the=20
>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>     I propose that the WG consider the alternate draft =
carefully=20
>>>>>>>>     as well as other submissions and evaluate the broader=20
>>>>>>>>     discovery problem before proceeding with WGLC on OAuth =
Discovery.=20
>>>>>>>>     Thanks!=20
>>>>>>>>     Phil=20
>>>>>>>>     @independentid=20
>>>>>>>>     www.independentid.com  =
 =20
>>>>>>>>     phil.hunt@oracle.com  =
 =20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         Begin forwarded message:=20
>>>>>>>>         *From:*internet-drafts@ietf.org=20
>>>>>>>>          =
=20
>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>         *To:*"Phil Hunt" =20
>>>>>>>>          =
>, "Anthony Nadalin"=20
>>>>>>>>          =
 >,=20
>>>>>>>>         "Tony Nadalin" =20
>>>>>>>>          =
>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>         has been successfully submitted by Phil Hunt and posted =
to the=20
>>>>>>>>         IETF repository.=20
>>>>>>>>=20
>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>         Revision:00=20
>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>         Group:Individual Submission=20
>>>>>>>>         Pages:22=20
>>>>>>>>         URL:=20
>>>>>>>>         =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>>>>>>         Status:=20
>>>>>>>>         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =
=20
>>>>>>>>         Htmlized:=20
>>>>>>>>         =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =
=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         Abstract:=20
>>>>>>>>           This specification defines a mechanism for the client =
of=20
>>>>>>>>         an OAuth 2.0=20
>>>>>>>>           protected resource service to obtain the =
configuration=20
>>>>>>>>         details of an=20
>>>>>>>>           OAuth 2.0 authorization server that is capable of=20
>>>>>>>>         authorizing access=20
>>>>>>>>           to a specific resource service.  The information=20
>>>>>>>>         includes the OAuth=20
>>>>>>>>           2.0 component endpoint location URIs and as well as=20=

>>>>>>>>         authorization=20
>>>>>>>>           server capabilities.=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         Please note that it may take a couple of minutes from =
the=20
>>>>>>>>         time of submission=20
>>>>>>>>         until the htmlized version and diff are available=20
>>>>>>>>         attools.ietf.org  =
.=20
>>>>>>>>=20
>>>>>>>>         The IETF Secretariat=20
>>>>>>>>=20
>>>>>>>>     _______________________________________________=20
>>>>>>>>     OAuth mailing list=20
>>>>>>>>     OAuth@ietf.org  =
 =20
>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>>>=20
>>>>>>=20
>>>>=20
>>>> _______________________________________________=20
>>>> OAuth mailing list=20
>>>> OAuth@ietf.org   =
=20
>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________=20
>>> OAuth mailing list=20
>>> OAuth@ietf.org =20
>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_434F6A9C-C46B-43EE-8576-0DFEB81A4633
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Regarding 2.

    The bound config spec makes no such requirement of knowing =
the and its path structure.  

    If you feel that you have other =
security measures and that clients will always have the proper AS, then =
you can wildcard the whole resource parameter.  It still might be =
advisable to at least check that your clients are using a URL of the =
form https://*.aol.com/* =
or https://*.partner.com/*.

    The benefit is that at least you know =
the client is intending to wield the token somewhere in your domain or =
your partner=E2=80=99s domain. as opposed to something like news.aol.myevildomain.com.

    The difference here is that security =
remains the responsibility of the service provider in all cases. =
 The check is up to the service provider rather than the client. =
This means that we don=E2=80=99t have to rely on trusting that the =
client developer bothered to check the configuration (as in other =
proposals that modify OAuth protocol itself) =E2=80=94 we know well they =
won=E2=80=99t because they won=E2=80=99t have to. The server side =
validation is trivial.  I=E2=80=99m not sure how much easier this =
can be.  

    


    

    

    On Mar 15, 2016, at 8:09 AM, George Fletcher <gffletch@aol.com> =
wrote:

    
 =20
    
 =20
  
    
    I worry about =
two
      directions I see in this thread...
    
      
    
      1. Client's accessing resources dynamically so that discovery is
      required to know the correct AS, etc. This is pretty much the
      classic use case for UMA and I'd rather not re-invent the =
wheel.
    
      
    
      2. Creating a tight coupling between RS and AS such that RS
      endpoint changes must be continually communicated to the AS. If an
      RS supports multiple AS's then the RS has to deal with
      "guaranteed" delivery. The AS needs an endpoint to receive such
      communications. If not dynamic via APIs, then deployment of the
      new RS is bound by the associated AS's getting and deploying the
      new endpoints. Can both endpoints of the RS be supported within
      the AS for some period of time, etc. This is an operation
      nightmare and almost assuredly going to go wrong in production.
    
      
    
      Maybe an OAuth2 "audience binding" spec is what's needed for those
      deployments that require this. I believe that is what John Bradley
      is suggesting.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/14/16 7:29 PM, Hans Zandbelt
      wrote:
    
    
    
    
    +1,
      I've found the very same in OAuth deployments that I was involved
      in; the hard part is to give names and descriptions to these
      concepts so that they cover all use cases and can be applied
      unambiguously
      
    
      
    
      Hans.
      
    
      
    
      On 3/14/16 10:44 PM, Justin Richer wrote:
      
    
      
    I agree that this is =
valuable, and not
        just for PoP. In all honesty,
        
    
        it=E2=80=99s not even really required for PoP to function in =
many cases
        =E2=80=94 it=E2=80=99s
        
    
        just an optimization for one particular kind of key distribution
        
    
        mechanism in that case.
        
    
        
    
        In the years of deployment experience with OAuth 2, I think
        we=E2=80=99ve really
        
    
        got three different kinds of things that currently get folded
        into
        
    
        =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:
        
    
        
    
        
    
          - What things do I want to access? (photos, profile)
        
    
          - What actions do I want to take on these things? (read,
        write, delete)
        
    
          - How long do I want these tokens to work?
        
    
        (offline_access/refresh_token, one time use, next hour, etc)
        
    
        
    
        
    
        I think the first one is close to the audience/resource
        parameters that
        
    
        have been bandied about a few times, including in the current
        token
        
    
        exchange document. We should be consistent across drafts in that
        regard.
        
    
        The second is more traditional scope-ish. The third has been
        patched in
        
    
        with things like =E2=80=9Coffline_access=E2=80=9D in certain =
APIs.
        
    
        
    
        Just another vector to think about if we=E2=80=99re going to be =
adding
        things
        
    
        like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.
        
    
        
    
          =E2=80=94 Justin
        
    
        
    
        
    
        
    On Mar 14, 2016, at 6:26 =
PM, John
          Bradley <ve7jtb@ve7jtb.com
          
    
          <mailto:ve7jtb@ve7jtb.com>>=
 wrote:
          
    
          
    
          Yes I will work on another proposal for allowing clients to
          specify
          
    
          what resource they want a token for and providing the
          meta-data to the
          
    
          client about the resources that a token is valid for.
          
    
          
    
          We have part of it in the POP key distribution spec and talked
          about
          
    
          separating it, as it is used more places than just for
          assigning keys.
          
    
          I know some AS use different token formats for different RS so
          are
          
    
          all-ready needing to pass the resource in the request to avoid
          making
          
    
          a mess of scopes.
          
    
          
    
          John B.
          
    
          
    
          
    
          
    
          
    
          
    
          
    On Mar 14, 2016, at 7:17 =
PM, Phil Hunt
            (IDM) <phil.hunt@oracle.com
            
    
            <mailto:phil.hunt@oracle.com>> wrote:
            
    
            
    
            Inline
            
    
            
    
            Phil
            
    
            
    
            On Mar 14, 2016, at 14:13, John Bradley
            <    ve7jtb@ve7jtb.com
            
    
            <mailto:ve7jtb@ve7jtb.com>>=
 wrote:
            
    
            
    
            
    We had two =
mandates.  One was to
              provide a spec for AS metadata.
              
    
              The other was to mitigate the client mixup attack.  =
The
              request was
              
    
              to do the latter without requiring the former for clients
              that don=E2=80=99t
              
    
              otherwise need discovery.
              
    
            
    
            There is no mandate for any of this. See
            
    
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt
            
    
            
    
              
    
              Returning the issuer and client_id from the authorization
              endpoint
              
    
              and the client checking them can be done by the client
              without
              
    
              discovery.
              
    
            
    
            
    
            How does this address the issue of whether the client is
            talking to
            
    
            the wrong endpoint?
            
    
            
    
              
    
              Any client that has the resource and issuer hard coded
              probably
              
    
              doesn=E2=80=99t need discovery.
              
    
            
    
            We agree
            
    
            
    
            
    
            
    One of the things that =
a client will
              need discovery for is to find
              
    
              the RS, so requiring the client to know the RS URI before
              getting
              
    
              the AS config seems backwards to me.
              
    
            
    
            How can you make an assumption on order? You seem to be
            conflating
            
    
            authentication with authorization by assuming the identity
            drives
            
    
            what the resource is.
            
    
            
    
            There are lots of applications that require user rights but
            are not
            
    
            identify centric. For example a document service.
            
    
            
    
              
    
              Unless the client tells the AS where it intends to use the
              token we
              
    
              will be leaving a security hole because the bearer tokens
              will have
              
    
              too loose an audience if they have one at all.
              
    
            
    
            This is the biggest risk we have IMHO.
            
    
            
    
              
    
              True you are telling the AS (Webfinger service) what the
              RS is but
              
    
              that is not at a place that is useful in the token
              production process.
              
    
            
    
            
    
            This has nothing to do with token production.
            
    
            
    
            What we want to ensure is whether an honest client is
            correctly
            
    
            configured and has not been mislead - eg by a phishing page.
            
    
            
    
              
    
              I also think there are use cases where the AS doesn=E2=80=99=
t know
              all the
              
    
              possible RS.   That is not something that a out =
of band
              check can
              
    
              address.
              
    
            
    
            
    
            May be. Lets identify them.
            
    
            
    
            
    There are also cases =
where a token
              might be good at multiple RS
              
    
              endpoints intentionally.
              
    
            
    
            
    
            
     In your solution =
the client would
              need to make a discovery request
              
    
              for each endpoint.
              
    
            
    
            Sure. Otherwise how would it know if there is one AS or a
            pool of AS
            
    
            servers assigned to each instance?
            
    
            
    Those requests lack the =
context of
              who the client and resource owner
              
    
              are.  I think that will be a problem in some use =
cases.
              
    
            
    
            
    
            Not sure I agree. This is about discovering a valid set of
            endpoints.
            
    
            For mitm, we mainly want to check the hostname is correct.
            If a
            
    
            client chooses evil.com <http://evil.com/> the cert
            can be valid and
            
    
            TLS will pass. How does it otherwise know it is supposed to
            talk to
            
    
            res.example.com <http://res.example.com/>?
            
    
            
    
              
    
              If this is added to the token endpoint it would be checked
              when code
              
    
              or refresh are exchanged, not every time the token is
              used.
              
    
            
    
            Your proposal requires rhe client to check. I am not clear
            how the AS
            
    
            can know the exact uri. It is far easier to validate than to
            lookup
            
    
            since as you say the client may be authorized to use
            multiple ASs.
            
    
            
    With a out of band =
check the client
              would never know if a RS was
              
    
              removed/revoked.
              
    
            
    
            
    
            Not sure that is in scope.
            
    
            
    
            None of the current proposals address this issue.
            
    
            
    
              
    
              I don=E2=80=99t see checking when refreshing a token as =
something
              that is a
              
    
              huge burden.
              
    
            
    
            
    
            Still its a lot more than once.
            
    
            
    
            Why don't you draft another alternative?
            
    
            
    
              
    
              If the server wants to do the check on it=E2=80=99s side =
then we
              could
              
    
              require the client to send the RS URI in the token
              request. that way
              
    
              you really know the client is not going to get a token for
              the wrong
              
    
              RS endpoint.
              
    
              If you check out of band in discovery you really have no
              idea if the
              
    
              client is checking.
              
    
            
    
            
    
            In the new webfinger draft, the client isn't checking. The
            service
            
    
            provider simply does not disclose oauth information to
            misconfigured
            
    
            clients.
            
    
            
    
              
    
              John B.
              
    
              
    
              
    
              
    On Mar 14, 2016, at =
3:56 PM, Phil
                Hunt <phil.hunt@oracle.com
                
    
                <mailto:phil.hunt@oracle.com>> wrote:
                
    
                
    
                Thanks to Mike and John for their feedback.  I=E2=80=99=
ll take
                each in turn:
                
    
                
    
                Mike,
                
    
                
    
                Regarding your suggested amendments
                
    
                
    
                Item 1: Returning the config URL would create two
                problems. One,it
                
    
                makes bound discovery a two-step process - that adds
                complexity.
                
    
                 It seems far simpler to mandate TLS (which I think =
it
                already does
                
    
                in the security considerations).
                
    
                
    
                The two-step process allows the current discovery
                process to
                
    
                continue. I disagree with this. This is why I put
                forward an
                
    
                =E2=80=9Calternate" draft that is almost the same but =
simply
                adds the check
                
    
                before returning the configuration data.  I worry =
that 
                developers
                
    
                would have no incentive to do the two-step approach.
                They would
                
    
                just start at step 2 which in turn puts AS=E2=80=99s at =
risk of
                exposing
                
    
                tokens because it works. This makes OAuth promiscuous.
                
    
                
    
                Regarding existing implementations. Most of those
                implementations
                
    
                are for OIDC.  I think it makes sense for OIDF to
                continue use of
                
    
                OIDC's discovery spec because the UserInfo endpoint is
                well defined
                
    
                and the likelihood of a client mis-informed about the
                resource
                
    
                endpoint is not there.  IMO This does not apply to =
the
                broader
                
    
                OAuth community.
                
    
                
    
                Item 2:  It may be appropriate to have a separate
                configuration
                
    
                registry specification, but I think we should hold off
                until we
                
    
                have a complete solution and then make the decision what
                drafts
                
    
                should exist and how many pieces.  A big concern is =
the
                perceived
                
    
                complexity of multiple solutions and multiple drafts.
                
    
                
    
                As to John Bradley=E2=80=99s comments:
                
    
                
    
                Re: Discovery is the wrong place to mitigate threats.
                
    
                I=E2=80=99m confused by this.  Our mandate was to =
solve a
                security threat
                
    
                by having a discovery specification to prevent clients
                being
                
    
                mis-lead about endpoints (of which resource service is
                one) in an
                
    
                oauth protected exchange.  Maybe what you mean is =
we
                should not use
                
    
                .well-known of any kind and we should just create a
                =E2=80=9C/Config=E2=80=9D
                
    
                endpoint to OAuth?
                
    
                
    
                Re: Your proposal for MITM mitigation
                
    
                You propose that instead the resource endpoint check
                should be in
                
    
                the oauth protocol itself.  The difference is that
                validation is
                
    
                transferred back to the client to get it right. As well,
                without
                
    
                the client informing the AS, I can=E2=80=99t see a way =
for the
                AS to know
                
    
                what endpoint the client is using.  The webfinger
                approach does
                
    
                this once and only requires that the host name be
                checked in many
                
    
                cases.
                
    
                
    
                As a principle, the members have discussed many times
                that the AS
                
    
                service should do validation when possible =E2=80=94 =
this was
                particularly
                
    
                true at the Germany meeting when this came up. This is
                why I prefer
                
    
                the client tell the service provider what it intends to
                do and the
                
    
                service provider can fail that request immediately if
                necessary. We
                
    
                don=E2=80=99t have to depend on the developer getting =
the spec
                correct to
                
    
                fail the correct way.
                
    
                
    
                I worry that adding more parameters to the authz and
                token protocol
                
    
                flows increases complexity and attack surface. It also
                means per
                
    
                authorization validation has to take place vs. a
                one-time
                
    
                validation at config time.  Placing it in the
                configuration lookup
                
    
                phase (whether via web finger or just a special OAuth
                endpoint)
                
    
                seems more appropriate and far less complex - as the
                request itself
                
    
                is simple and has only one parameter. Here we are not
                considered
                
    
                about legitimacy of the client. we=E2=80=99re just =
concerned
                with the issue
                
    
                "has the client been correctly informed?=E2=80=9D
                
    
                
    
                That said, it may be that when we consider all the use
                cases, some
                
    
                combination of AS protocol and discovery may be both
                needed. I=E2=80=99m
                
    
                not ready to make conclusions about this.  The =
current
                
    
                oauth-discovery spec seems to put future generic clients
                at risk
                
    
                and that is my primary concern.
                
    
                
    
                Best Regards,
                
    
                
    
                Phil
                
    
                
    
                @independentid
                
    
                    www.independentid.com
                <http://www.independentid.com/&g=
t;
                
    
                phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 13, 2016, at =
10:28 PM,
                  Mike Jones
                  
    
                  <    Michael.Jones@microsoft.com
                  <mailto:Michael.Jones@micro=
soft.com>>
                  
    
                  wrote:
                  
    
                  
    
                  Thanks for posting this, Phil.  It provides a =
concrete
                  example of
                  
    
                  a way that protected resource discovery could be added
                  to
                  
    
                  authorization server metadata discovery, and as such,
                  should
                  
    
                  provide useful input for working group discussions on
                  this topic.
                  
    
                  It=E2=80=99s always great when someone takes the time =
to write
                  an actual
                  
    
                  draft that can be examined and implemented, and I
                  appreciate you
                  
    
                  doing that.
                  
    
                  The content of your draft points out that there
                  appears to be
                  
    
                  complete agreement on what the authorization server
                  metadata
                  
    
                  format should be, which is great!  I=E2=80=99ll =
note that
                  Section 3 of
                  
    
                  draft-hunt-oauth-bound-config-00 titled =
=E2=80=9CAuthorization
                  Server
                  
    
                  Metadata=E2=80=9D is an exact copy of Section 2 of
                  
    
                  draft-ietf-oauth-discovery-01 (with the same title),
                  modulo
                  
    
                  applying a correction suggested by the working =
group. 
                  To me this
                  
    
                  suggests that the authorization server metadata
                  definitions in
                  
    
                  draft-ietf-oauth-discovery (which is now the whole
                  normative
                  
    
                  content of the draft) are clearly ready for
                  standardization, since
                  
    
                  even your alternative proposal includes them verbatim.
                  
    
                  Reading your draft, the problem I have with it is that
                  you are
                  
    
                  returning the AS metadata only as a WebFinger
                  response, rather
                  
    
                  than as an https-protected resource published by the
                  authorization
                  
    
                  server.  The choice to only return this via =
WebFinger
                  makes your
                  
    
                  draft incompatible with most deployed implementations
                  of OAuth
                  
    
                  metadata, including the 22 implementations using it
                  listed
                  
    
                  athttp://openid.net/certification/(see the =E2=80=9COP =
Config=E2=80=9D
                  column in
                  
    
                  the table) andOAuth 2.0 libraries such as =
Microsoft=E2=80=99s
                  =E2=80=9CADAL=E2=80=9D
                  
    
                  library, which uses the metadata path for client
                  configuration.
                  
    
                  Without having ASs provide the metadata as an
                  https-protected
                  
    
                  resource, implementations such as ADAL can=E2=80=99t =
use it
                  for client
                  
    
                  configuration as the currently do.
                  
    
                  Therefore, I would request that you make these minor
                  revisions to
                  
    
                  your draft and republish, so as to provide a unified
                  way forward
                  
    
                  that is compatible with all known existing OAuth
                  Discovery
                  
    
                  deployments:
                  
    
                  1.Modify your section 2 =E2=80=9CAuthorization Server
                  WebFinger Discovery=E2=80=9D
                  
    
                  to have the WebFinger request return the issuer
                  identifier for the
                  
    
                  AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D =
value, rather than
                  returning the
                  
    
                  metadata values by value as the =E2=80=9Cproperties=E2=80=
=9D value.
                  
    
                  2.Reference the metadata definitions from Section 2 of
                  
    
                  draft-ietf-oauth-discovery, rather than duplicating
                  them in your
                  
    
                  Section 3.
                  
    
                  That would have the advantage of paring your draft
                  down to only
                  
    
                  the new things that it proposes, enabling them to be
                  more clearly
                  
    
                  understood and evaluated on their own merits.  I =
look
                  forward to
                  
    
                  the discussions of ways of performing additional kinds
                  of OAuth
                  
    
                  discovery, and consider your draft a valuable input to
                  those
                  
    
                  discussions.
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  Best wishes,
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  -- Mike
                  
    
                  *From:*OAuth [mailto:oauth-bounces@ietf.org]*=
On Behalf
                  Of*John Bradley
                  
    
                  *Sent:*Sunday, March 13, 2016 6:45 PM
                  
    
                  *To:*Phil Hunt <phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>>
                  
    
                  *Cc:*oauth <    oauth@ietf.org
                  <mailto:oauth@ietf.org>>
                  
    
                  *Subject:*Re: [OAUTH-WG] New Version Notification for
                  
    
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  As I have told Phil off list.
                  
    
                  Discovery is the wrong place to try and provide
                  security against
                  
    
                  man in the middle attacks on the RS.
                  
    
                  This requires the client to know what the RS URI is
                  before
                  
    
                  retrieving the information on the AS Configuration.
                  
    
                  The proposal Mike and I have been working on requires
                  the client
                  
    
                  to have a notion of what API it is looking for and
                  retrieve the
                  
    
                  .well-known file for that API from the =
issuer.   That
                  allows a
                  
    
                  protocol like Connect to register its own config file
                  that can
                  
    
                  point to the RS.
                  
    
                  If the API specific well known is not available the
                  client can try
                  
    
                  the default oauth-server one.
                  
    
                  That then allows us to deal with restricting where AT
                  are
                  
    
                  presented as part of the protocol rather then dragging
                  discovery
                  
    
                  in as a requirement.
                  
    
                  In my opinion the resource the token is targeted to
                  should be
                  
    
                  separated from the scope and returned as part of the
                  meta-data
                  
    
                  about the AT along with scopes granted and expiry
                  time.   We
                  
    
                  should also have a input parameter for resources so
                  that a client
                  
    
                  can restrict tokens issued to a subset of the ones
                  granted by the
                  
    
                  refresh token.   It would then also be =
possible to ask
                  a AS for a
                  
    
                  token for a unregistered RS and have the AS produce a
                  JWT access
                  
    
                  token with the resource as an audience if policy
                  allows.
                  
    
                  That however was supposed to be dealt with as part of
                  the mixed up
                  
    
                  client set of mitigations.
                  
    
                  In that the goal was to mitigate the attacks by
                  returning
                  
    
                  meta-data about the tokens, and not to require
                  discovery.
                  
    
                  We intend to return =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Ccleint_id=E2=80=9D for the
                  code, and I
                  
    
                  intend to discuss at the F2F returning resource for AT
                  as well.
                  
    
                  Those mitigate the attack.
                  
    
                  I will continue to resist mixing up discovery of
                  configuration
                  
    
                  meta-data with mitigation of the attacks.
                  
    
                  We return meta-data about the tokens now, because AT
                  are opaque to
                  
    
                  the client, we neglected to include some of the
                  information for
                  
    
                  the client needs to be secure.   We just =
need to add
                  that in to
                  
    
                  the existing flows.
                  
    
                  While Phil=E2=80=99s proposal is easier for the AS to
                  implement as an add
                  
    
                  on, it puts more of a burden on the client needing to
                  potentially
                  
    
                  change how it stores the relationships between AS and
                  RS to
                  
    
                  prevent compromise, I think the solution should be
                  biased towards
                  
    
                  simplicity on the client side.
                  
    
                  If we return the resources as part of the existing
                  meta data the
                  
    
                  client checks that against the resource it intends to
                  send the
                  
    
                  token to and if it is not in the list then it can=E2=80=99=
t
                  send the
                  
    
                  token.  Simple check every time it gets a new AT, =
no
                  optionality.
                  
    
                  I am not saying anything new Nat has been advocating
                  basically
                  
    
                  this for some time, and dis submit a =
draft.   I prefer
                  to return
                  
    
                  the info in the existing format rather than as link
                  headers,  but
                  
    
                  that is the largest difference between what Nat and I
                  are saying
                  
    
                  with respect to resource.
                  
    
                  That is the core of my problem with Phil=E2=80=99s =
draft.
                  
    
                  I guess we will need to have a long conversation in
                  BA.
                  
    
                  Regards
                  
    
                  John B.
                  
    
                  
    
                      On Mar 13, 2016, at 8:12 PM, Phil =
Hunt
                  <phil.hunt@oracle.com
                  
    
                      <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                      This draft is a proposed alternate =
proposal for
                  
    
                      draft-ietf-oauth-discovery.  =
As such, it contains
                  the same
                  
    
                      registry for OAuth Config Metadata =
as the authors
                  believe that
                  
    
                      both solutions are not required, or =
depending on
                  WG discussion
                  
    
                      they will be merged. The intent is =
to provide a
                  simple
                  
    
                      complete draft for consideration.
                  
    
                      How it works...
                  
    
                      Given that a client has previously =
discovered an
                  OAuth
                  
    
                      protected resource, the bound =
configuration method
                  allows a
                  
    
                      client to return the configuration =
for an oauth
                  authorization
                  
    
                      server that can issue tokens for =
the resource URI
                  specified by
                  
    
                      the client.  The AS is not =
required to be in the
                  same domain.
                  
    
                       The AS is however required to =
know if it can
                  issue tokens for
                  
    
                      a resource service (which presumes =
some agreement
                  exists on
                  
    
                      tokens etc).
                  
    
                      The draft does not require that the =
resource exist
                  (e.g. for
                  
    
                      unconfigured or new user based =
resources). It only
                  requires
                  
    
                      that the AS service provider agrees =
it can issue
                  tokens.
                  
    
                      =46rom a security perspective, =
returning the OAuth
                  service
                  
    
                      configuration for a specified =
resource URI serves
                  to confirm
                  
    
                      the client is in possession of a =
valid resource
                  URI ensuring
                  
    
                      the client has received a valid set =
of endpoints
                  for the
                  
    
                      resource and the associated oauth =
services.
                  
    
                      I propose that the WG consider the =
alternate draft
                  carefully
                  
    
                      as well as other submissions and =
evaluate the
                  broader
                  
    
                      discovery problem before proceeding =
with WGLC on
                  OAuth Discovery.
                  
    
                      Thanks!
                  
    
                      Phil
                  
    
                      @independentid
                  
    
                          www.independentid.com
                  <http://www.independentid.com/&g=
t;
                  
    
                      phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                          Begin =
forwarded message:
                  
    
                          *From:*    internet-drafts@ietf.org
                  
    
                          <mailto:internet-drafts@ietf.o=
rg>
                  
    
                          *Subject: =
New Version Notification for
                  
    
                          =
draft-hunt-oauth-bound-config-00.txt*
                  
    
                          =
*Date:*March 13, 2016 at 3:53:37 PM PDT
                  
    
                          *To:*"Phil =
Hunt" <phil.hunt@yahoo.com
                  
    
                          <mailto:phil.hunt@yahoo.com>=
>,
                  "Anthony Nadalin"
                  
    
                          <tonynad@microsoft.com
                  <mailto:tonynad@microsoft.com>=
>,
                  
    
                          "Tony =
Nadalin" <tonynad@microsoft.com
                  
    
                          <mailto:tonynad@microsoft.com>=
>
                  
    
                  
    
                  
    
                          A new =
version of I-D,
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                          has been =
successfully submitted by Phil Hunt
                  and posted to the
                  
    
                          IETF =
repository.
                  
    
                  
    
                          =
Name:draft-hunt-oauth-bound-config
                  
    
                          Revision:00
                  
    
                          Title:OAuth =
2.0 Bound Configuration Lookup
                  
    
                          Document =
date:2016-03-13
                  
    
                          =
Group:Individual Submission
                  
    
                          Pages:22
                  
    
                          URL:
                  
    
                         
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-confi=
g-00.txt
    
                          Status:
                  
    
                         
                  h=
ttps://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                  
    
                          Htmlized:
                  
    
                         
                  http=
s://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                  
    
                  
    
                  
    
                          Abstract:
                  
    
                            =
This specification defines a mechanism for
                  the client of
                  
    
                          an OAuth =
2.0
                  
    
                            =
protected resource service to obtain the
                  configuration
                  
    
                          details of =
an
                  
    
                            =
OAuth 2.0 authorization server that is
                  capable of
                  
    
                          authorizing =
access
                  
    
                            =
to a specific resource service.  The
                  information
                  
    
                          includes =
the OAuth
                  
    
                            =
2.0 component endpoint location URIs and as
                  well as
                  
    
                          =
authorization
                  
    
                            =
server capabilities.
                  
    
                  
    
                  
    
                  
    
                  
    
                          Please note =
that it may take a couple of
                  minutes from the
                  
    
                          time of =
submission
                  
    
                          until the =
htmlized version and diff are
                  available
                  
    
                          attools.ietf.org
                  <http://tools.ietf.org/>.
                  
    
                  
    
                          The IETF =
Secretariat
                  
    
                  
    
                      =
_______________________________________________
                  
    
                      OAuth mailing list
                  
    
                      OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                      https://www.ietf.org/=
mailman/listinfo/oauth
                  
    
                
    
                
    
              
    
              
    
            
    
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.org <mailto:OAuth@ietf.org>
          
    
          https://www.ietf.org/=
mailman/listinfo/oauth
          
    
        
    
        
    
        
    
        
    
        _______________________________________________
        
    
        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

    =

--Apple-Mail=_434F6A9C-C46B-43EE-8576-0DFEB81A4633--


From nobody Tue Mar 15 08:47:00 2016
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 2E31812DC64 for ; Tue, 15 Mar 2016 08:46: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, 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=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 mkta5Qm_S4kg for ; Tue, 15 Mar 2016 08:46:52 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 44DCB12DC49 for ; Tue, 15 Mar 2016 08:46:52 -0700 (PDT)
Received: by mail-ig0-x236.google.com with SMTP id av4so90842602igc.1 for ; Tue, 15 Mar 2016 08:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pDMAGbFpwBnxaj2ZwWpEnL0I7w7Qf8p5ylHo3mbnd84=; b=Sfq4kx6GtTijtcswzDMcfmIgNb1B5NkNxqTOI2USesGvSy4NOBzT/PyIp2sNkRqyI5 yRYDYDChjrL5+LdSRXO30y/dCSHJjSPltEmybb4LjHKEaX9SOd6dp3KK/XhaX+ACoS9e b4t/dWcqEF/XAH2QEIV3M3bYduaB9DoqM6O3Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pDMAGbFpwBnxaj2ZwWpEnL0I7w7Qf8p5ylHo3mbnd84=; b=le/7aBfiPS31q5ybs6My/aqeIxumttdYjBN3SCjswPro2TJ34Z/DkpaCJYv3j6Tuo6 LouyQlVAYZS5aqoMe7Kr9f/XXMDpiKdisbgrUSTleAtx3N/Lj18/5GMsXbIi4Ve9u7fu Q1gJHOhK4uZXt2ebY5vb1xIIgO0Egx3BF4HsFQg5rnp4dRqGYXZA8g9gEGNv9NHg6J8G hEha5x+KKcT1OeSsZs8pYQHlJc0Ic0T3P/zBWSZT5GL+rjXbU3CS3VmymXYHKzTufBoX /NEM32jJ5QJ6Cg0oXGgDYUP9EsCOioRQISzfM0Vje5nTCPlk4HBY+Te5PizcAKe0rf2Y pTQw==
X-Gm-Message-State: AD7BkJJtWkARjaKNXE9ukTRIq04WYtXUEte6Fy9XLUiriSVR4m/OC38O6YLMuHKY3C9DbsyWaMoPrJQzM+YxRZhJ
X-Received: by 10.50.119.103 with SMTP id kt7mr25107341igb.49.1458056811466; Tue, 15 Mar 2016 08:46:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 15 Mar 2016 08:46:21 -0700 (PDT)
In-Reply-To: <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>
From: Brian Campbell 
Date: Tue, 15 Mar 2016 09:46:21 -0600
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=089e010d93784f9ac0052e184e92
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 15:46:57 -0000

--089e010d93784f9ac0052e184e92
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If the client specifies the desired audience(s)/resource(s), is that
metadata to the client needed? The AS can audience restrict the token as
needed or respond with an error if it can't or wont issue a token for the
resource the client asked for.

On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  wrote:

> Yes,  I think bearer tokens with no audience are a bad idea.
>
> The AS needs to infer an audience from the scopes snd/or have the client
> specify the desired audience.
>
> If the AT has a audience or audiences then as long as the endpoint URI ar=
e
> provided as meta-data with the token, the client can determine if it is
> sending the token to the correct place.
>
> I think Phil would prefer the server rather than the client do the check,
> but the client always needs to take some responsibility to not leak token=
s
> giving them to the wrong RS or the code to the wrong token endpoint is
> leaking.
>
> I imagine that claims based access tokens are going to become more popula=
r
> and the static relationship between one RS and one AS will not be the
> majority of deployments over time.
>
> In any case where the client is configured up front to know the RS and th=
e
> AS it seems like that would not require Phil=E2=80=99s Solution, but that=
 is the
> only case supported by that discovery.
>
> If the client itself is bad there is not much you can do to stop it from
> passing on the AT in way way it wants.  That however is a different probl=
em
> and needs claimed URI or attestations to prevent client spoofing.
> William and I are working on that in the mobile best practices draft.
>
> John B.
>
>
> On Mar 15, 2016, at 12:09 PM, George Fletcher  wrote:
>
> I worry about two directions I see in this thread...
>
> 1. Client's accessing resources dynamically so that discovery is required
> to know the correct AS, etc. This is pretty much the classic use case for
> UMA and I'd rather not re-invent the wheel.
>
> 2. Creating a tight coupling between RS and AS such that RS endpoint
> changes must be continually communicated to the AS. If an RS supports
> multiple AS's then the RS has to deal with "guaranteed" delivery. The AS
> needs an endpoint to receive such communications. If not dynamic via APIs=
,
> then deployment of the new RS is bound by the associated AS's getting and
> deploying the new endpoints. Can both endpoints of the RS be supported
> within the AS for some period of time, etc. This is an operation nightmar=
e
> and almost assuredly going to go wrong in production.
>
> Maybe an OAuth2 "audience binding" spec is what's needed for those
> deployments that require this. I believe that is what John Bradley is
> suggesting.
>
> Thanks,
> George
>
> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>
> +1, I've found the very same in OAuth deployments that I was involved in;
> the hard part is to give names and descriptions to these concepts so that
> they cover all use cases and can be applied unambiguously
>
> Hans.
>
> On 3/14/16 10:44 PM, Justin Richer wrote:
>
> I agree that this is valuable, and not just for PoP. In all honesty,
> it=E2=80=99s not even really required for PoP to function in many cases =
=E2=80=94 it=E2=80=99s
> just an optimization for one particular kind of key distribution
> mechanism in that case.
>
> In the years of deployment experience with OAuth 2, I think we=E2=80=99ve=
 really
> got three different kinds of things that currently get folded into
> =E2=80=9Cscope=E2=80=9D that we might want to try separating out better:
>
>
>   - What things do I want to access? (photos, profile)
>   - What actions do I want to take on these things? (read, write, delete)
>   - How long do I want these tokens to work?
> (offline_access/refresh_token, one time use, next hour, etc)
>
>
> I think the first one is close to the audience/resource parameters that
> have been bandied about a few times, including in the current token
> exchange document. We should be consistent across drafts in that regard.
> The second is more traditional scope-ish. The third has been patched in
> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.
>
> Just another vector to think about if we=E2=80=99re going to be adding th=
ings
> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or both to =
the token requests.
>
>   =E2=80=94 Justin
>
>
> On Mar 14, 2016, at 6:26 PM, John Bradley   > wrote:
>
> Yes I will work on another proposal for allowing clients to specify
> what resource they want a token for and providing the meta-data to the
> client about the resources that a token is valid for.
>
> We have part of it in the POP key distribution spec and talked about
> separating it, as it is used more places than just for assigning keys.
> I know some AS use different token formats for different RS so are
> all-ready needing to pass the resource in the request to avoid making
> a mess of scopes.
>
> John B.
>
>
>
>
>
> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)   > wrote:
>
> Inline
>
> Phil
>
> On Mar 14, 2016, at 14:13, John Bradley   > wrote:
>
> We had two mandates.  One was to provide a spec for AS metadata.
> The other was to mitigate the client mixup attack.  The request was
> to do the latter without requiring the former for clients that don=E2=80=
=99t
> otherwise need discovery.
>
> There is no mandate for any of this. See
> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.t=
xt
>
>
> Returning the issuer and client_id from the authorization endpoint
> and the client checking them can be done by the client without
> discovery.
>
>
> How does this address the issue of whether the client is talking to
> the wrong endpoint?
>
>
> Any client that has the resource and issuer hard coded probably
> doesn=E2=80=99t need discovery.
>
> We agree
>
>
> One of the things that a client will need discovery for is to find
> the RS, so requiring the client to know the RS URI before getting
> the AS config seems backwards to me.
>
> How can you make an assumption on order? You seem to be conflating
> authentication with authorization by assuming the identity drives
> what the resource is.
>
> There are lots of applications that require user rights but are not
> identify centric. For example a document service.
>
>
> Unless the client tells the AS where it intends to use the token we
> will be leaving a security hole because the bearer tokens will have
> too loose an audience if they have one at all.
>
> This is the biggest risk we have IMHO.
>
>
> True you are telling the AS (Webfinger service) what the RS is but
> that is not at a place that is useful in the token production process.
>
>
> This has nothing to do with token production.
>
> What we want to ensure is whether an honest client is correctly
> configured and has not been mislead - eg by a phishing page.
>
>
> I also think there are use cases where the AS doesn=E2=80=99t know all th=
e
> possible RS.   That is not something that a out of band check can
> address.
>
>
> May be. Lets identify them.
>
> There are also cases where a token might be good at multiple RS
> endpoints intentionally.
>
>
>  In your solution the client would need to make a discovery request
> for each endpoint.
>
> Sure. Otherwise how would it know if there is one AS or a pool of AS
> servers assigned to each instance?
>
> Those requests lack the context of who the client and resource owner
> are.  I think that will be a problem in some use cases.
>
>
> Not sure I agree. This is about discovering a valid set of endpoints.
> For mitm, we mainly want to check the hostname is correct. If a
> client chooses evil.com   the cert
> can be valid and
> TLS will pass. How does it otherwise know it is supposed to talk to
> res.example.com  ?
>
>
> If this is added to the token endpoint it would be checked when code
> or refresh are exchanged, not every time the token is used.
>
> Your proposal requires rhe client to check. I am not clear how the AS
> can know the exact uri. It is far easier to validate than to lookup
> since as you say the client may be authorized to use multiple ASs.
>
> With a out of band check the client would never know if a RS was
> removed/revoked.
>
>
> Not sure that is in scope.
>
> None of the current proposals address this issue.
>
>
> I don=E2=80=99t see checking when refreshing a token as something that is=
 a
> huge burden.
>
>
> Still its a lot more than once.
>
> Why don't you draft another alternative?
>
>
> If the server wants to do the check on it=E2=80=99s side then we could
> require the client to send the RS URI in the token request. that way
> you really know the client is not going to get a token for the wrong
> RS endpoint.
> If you check out of band in discovery you really have no idea if the
> client is checking.
>
>
> In the new webfinger draft, the client isn't checking. The service
> provider simply does not disclose oauth information to misconfigured
> clients.
>
>
> John B.
>
>
> On Mar 14, 2016, at 3:56 PM, Phil Hunt   > wrote:
>
> Thanks to Mike and John for their feedback.  I=E2=80=99ll take each in tu=
rn:
>
> Mike,
>
> Regarding your suggested amendments
>
> Item 1: Returning the config URL would create two problems. One,it
> makes bound discovery a two-step process - that adds complexity.
>  It seems far simpler to mandate TLS (which I think it already does
> in the security considerations).
>
> The two-step process allows the current discovery process to
> continue. I disagree with this. This is why I put forward an
> =E2=80=9Calternate" draft that is almost the same but simply adds the che=
ck
> before returning the configuration data.  I worry that  developers
> would have no incentive to do the two-step approach. They would
> just start at step 2 which in turn puts AS=E2=80=99s at risk of exposing
> tokens because it works. This makes OAuth promiscuous.
>
> Regarding existing implementations. Most of those implementations
> are for OIDC.  I think it makes sense for OIDF to continue use of
> OIDC's discovery spec because the UserInfo endpoint is well defined
> and the likelihood of a client mis-informed about the resource
> endpoint is not there.  IMO This does not apply to the broader
> OAuth community.
>
> Item 2:  It may be appropriate to have a separate configuration
> registry specification, but I think we should hold off until we
> have a complete solution and then make the decision what drafts
> should exist and how many pieces.  A big concern is the perceived
> complexity of multiple solutions and multiple drafts.
>
> As to John Bradley=E2=80=99s comments:
>
> Re: Discovery is the wrong place to mitigate threats.
> I=E2=80=99m confused by this.  Our mandate was to solve a security threat
> by having a discovery specification to prevent clients being
> mis-lead about endpoints (of which resource service is one) in an
> oauth protected exchange.  Maybe what you mean is we should not use
> .well-known of any kind and we should just create a =E2=80=9C/Config=E2=
=80=9D
> endpoint to OAuth?
>
> Re: Your proposal for MITM mitigation
> You propose that instead the resource endpoint check should be in
> the oauth protocol itself.  The difference is that validation is
> transferred back to the client to get it right. As well, without
> the client informing the AS, I can=E2=80=99t see a way for the AS to know
> what endpoint the client is using.  The webfinger approach does
> this once and only requires that the host name be checked in many
> cases.
>
> As a principle, the members have discussed many times that the AS
> service should do validation when possible =E2=80=94 this was particularl=
y
> true at the Germany meeting when this came up. This is why I prefer
> the client tell the service provider what it intends to do and the
> service provider can fail that request immediately if necessary. We
> don=E2=80=99t have to depend on the developer getting the spec correct to
> fail the correct way.
>
> I worry that adding more parameters to the authz and token protocol
> flows increases complexity and attack surface. It also means per
> authorization validation has to take place vs. a one-time
> validation at config time.  Placing it in the configuration lookup
> phase (whether via web finger or just a special OAuth endpoint)
> seems more appropriate and far less complex - as the request itself
> is simple and has only one parameter. Here we are not considered
> about legitimacy of the client. we=E2=80=99re just concerned with the iss=
ue
> "has the client been correctly informed?=E2=80=9D
>
> That said, it may be that when we consider all the use cases, some
> combination of AS protocol and discovery may be both needed. I=E2=80=99m
> not ready to make conclusions about this.  The current
> oauth-discovery spec seems to put future generic clients at risk
> and that is my primary concern.
>
> Best Regards,
>
> Phil
>
> @independentid
> www.independentid.com 
> 
> phil.hunt@oracle.com  
>
>
>
>
>
> On Mar 13, 2016, at 10:28 PM, Mike Jones
> 
> >
> wrote:
>
> Thanks for posting this, Phil.  It provides a concrete example of
> a way that protected resource discovery could be added to
> authorization server metadata discovery, and as such, should
> provide useful input for working group discussions on this topic.
> It=E2=80=99s always great when someone takes the time to write an actual
> draft that can be examined and implemented, and I appreciate you
> doing that.
> The content of your draft points out that there appears to be
> complete agreement on what the authorization server metadata
> format should be, which is great!  I=E2=80=99ll note that Section 3 of
> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server
> Metadata=E2=80=9D is an exact copy of Section 2 of
> draft-ietf-oauth-discovery-01 (with the same title), modulo
> applying a correction suggested by the working group.  To me this
> suggests that the authorization server metadata definitions in
> draft-ietf-oauth-discovery (which is now the whole normative
> content of the draft) are clearly ready for standardization, since
> even your alternative proposal includes them verbatim.
> Reading your draft, the problem I have with it is that you are
> returning the AS metadata only as a WebFinger response, rather
> than as an https-protected resource published by the authorization
> server.  The choice to only return this via WebFinger makes your
> draft incompatible with most deployed implementations of OAuth
> metadata, including the 22 implementations using it listed
> athttp://openid.net/certification/(see the =E2=80=9COP Config=E2=80=9D co=
lumn in
> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CAD=
AL=E2=80=9D
> library, which uses the metadata path for client configuration.
> Without having ASs provide the metadata as an https-protected
> resource, implementations such as ADAL can=E2=80=99t use it for client
> configuration as the currently do.
> Therefore, I would request that you make these minor revisions to
> your draft and republish, so as to provide a unified way forward
> that is compatible with all known existing OAuth Discovery
> deployments:
> 1.Modify your section 2 =E2=80=9CAuthorization Server WebFinger Discovery=
=E2=80=9D
> to have the WebFinger request return the issuer identifier for the
> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, rather than ret=
urning the
> metadata values by value as the =E2=80=9Cproperties=E2=80=9D value.
> 2.Reference the metadata definitions from Section 2 of
> draft-ietf-oauth-discovery, rather than duplicating them in your
> Section 3.
> That would have the advantage of paring your draft down to only
> the new things that it proposes, enabling them to be more clearly
> understood and evaluated on their own merits.  I look forward to
> the discussions of ways of performing additional kinds of OAuth
> discovery, and consider your draft a valuable input to those
> discussions.
>                                                           Best wishes,
>                                                           -- Mike
> *From:*OAuth [mailto:oauth-bounces@ietf.org ]*On
> Behalf Of*John Bradley
> *Sent:*Sunday, March 13, 2016 6:45 PM
> *To:*Phil Hunt 
> >
> *Cc:*oauth  >
> *Subject:*Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-bound-config-00.txt
> As I have told Phil off list.
> Discovery is the wrong place to try and provide security against
> man in the middle attacks on the RS.
> This requires the client to know what the RS URI is before
> retrieving the information on the AS Configuration.
> The proposal Mike and I have been working on requires the client
> to have a notion of what API it is looking for and retrieve the
> .well-known file for that API from the issuer.   That allows a
> protocol like Connect to register its own config file that can
> point to the RS.
> If the API specific well known is not available the client can try
> the default oauth-server one.
> That then allows us to deal with restricting where AT are
> presented as part of the protocol rather then dragging discovery
> in as a requirement.
> In my opinion the resource the token is targeted to should be
> separated from the scope and returned as part of the meta-data
> about the AT along with scopes granted and expiry time.   We
> should also have a input parameter for resources so that a client
> can restrict tokens issued to a subset of the ones granted by the
> refresh token.   It would then also be possible to ask a AS for a
> token for a unregistered RS and have the AS produce a JWT access
> token with the resource as an audience if policy allows.
> That however was supposed to be dealt with as part of the mixed up
> client set of mitigations.
> In that the goal was to mitigate the attacks by returning
> meta-data about the tokens, and not to require discovery.
> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=9D=
 for the code, and I
> intend to discuss at the F2F returning resource for AT as well.
> Those mitigate the attack.
> I will continue to resist mixing up discovery of configuration
> meta-data with mitigation of the attacks.
> We return meta-data about the tokens now, because AT are opaque to
> the client, we neglected to include some of the information for
> the client needs to be secure.   We just need to add that in to
> the existing flows.
> While Phil=E2=80=99s proposal is easier for the AS to implement as an add
> on, it puts more of a burden on the client needing to potentially
> change how it stores the relationships between AS and RS to
> prevent compromise, I think the solution should be biased towards
> simplicity on the client side.
> If we return the resources as part of the existing meta data the
> client checks that against the resource it intends to send the
> token to and if it is not in the list then it can=E2=80=99t send the
> token.  Simple check every time it gets a new AT, no optionality.
> I am not saying anything new Nat has been advocating basically
> this for some time, and dis submit a draft.   I prefer to return
> the info in the existing format rather than as link headers,  but
> that is the largest difference between what Nat and I are saying
> with respect to resource.
> That is the core of my problem with Phil=E2=80=99s draft.
> I guess we will need to have a long conversation in BA.
> Regards
> John B.
>
>     On Mar 13, 2016, at 8:12 PM, Phil Hunt       > wrote:
>     This draft is a proposed alternate proposal for
>     draft-ietf-oauth-discovery.  As such, it contains the same
>     registry for OAuth Config Metadata as the authors believe that
>     both solutions are not required, or depending on WG discussion
>     they will be merged. The intent is to provide a simple
>     complete draft for consideration.
>     How it works...
>     Given that a client has previously discovered an OAuth
>     protected resource, the bound configuration method allows a
>     client to return the configuration for an oauth authorization
>     server that can issue tokens for the resource URI specified by
>     the client.  The AS is not required to be in the same domain.
>      The AS is however required to know if it can issue tokens for
>     a resource service (which presumes some agreement exists on
>     tokens etc).
>     The draft does not require that the resource exist (e.g. for
>     unconfigured or new user based resources). It only requires
>     that the AS service provider agrees it can issue tokens.
>     From a security perspective, returning the OAuth service
>     configuration for a specified resource URI serves to confirm
>     the client is in possession of a valid resource URI ensuring
>     the client has received a valid set of endpoints for the
>     resource and the associated oauth services.
>     I propose that the WG consider the alternate draft carefully
>     as well as other submissions and evaluate the broader
>     discovery problem before proceeding with WGLC on OAuth Discovery.
>     Thanks!
>     Phil
>     @independentid
>     www.independentid.com 
> 
>     phil.hunt@oracle.com 
> 
>
>
>         Begin forwarded message:
>         *From:*internet-drafts@ietf.org
>          
>         *Subject: New Version Notification for
>         draft-hunt-oauth-bound-config-00.txt*
>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>         *To:*"Phil Hunt"           >, "Anthony
> Nadalin"
>         
> >,
>         "Tony Nadalin"           >
>
>
>         A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>         has been successfully submitted by Phil Hunt and posted to the
>         IETF repository.
>
>         Name:draft-hunt-oauth-bound-config
>         Revision:00
>         Title:OAuth 2.0 Bound Configuration Lookup
>         Document date:2016-03-13
>         Group:Individual Submission
>         Pages:22
>         URL:
>
> https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>         Status:
>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>         Htmlized:
>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>
>
>         Abstract:
>           This specification defines a mechanism for the client of
>         an OAuth 2.0
>           protected resource service to obtain the configuration
>         details of an
>           OAuth 2.0 authorization server that is capable of
>         authorizing access
>           to a specific resource service.  The information
>         includes the OAuth
>           2.0 component endpoint location URIs and as well as
>         authorization
>           server capabilities.
>
>
>
>
>         Please note that it may take a couple of minutes from the
>         time of submission
>         until the htmlized version and diff are available
>         attools.ietf.org  .
>
>
>         The IETF Secretariat
>
>     _______________________________________________
>     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
>
>
>
>
> _______________________________________________
> 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
>
>

--089e010d93784f9ac0052e184e92
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    If the client specifies the desired audience(s)/resource(s=
), is that metadata to the client needed? The AS can audience restrict the =
token as needed or respond with an error if it can't or wont issue a to=
ken for the resource the client asked for. 

    On Tue, Mar 15, 2016 at 9:37 AM, Jo=
hn Bradley <ve7jtb@ve7jtb.com> wrote:
    Yes, =
=C2=A0I think bearer tokens with no audience are a bad idea.

    =

    The AS needs to infer an audience from the scopes snd/or have the clie=
nt specify the desired audience.

    If the AT has a a=
udience or audiences then as long as the endpoint URI are provided as meta-=
data with the token, the client can determine if it is sending the token to=
 the correct place.

    I think Phil would prefer the =
server rather than the client do the check, but the client always needs to =
take some responsibility to not leak tokens giving them to the wrong RS or =
the code to the wrong token endpoint is leaking.

    I=
 imagine that claims based access tokens are going to become more popular a=
nd the static relationship between one RS and one AS will not be the majori=
ty of deployments over time.=C2=A0

    In any case whe=
re the client is configured up front to know the RS and the AS it seems lik=
e that would not require Phil=E2=80=99s Solution, but that is the only case=
 supported by that discovery.
    =C2=A0=C2=A0
    If the clien=
t itself is bad there is not much you can do to stop it from passing on the=
 AT in way way it wants.=C2=A0 That however is a different problem and need=
s claimed URI or attestations to prevent client spoofing.
    William=
 and I are working on that in the mobile best practices draft.
    John B.


    On Mar 15, 2016, at 12:09 PM, George Fletcher <gffletch@aol.com> wrote:
    
 =20
   =20
 =20
  
    
    I worry about two
      directions I see in this thread...
    
      
    
      1. Client's accessing resources dynamically so that discovery is
      required to know the correct AS, etc. This is pretty much the
      classic use case for UMA and I'd rather not re-invent the wheel.<=
br>
      
    
      2. Creating a tight coupling between RS and AS such that RS
      endpoint changes must be continually communicated to the AS. If an
      RS supports multiple AS's then the RS has to deal with
      "guaranteed" delivery. The AS needs an endpoint to receive =
such
      communications. If not dynamic via APIs, then deployment of the
      new RS is bound by the associated AS's getting and deploying the
      new endpoints. Can both endpoints of the RS be supported within
      the AS for some period of time, etc. This is an operation
      nightmare and almost assuredly going to go wrong in production.
    
      
    
      Maybe an OAuth2 "audience binding" spec is what's neede=
d for those
      deployments that require this. I believe that is what John Bradley
      is suggesting.
    
      
    
      Thanks,
    
      George
    
    

    
    
    On 3/14/16 7:29 PM, Hans Zandbelt
      wrote:
    
    
    
    
    +1,
      I've found the very same in OAuth deployments that I was involved
      in; the hard part is to give names and descriptions to these
      concepts so that they cover all use cases and can be applied
      unambiguously
      
    
      
    
      Hans.
      
    
      
    
      On 3/14/16 10:44 PM, Justin Richer wrote:
      
    
      
    I agree that this is valuable, and not
        just for PoP. In all honesty,
        
    
        it=E2=80=99s not even really required for PoP to function in many c=
ases
        =E2=80=94 it=E2=80=99s
        
    
        just an optimization for one particular kind of key distribution
        
    
        mechanism in that case.
        
    
        
    
        In the years of deployment experience with OAuth 2, I think
        we=E2=80=99ve really
        
    
        got three different kinds of things that currently get folded
        into
        
    
        =E2=80=9Cscope=E2=80=9D that we might want to try separating out be=
tter:
        
    
        
    
        
    
        =C2=A0 - What things do I want to access? (photos, profile)
        
    
        =C2=A0 - What actions do I want to take on these things? (read,
        write, delete)
        
    
        =C2=A0 - How long do I want these tokens to work?
        
    
        (offline_access/refresh_token, one time use, next hour, etc)
        
    
        
    
        
    
        I think the first one is close to the audience/resource
        parameters that
        
    
        have been bandied about a few times, including in the current
        token
        
    
        exchange document. We should be consistent across drafts in that
        regard.
        
    
        The second is more traditional scope-ish. The third has been
        patched in
        
    
        with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.
        
    
        
    
        Just another vector to think about if we=E2=80=99re going to be add=
ing
        things
        
    
        like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or bo=
th to the token requests.
        
    
        
    
        =C2=A0 =E2=80=94 Justin
        
    
        
    
        
    
        
    On Mar 14, 2016, at 6:26 PM, John
          Bradley <ve7jtb@ve7jtb.com
          
    
          <mailto=
:ve7jtb@ve7jtb.com>> wrote:
          
    
          
    
          Yes I will work on another proposal for allowing clients to
          specify
          
    
          what resource they want a token for and providing the
          meta-data to the
          
    
          client about the resources that a token is valid for.
          
    
          
    
          We have part of it in the POP key distribution spec and talked
          about
          
    
          separating it, as it is used more places than just for
          assigning keys.
          
    
          I know some AS use different token formats for different RS so
          are
          
    
          all-ready needing to pass the resource in the request to avoid
          making
          
    
          a mess of scopes.
          
    
          
    
          John B.
          
    
          
    
          
    
          
    
          
    
          
    
          
    On Mar 14, 2016, at 7:17 PM, Phil Hunt
            (IDM) <phil.hunt@oracle.com
            
    
            <m=
ailto:phil.hunt@oracle.com>> wrote:
            
    
            
    
            Inline
            
    
            
    
            Phil
            
    
            
    
            On Mar 14, 2016, at 14:13, John Bradley
            <ve7j=
tb@ve7jtb.com
            
    
            <mail=
to:ve7jtb@ve7jtb.com>> wrote:
            
    
            
    
            
    We had two mandates.=C2=A0 One was to
              provide a spec for AS metadata.
              
    
              The other was to mitigate the client mixup attack.=C2=A0 The
              request was
              
    
              to do the latter without requiring the former for clients
              that don=E2=80=99t
              
    
              otherwise need discovery.
              
    
            
    
            There is no mandate for any of this. See
            
    
http://tools.ietf.org/wg/oauth/charters?item=
=3Dcharter-oauth-2016-01-22.txt
            
    
            
    
              
    
              Returning the issuer and client_id from the authorization
              endpoint
              
    
              and the client checking them can be done by the client
              without
              
    
              discovery.
              
    
            
    
            
    
            How does this address the issue of whether the client is
            talking to
            
    
            the wrong endpoint?
            
    
            
    
              
    
              Any client that has the resource and issuer hard coded
              probably
              
    
              doesn=E2=80=99t need discovery.
              
    
            
    
            We agree
            
    
            
    
            
    
            
    One of the things that a client will
              need discovery for is to find
              
    
              the RS, so requiring the client to know the RS URI before
              getting
              
    
              the AS config seems backwards to me.
              
    
            
    
            How can you make an assumption on order? You seem to be
            conflating
            
    
            authentication with authorization by assuming the identity
            drives
            
    
            what the resource is.
            
    
            
    
            There are lots of applications that require user rights but
            are not
            
    
            identify centric. For example a document service.
            
    
            
    
              
    
              Unless the client tells the AS where it intends to use the
              token we
              
    
              will be leaving a security hole because the bearer tokens
              will have
              
    
              too loose an audience if they have one at all.
              
    
            
    
            This is the biggest risk we have IMHO.
            
    
            
    
              
    
              True you are telling the AS (Webfinger service) what the
              RS is but
              
    
              that is not at a place that is useful in the token
              production process.
              
    
            
    
            
    
            This has nothing to do with token production.
            
    
            
    
            What we want to ensure is whether an honest client is
            correctly
            
    
            configured and has not been mislead - eg by a phishing page.
            
    
            
    
              
    
              I also think there are use cases where the AS doesn=E2=80=99t=
 know
              all the
              
    
              possible RS.=C2=A0=C2=A0 That is not something that a out of =
band
              check can
              
    
              address.
              
    
            
    
            
    
            May be. Lets identify them.
            
    
            
    
            
    There are also cases where a token
              might be good at multiple RS
              
    
              endpoints intentionally.
              
    
            
    
            
    
            
    =C2=A0In your solution the client wou=
ld
              need to make a discovery request
              
    
              for each endpoint.
              
    
            
    
            Sure. Otherwise how would it know if there is one AS or a
            pool of AS
            
    
            servers assigned to each instance?
            
    
            
    Those requests lack the context of
              who the client and resource owner
              
    
              are.=C2=A0 I think that will be a problem in some use cases.
              
    
            
    
            
    
            Not sure I agree. This is about discovering a valid set of
            endpoints.
            
    
            For mitm, we mainly want to check the hostname is correct.
            If a
            
    
            client chooses ev=
il.com <http://evil.c=
om/> the cert
            can be valid and
            
    
            TLS will pass. How does it otherwise know it is supposed to
            talk to
            
    
            res.exampl=
e.com <http://=
res.example.com/>?
            
    
            
    
              
    
              If this is added to the token endpoint it would be checked
              when code
              
    
              or refresh are exchanged, not every time the token is
              used.
              
    
            
    
            Your proposal requires rhe client to check. I am not clear
            how the AS
            
    
            can know the exact uri. It is far easier to validate than to
            lookup
            
    
            since as you say the client may be authorized to use
            multiple ASs.
            
    
            
    With a out of band check the client
              would never know if a RS was
              
    
              removed/revoked.
              
    
            
    
            
    
            Not sure that is in scope.
            
    
            
    
            None of the current proposals address this issue.
            
    
            
    
              
    
              I don=E2=80=99t see checking when refreshing a token as somet=
hing
              that is a
              
    
              huge burden.
              
    
            
    
            
    
            Still its a lot more than once.
            
    
            
    
            Why don't you draft another alternative?
            
    
            
    
              
    
              If the server wants to do the check on it=E2=80=99s side then=
 we
              could
              
    
              require the client to send the RS URI in the token
              request. that way
              
    
              you really know the client is not going to get a token for
              the wrong
              
    
              RS endpoint.
              
    
              If you check out of band in discovery you really have no
              idea if the
              
    
              client is checking.
              
    
            
    
            
    
            In the new webfinger draft, the client isn't checking. The
            service
            
    
            provider simply does not disclose oauth information to
            misconfigured
            
    
            clients.
            
    
            
    
              
    
              John B.
              
    
              
    
              
    
              
    On Mar 14, 2016, at 3:56 PM, Phil
                Hunt <phil.hunt@oracle.com
                
    
                &=
lt;mailto:phil.hunt@oracle.com>> wrote:
                
    
                
    
                Thanks to Mike and John for their feedback.=C2=A0 I=E2=80=
=99ll take
                each in turn:
                
    
                
    
                Mike,
                
    
                
    
                Regarding your suggested amendments
                
    
                
    
                Item 1: Returning the config URL would create two
                problems. One,it
                
    
                makes bound discovery a two-step process - that adds
                complexity.
                
    
                =C2=A0It seems far simpler to mandate TLS (which I think it
                already does
                
    
                in the security considerations).
                
    
                
    
                The two-step process allows the current discovery
                process to
                
    
                continue. I disagree with this. This is why I put
                forward an
                
    
                =E2=80=9Calternate" draft that is almost the same but =
simply
                adds the check
                
    
                before returning the configuration data.=C2=A0 I worry that=
=C2=A0
                developers
                
    
                would have no incentive to do the two-step approach.
                They would
                
    
                just start at step 2 which in turn puts AS=E2=80=99s at ris=
k of
                exposing
                
    
                tokens because it works. This makes OAuth promiscuous.
                
    
                
    
                Regarding existing implementations. Most of those
                implementations
                
    
                are for OIDC.=C2=A0 I think it makes sense for OIDF to
                continue use of
                
    
                OIDC's discovery spec because the UserInfo endpoint is
                well defined
                
    
                and the likelihood of a client mis-informed about the
                resource
                
    
                endpoint is not there.=C2=A0 IMO This does not apply to the
                broader
                
    
                OAuth community.
                
    
                
    
                Item 2:=C2=A0 It may be appropriate to have a separate
                configuration
                
    
                registry specification, but I think we should hold off
                until we
                
    
                have a complete solution and then make the decision what
                drafts
                
    
                should exist and how many pieces.=C2=A0 A big concern is th=
e
                perceived
                
    
                complexity of multiple solutions and multiple drafts.
                
    
                
    
                As to John Bradley=E2=80=99s comments:
                
    
                
    
                Re: Discovery is the wrong place to mitigate threats.
                
    
                I=E2=80=99m confused by this.=C2=A0 Our mandate was to solv=
e a
                security threat
                
    
                by having a discovery specification to prevent clients
                being
                
    
                mis-lead about endpoints (of which resource service is
                one) in an
                
    
                oauth protected exchange.=C2=A0 Maybe what you mean is we
                should not use
                
    
                .well-known of any kind and we should just create a
                =E2=80=9C/Config=E2=80=9D
                
    
                endpoint to OAuth?
                
    
                
    
                Re: Your proposal for MITM mitigation
                
    
                You propose that instead the resource endpoint check
                should be in
                
    
                the oauth protocol itself.=C2=A0 The difference is that
                validation is
                
    
                transferred back to the client to get it right. As well,
                without
                
    
                the client informing the AS, I can=E2=80=99t see a way for =
the
                AS to know
                
    
                what endpoint the client is using.=C2=A0 The webfinger
                approach does
                
    
                this once and only requires that the host name be
                checked in many
                
    
                cases.
                
    
                
    
                As a principle, the members have discussed many times
                that the AS
                
    
                service should do validation when possible =E2=80=94 this w=
as
                particularly
                
    
                true at the Germany meeting when this came up. This is
                why I prefer
                
    
                the client tell the service provider what it intends to
                do and the
                
    
                service provider can fail that request immediately if
                necessary. We
                
    
                don=E2=80=99t have to depend on the developer getting the s=
pec
                correct to
                
    
                fail the correct way.
                
    
                
    
                I worry that adding more parameters to the authz and
                token protocol
                
    
                flows increases complexity and attack surface. It also
                means per
                
    
                authorization validation has to take place vs. a
                one-time
                
    
                validation at config time.=C2=A0 Placing it in the
                configuration lookup
                
    
                phase (whether via web finger or just a special OAuth
                endpoint)
                
    
                seems more appropriate and far less complex - as the
                request itself
                
    
                is simple and has only one parameter. Here we are not
                considered
                
    
                about legitimacy of the client. we=E2=80=99re just concerne=
d
                with the issue
                
    
                "has the client been correctly informed?=E2=80=9D
                
    
                
    
                That said, it may be that when we consider all the use
                cases, some
                
    
                combination of AS protocol and discovery may be both
                needed. I=E2=80=99m
                
    
                not ready to make conclusions about this.=C2=A0 The current
                
    
                oauth-discovery spec seems to put future generic clients
                at risk
                
    
                and that is my primary concern.
                
    
                
    
                Best Regards,
                
    
                
    
                Phil
                
    
                
    
                @independentid
                
    
                www.independentid.com
                <http://www.independentid.com/>
                
    
                p=
hil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 13, 2016, at 10:28 PM,
                  Mike Jones
                  
    
                  <Michael.Jones@microsoft.com
                  <mailto:Michael.Jones@microsoft.com>>
                  
    
                  wrote:
                  
    
                  
    
                  Thanks for posting this, Phil.=C2=A0 It provides a concre=
te
                  example of
                  
    
                  a way that protected resource discovery could be added
                  to
                  
    
                  authorization server metadata discovery, and as such,
                  should
                  
    
                  provide useful input for working group discussions on
                  this topic.
                  
    
                  It=E2=80=99s always great when someone takes the time to =
write
                  an actual
                  
    
                  draft that can be examined and implemented, and I
                  appreciate you
                  
    
                  doing that.
                  
    
                  The content of your draft points out that there
                  appears to be
                  
    
                  complete agreement on what the authorization server
                  metadata
                  
    
                  format should be, which is great!=C2=A0 I=E2=80=99ll note=
 that
                  Section 3 of
                  
    
                  draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthoriz=
ation
                  Server
                  
    
                  Metadata=E2=80=9D is an exact copy of Section 2 of
                  
    
                  draft-ietf-oauth-discovery-01 (with the same title),
                  modulo
                  
    
                  applying a correction suggested by the working group.=C2=
=A0
                  To me this
                  
    
                  suggests that the authorization server metadata
                  definitions in
                  
    
                  draft-ietf-oauth-discovery (which is now the whole
                  normative
                  
    
                  content of the draft) are clearly ready for
                  standardization, since
                  
    
                  even your alternative proposal includes them verbatim.
                  
    
                  Reading your draft, the problem I have with it is that
                  you are
                  
    
                  returning the AS metadata only as a WebFinger
                  response, rather
                  
    
                  than as an https-protected resource published by the
                  authorization
                  
    
                  server.=C2=A0 The choice to only return this via WebFinge=
r
                  makes your
                  
    
                  draft incompatible with most deployed implementations
                  of OAuth
                  
    
                  metadata, including the 22 implementations using it
                  listed
                  
    
                  athttp://openid.net/certification/(see the =E2=80=
=9COP Config=E2=80=9D
                  column in
                  
    
                  the table) andOAuth 2.0 libraries such as Microsoft=E2=80=
=99s
                  =E2=80=9CADAL=E2=80=9D
                  
    
                  library, which uses the metadata path for client
                  configuration.
                  
    
                  Without having ASs provide the metadata as an
                  https-protected
                  
    
                  resource, implementations such as ADAL can=E2=80=99t use =
it
                  for client
                  
    
                  configuration as the currently do.
                  
    
                  Therefore, I would request that you make these minor
                  revisions to
                  
    
                  your draft and republish, so as to provide a unified
                  way forward
                  
    
                  that is compatible with all known existing OAuth
                  Discovery
                  
    
                  deployments:
                  
    
                  1.Modify your section 2 =E2=80=9CAuthorization Server
                  WebFinger Discovery=E2=80=9D
                  
    
                  to have the WebFinger request return the issuer
                  identifier for the
                  
    
                  AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value,=
 rather than
                  returning the
                  
    
                  metadata values by value as the =E2=80=9Cproperties=E2=80=
=9D value.
                  
    
                  2.Reference the metadata definitions from Section 2 of
                  
    
                  draft-ietf-oauth-discovery, rather than duplicating
                  them in your
                  
    
                  Section 3.
                  
    
                  That would have the advantage of paring your draft
                  down to only
                  
    
                  the new things that it proposes, enabling them to be
                  more clearly
                  
    
                  understood and evaluated on their own merits.=C2=A0 I loo=
k
                  forward to
                  
    
                  the discussions of ways of performing additional kinds
                  of OAuth
                  
    
                  discovery, and consider your draft a valuable input to
                  those
                  
    
                  discussions.
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  Best wishes,
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  -- Mike
                  
    
                  *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf
                  Of*John Bradley
                  
    
                  *Sent:*Sunday, March 13, 2016 6:45 PM
                  
    
                  *To:*Phil Hunt <phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>>
                  
    
                  *Cc:*oauth <oauth@ietf.org
                  <m=
ailto:oauth@ietf.org>>
                  
    
                  *Subject:*Re: [OAUTH-WG] New Version Notification for
                  
    
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  As I have told Phil off list.
                  
    
                  Discovery is the wrong place to try and provide
                  security against
                  
    
                  man in the middle attacks on the RS.
                  
    
                  This requires the client to know what the RS URI is
                  before
                  
    
                  retrieving the information on the AS Configuration.
                  
    
                  The proposal Mike and I have been working on requires
                  the client
                  
    
                  to have a notion of what API it is looking for and
                  retrieve the
                  
    
                  .well-known file for that API from the issuer.=C2=A0=C2=
=A0 That
                  allows a
                  
    
                  protocol like Connect to register its own config file
                  that can
                  
    
                  point to the RS.
                  
    
                  If the API specific well known is not available the
                  client can try
                  
    
                  the default oauth-server one.
                  
    
                  That then allows us to deal with restricting where AT
                  are
                  
    
                  presented as part of the protocol rather then dragging
                  discovery
                  
    
                  in as a requirement.
                  
    
                  In my opinion the resource the token is targeted to
                  should be
                  
    
                  separated from the scope and returned as part of the
                  meta-data
                  
    
                  about the AT along with scopes granted and expiry
                  time.=C2=A0=C2=A0 We
                  
    
                  should also have a input parameter for resources so
                  that a client
                  
    
                  can restrict tokens issued to a subset of the ones
                  granted by the
                  
    
                  refresh token.=C2=A0=C2=A0 It would then also be possible=
 to ask
                  a AS for a
                  
    
                  token for a unregistered RS and have the AS produce a
                  JWT access
                  
    
                  token with the resource as an audience if policy
                  allows.
                  
    
                  That however was supposed to be dealt with as part of
                  the mixed up
                  
    
                  client set of mitigations.
                  
    
                  In that the goal was to mitigate the attacks by
                  returning
                  
    
                  meta-data about the tokens, and not to require
                  discovery.
                  
    
                  We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccl=
eint_id=E2=80=9D for the
                  code, and I
                  
    
                  intend to discuss at the F2F returning resource for AT
                  as well.
                  
    
                  Those mitigate the attack.
                  
    
                  I will continue to resist mixing up discovery of
                  configuration
                  
    
                  meta-data with mitigation of the attacks.
                  
    
                  We return meta-data about the tokens now, because AT
                  are opaque to
                  
    
                  the client, we neglected to include some of the
                  information for
                  
    
                  the client needs to be secure.=C2=A0=C2=A0 We just need t=
o add
                  that in to
                  
    
                  the existing flows.
                  
    
                  While Phil=E2=80=99s proposal is easier for the AS to
                  implement as an add
                  
    
                  on, it puts more of a burden on the client needing to
                  potentially
                  
    
                  change how it stores the relationships between AS and
                  RS to
                  
    
                  prevent compromise, I think the solution should be
                  biased towards
                  
    
                  simplicity on the client side.
                  
    
                  If we return the resources as part of the existing
                  meta data the
                  
    
                  client checks that against the resource it intends to
                  send the
                  
    
                  token to and if it is not in the list then it can=E2=80=
=99t
                  send the
                  
    
                  token.=C2=A0 Simple check every time it gets a new AT, no
                  optionality.
                  
    
                  I am not saying anything new Nat has been advocating
                  basically
                  
    
                  this for some time, and dis submit a draft.=C2=A0=C2=A0 I=
 prefer
                  to return
                  
    
                  the info in the existing format rather than as link
                  headers,=C2=A0 but
                  
    
                  that is the largest difference between what Nat and I
                  are saying
                  
    
                  with respect to resource.
                  
    
                  That is the core of my problem with Phil=E2=80=99s draft.
                  
    
                  I guess we will need to have a long conversation in
                  BA.
                  
    
                  Regards
                  
    
                  John B.
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0 On Mar 13, 2016, at 8:12 PM, Phil Hunt
                  <phil.hunt@oracle.com
                  
    
                  =C2=A0=C2=A0=C2=A0 <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                  =C2=A0=C2=A0=C2=A0 This draft is a proposed alternate pro=
posal for
                  
    
                  =C2=A0=C2=A0=C2=A0 draft-ietf-oauth-discovery.=C2=A0 As s=
uch, it contains
                  the same
                  
    
                  =C2=A0=C2=A0=C2=A0 registry for OAuth Config Metadata as =
the authors
                  believe that
                  
    
                  =C2=A0=C2=A0=C2=A0 both solutions are not required, or de=
pending on
                  WG discussion
                  
    
                  =C2=A0=C2=A0=C2=A0 they will be merged. The intent is to =
provide a
                  simple
                  
    
                  =C2=A0=C2=A0=C2=A0 complete draft for consideration.
                  
    
                  =C2=A0=C2=A0=C2=A0 How it works...
                  
    
                  =C2=A0=C2=A0=C2=A0 Given that a client has previously dis=
covered an
                  OAuth
                  
    
                  =C2=A0=C2=A0=C2=A0 protected resource, the bound configur=
ation method
                  allows a
                  
    
                  =C2=A0=C2=A0=C2=A0 client to return the configuration for=
 an oauth
                  authorization
                  
    
                  =C2=A0=C2=A0=C2=A0 server that can issue tokens for the r=
esource URI
                  specified by
                  
    
                  =C2=A0=C2=A0=C2=A0 the client.=C2=A0 The AS is not requir=
ed to be in the
                  same domain.
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0 The AS is however required to kn=
ow if it can
                  issue tokens for
                  
    
                  =C2=A0=C2=A0=C2=A0 a resource service (which presumes som=
e agreement
                  exists on
                  
    
                  =C2=A0=C2=A0=C2=A0 tokens etc).
                  
    
                  =C2=A0=C2=A0=C2=A0 The draft does not require that the re=
source exist
                  (e.g. for
                  
    
                  =C2=A0=C2=A0=C2=A0 unconfigured or new user based resourc=
es). It only
                  requires
                  
    
                  =C2=A0=C2=A0=C2=A0 that the AS service provider agrees it=
 can issue
                  tokens.
                  
    
                  =C2=A0=C2=A0=C2=A0 From a security perspective, returning=
 the OAuth
                  service
                  
    
                  =C2=A0=C2=A0=C2=A0 configuration for a specified resource=
 URI serves
                  to confirm
                  
    
                  =C2=A0=C2=A0=C2=A0 the client is in possession of a valid=
 resource
                  URI ensuring
                  
    
                  =C2=A0=C2=A0=C2=A0 the client has received a valid set of=
 endpoints
                  for the
                  
    
                  =C2=A0=C2=A0=C2=A0 resource and the associated oauth serv=
ices.
                  
    
                  =C2=A0=C2=A0=C2=A0 I propose that the WG consider the alt=
ernate draft
                  carefully
                  
    
                  =C2=A0=C2=A0=C2=A0 as well as other submissions and evalu=
ate the
                  broader
                  
    
                  =C2=A0=C2=A0=C2=A0 discovery problem before proceeding wi=
th WGLC on
                  OAuth Discovery.
                  
    
                  =C2=A0=C2=A0=C2=A0 Thanks!
                  
    
                  =C2=A0=C2=A0=C2=A0 Phil
                  
    
                  =C2=A0=C2=A0=C2=A0 @independentid
                  
    
                  =C2=A0=C2=A0=C2=A0 www.independentid.com
                  <http://www.independentid.com/>
                  
    
                  =C2=A0=C2=A0=C2=A0 phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Begin forwarde=
d message:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *From:*internet-drafts@ietf=
.org
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:internet-drafts@=
ietf.org>
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Subject: New =
Version Notification for
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-hunt-oau=
th-bound-config-00.txt*
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Date:*March 1=
3, 2016 at 3:53:37 PM PDT
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *To:*"Phi=
l Hunt" <p=
hil.hunt@yahoo.com
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:phil.hunt@yahoo.com&g=
t;>,
                  "Anthony Nadalin"
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <tonynad@microsoft.com
                  <mailto:tonynad@microsoft.com>>,
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Tony Nad=
alin" <t=
onynad@microsoft.com
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:tonynad@microsoft.c=
om>>
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A new version =
of I-D,
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has been succe=
ssfully submitted by Phil Hunt
                  and posted to the
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IETF repositor=
y.
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Name:draft-hun=
t-oauth-bound-config
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Revision:00
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title:OAuth 2.=
0 Bound Configuration Lookup
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Document date:=
2016-03-13
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Group:Individu=
al Submission
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pages:22
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URL:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
https://www.ietf.org/internet-drafts/draft-hun=
t-oauth-bound-config-00.txt
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Status:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  https://datatracker.ietf.org/doc/draft=
-hunt-oauth-bound-config/
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Htmlized:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  https://tools.ietf.org/html/draft-hunt-oa=
uth-bound-config-00
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Abstract:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Th=
is specification defines a mechanism for
                  the client of
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an OAuth 2.0
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pr=
otected resource service to obtain the
                  configuration
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 details of an
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OA=
uth 2.0 authorization server that is
                  capable of
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorizing ac=
cess
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to=
 a specific resource service.=C2=A0 The
                  information
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 includes the O=
Auth
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.=
0 component endpoint location URIs and as
                  well as
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 se=
rver capabilities.
                  
    
                  
    
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please note th=
at it may take a couple of
                  minutes from the
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 time of submis=
sion
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 until the html=
ized version and diff are
                  available
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attools.ietf.org
                  <=
http://tools.ietf.org/>.
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The IETF Secre=
tariat
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0 ______________________________________=
_________
                  
    
                  =C2=A0=C2=A0=C2=A0 OAuth mailing list
                  
    
                  =C2=A0=C2=A0=C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                  =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/o=
auth
                  
    
                
    
                
    
              
    
              
    
            
    
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.or=
g <mailto:OAuth@=
ietf.org>
          
    
          https://www.ietf.org/mailman/listinfo/oauth
          
    
        
    
        
    
        
    
        
    
        _______________________________________________
        
    
        OAuth mailing list
        
    
        OAuth@ietf.org<=
/a>
        
    
            https://www.ietf.org/mailman/listinfo/oauth
        
    
        
    
      
    
      
    
    
    
    
    
  
    




    ______________________________=
_________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    


    

--089e010d93784f9ac0052e184e92--


From nobody Tue Mar 15 08:54:56 2016
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 D883D12DA74 for ; Tue, 15 Mar 2016 08:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 nLA5wDG-dY3b for ; Tue, 15 Mar 2016 08:54:50 -0700 (PDT)
Received: from omr-a006e.mx.aol.com (omr-a006e.mx.aol.com [204.29.186.55]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8887C12D948 for ; Tue, 15 Mar 2016 08:54:49 -0700 (PDT)
Received: from mtaout-aad01.mx.aol.com (mtaout-aad01.mx.aol.com [172.26.127.225]) by omr-a006e.mx.aol.com (Outbound Mail Relay) with ESMTP id 81550380009A; Tue, 15 Mar 2016 11:54:48 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aad01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9764338000098; Tue, 15 Mar 2016 11:54:47 -0400 (EDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E83047.8090908@aol.com>
Date: Tue, 15 Mar 2016 11:54:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------070904020201050001060202"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458057288; bh=yu+qEzjPh/D+F5+Rws0Mgx7c1Rb+ISucRu1JQYBsPrE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=bIGfqHncj1AvMbhtiQGfqW13M3Ly4vTgsaAZ3WKAuUjfB77Sp2whpi4lpDnJe7HZ2 V7PWg3Gai20Et1Z6X6QqTFQja/mL2M7RjfHnx3Ldkxb2ZRxFw6WigonDBVEm+qU/WI ncil8NHy6a0IeuS5mwgaoxQ+zL5zIsQ/eBuPxPKg=
x-aol-sid: 3039ac1a7fe156e830472269
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 15:54:55 -0000

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

I'm not against binding audiences to a token. (Note that in many 
deployments today, a single access token can be used at many endpoints 
representing different services. It's not uncommon for a client to 
request a token to access the mail endpoints, messaging endpoints, 
contacts endpoints, etc. This requires the ability to associate multiple 
audiences to a single token.)

The issue is whether it's possible to represent the RS with an abstract 
audience identifier (e.g. URN?) rather than a specific endpoint. Taking 
this approach provides a level of indirection that is much easier to 
configure. The AS likely knows (or can be configured) that it supports a 
Instant-Messaging RS. The client can then use some other mechanism to 
determine the exact endpoint of that abstract audience identifier. This 
keeps the relationships defined without the tight-coupling of 
registering endpoints (even with wild cards).

Now if the direction is to move to a token can only have one audience, 
to me that isn't OAuth2. It's a perfectly fine model, but we should be 
addressing that as the next gen spec, not trying to layer it on the 
existing one that has different deployment semantics.

Thanks,
George

On 3/15/16 11:37 AM, John Bradley wrote:
> Yes,  I think bearer tokens with no audience are a bad idea.
>
> The AS needs to infer an audience from the scopes snd/or have the 
> client specify the desired audience.
>
> If the AT has a audience or audiences then as long as the endpoint URI 
> are provided as meta-data with the token, the client can determine if 
> it is sending the token to the correct place.
>
> I think Phil would prefer the server rather than the client do the 
> check, but the client always needs to take some responsibility to not 
> leak tokens giving them to the wrong RS or the code to the wrong token 
> endpoint is leaking.
>
> I imagine that claims based access tokens are going to become more 
> popular and the static relationship between one RS and one AS will not 
> be the majority of deployments over time.
>
> In any case where the client is configured up front to know the RS and 
> the AS it seems like that would not require Phil’s Solution, but that 
> is the only case supported by that discovery.
> If the client itself is bad there is not much you can do to stop it 
> from passing on the AT in way way it wants.  That however is a 
> different problem and needs claimed URI or attestations to prevent 
> client spoofing.
> William and I are working on that in the mobile best practices draft.
>
> John B.
>
>
>> On Mar 15, 2016, at 12:09 PM, George Fletcher > > wrote:
>>
>> I worry about two directions I see in this thread...
>>
>> 1. Client's accessing resources dynamically so that discovery is 
>> required to know the correct AS, etc. This is pretty much the classic 
>> use case for UMA and I'd rather not re-invent the wheel.
>>
>> 2. Creating a tight coupling between RS and AS such that RS endpoint 
>> changes must be continually communicated to the AS. If an RS supports 
>> multiple AS's then the RS has to deal with "guaranteed" delivery. The 
>> AS needs an endpoint to receive such communications. If not dynamic 
>> via APIs, then deployment of the new RS is bound by the associated 
>> AS's getting and deploying the new endpoints. Can both endpoints of 
>> the RS be supported within the AS for some period of time, etc. This 
>> is an operation nightmare and almost assuredly going to go wrong in 
>> production.
>>
>> Maybe an OAuth2 "audience binding" spec is what's needed for those 
>> deployments that require this. I believe that is what John Bradley is 
>> suggesting.
>>
>> Thanks,
>> George
>>
>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>> +1, I've found the very same in OAuth deployments that I was 
>>> involved in; the hard part is to give names and descriptions to 
>>> these concepts so that they cover all use cases and can be applied 
>>> unambiguously
>>>
>>> Hans.
>>>
>>> On 3/14/16 10:44 PM, Justin Richer wrote:
>>>> I agree that this is valuable, and not just for PoP. In all honesty,
>>>> it’s not even really required for PoP to function in many cases — it’s
>>>> just an optimization for one particular kind of key distribution
>>>> mechanism in that case.
>>>>
>>>> In the years of deployment experience with OAuth 2, I think we’ve 
>>>> really
>>>> got three different kinds of things that currently get folded into
>>>> “scope†that we might want to try separating out better:
>>>>
>>>>
>>>>   - What things do I want to access? (photos, profile)
>>>>   - What actions do I want to take on these things? (read, write, 
>>>> delete)
>>>>   - How long do I want these tokens to work?
>>>> (offline_access/refresh_token, one time use, next hour, etc)
>>>>
>>>>
>>>> I think the first one is close to the audience/resource parameters 
>>>> that
>>>> have been bandied about a few times, including in the current token
>>>> exchange document. We should be consistent across drafts in that 
>>>> regard.
>>>> The second is more traditional scope-ish. The third has been 
>>>> patched in
>>>> with things like “offline_access†in certain APIs.
>>>>
>>>> Just another vector to think about if we’re going to be adding things
>>>> like “audience†or “resource†or both to the token requests.
>>>>
>>>>   — Justin
>>>>
>>>>
>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>> > wrote:
>>>>>
>>>>> Yes I will work on another proposal for allowing clients to specify
>>>>> what resource they want a token for and providing the meta-data to 
>>>>> the
>>>>> client about the resources that a token is valid for.
>>>>>
>>>>> We have part of it in the POP key distribution spec and talked about
>>>>> separating it, as it is used more places than just for assigning 
>>>>> keys.
>>>>> I know some AS use different token formats for different RS so are
>>>>> all-ready needing to pass the resource in the request to avoid making
>>>>> a mess of scopes.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>> > wrote:
>>>>>>
>>>>>> Inline
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>> > wrote:
>>>>>>
>>>>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>>>>> The other was to mitigate the client mixup attack.  The request was
>>>>>>> to do the latter without requiring the former for clients that 
>>>>>>> don’t
>>>>>>> otherwise need discovery.
>>>>>> There is no mandate for any of this. See
>>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
>>>>>>
>>>>>>>
>>>>>>> Returning the issuer and client_id from the authorization endpoint
>>>>>>> and the client checking them can be done by the client without
>>>>>>> discovery.
>>>>>>
>>>>>> How does this address the issue of whether the client is talking to
>>>>>> the wrong endpoint?
>>>>>>>
>>>>>>> Any client that has the resource and issuer hard coded probably
>>>>>>> doesn’t need discovery.
>>>>>> We agree
>>>>>>
>>>>>>
>>>>>>> One of the things that a client will need discovery for is to find
>>>>>>> the RS, so requiring the client to know the RS URI before getting
>>>>>>> the AS config seems backwards to me.
>>>>>> How can you make an assumption on order? You seem to be conflating
>>>>>> authentication with authorization by assuming the identity drives
>>>>>> what the resource is.
>>>>>>
>>>>>> There are lots of applications that require user rights but are not
>>>>>> identify centric. For example a document service.
>>>>>>>
>>>>>>> Unless the client tells the AS where it intends to use the token we
>>>>>>> will be leaving a security hole because the bearer tokens will have
>>>>>>> too loose an audience if they have one at all.
>>>>>> This is the biggest risk we have IMHO.
>>>>>>>
>>>>>>> True you are telling the AS (Webfinger service) what the RS is but
>>>>>>> that is not at a place that is useful in the token production 
>>>>>>> process.
>>>>>>
>>>>>> This has nothing to do with token production.
>>>>>>
>>>>>> What we want to ensure is whether an honest client is correctly
>>>>>> configured and has not been mislead - eg by a phishing page.
>>>>>>>
>>>>>>> I also think there are use cases where the AS doesn’t know all the
>>>>>>> possible RS.   That is not something that a out of band check can
>>>>>>> address.
>>>>>>
>>>>>> May be. Lets identify them.
>>>>>>
>>>>>>> There are also cases where a token might be good at multiple RS
>>>>>>> endpoints intentionally.
>>>>>>
>>>>>>>  In your solution the client would need to make a discovery request
>>>>>>> for each endpoint.
>>>>>> Sure. Otherwise how would it know if there is one AS or a pool of AS
>>>>>> servers assigned to each instance?
>>>>>>> Those requests lack the context of who the client and resource 
>>>>>>> owner
>>>>>>> are.  I think that will be a problem in some use cases.
>>>>>>
>>>>>> Not sure I agree. This is about discovering a valid set of 
>>>>>> endpoints.
>>>>>> For mitm, we mainly want to check the hostname is correct. If a
>>>>>> client chooses evil.com   the 
>>>>>> cert can be valid and
>>>>>> TLS will pass. How does it otherwise know it is supposed to talk to
>>>>>> res.example.com  ?
>>>>>>>
>>>>>>> If this is added to the token endpoint it would be checked when 
>>>>>>> code
>>>>>>> or refresh are exchanged, not every time the token is used.
>>>>>> Your proposal requires rhe client to check. I am not clear how 
>>>>>> the AS
>>>>>> can know the exact uri. It is far easier to validate than to lookup
>>>>>> since as you say the client may be authorized to use multiple ASs.
>>>>>>> With a out of band check the client would never know if a RS was
>>>>>>> removed/revoked.
>>>>>>
>>>>>> Not sure that is in scope.
>>>>>>
>>>>>> None of the current proposals address this issue.
>>>>>>>
>>>>>>> I don’t see checking when refreshing a token as something that is a
>>>>>>> huge burden.
>>>>>>
>>>>>> Still its a lot more than once.
>>>>>>
>>>>>> Why don't you draft another alternative?
>>>>>>>
>>>>>>> If the server wants to do the check on it’s side then we could
>>>>>>> require the client to send the RS URI in the token request. that 
>>>>>>> way
>>>>>>> you really know the client is not going to get a token for the 
>>>>>>> wrong
>>>>>>> RS endpoint.
>>>>>>> If you check out of band in discovery you really have no idea if 
>>>>>>> the
>>>>>>> client is checking.
>>>>>>
>>>>>> In the new webfinger draft, the client isn't checking. The service
>>>>>> provider simply does not disclose oauth information to misconfigured
>>>>>> clients.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Thanks to Mike and John for their feedback. I’ll take each in 
>>>>>>>> turn:
>>>>>>>>
>>>>>>>> Mike,
>>>>>>>>
>>>>>>>> Regarding your suggested amendments
>>>>>>>>
>>>>>>>> Item 1: Returning the config URL would create two problems. One,it
>>>>>>>> makes bound discovery a two-step process - that adds complexity.
>>>>>>>>  It seems far simpler to mandate TLS (which I think it already 
>>>>>>>> does
>>>>>>>> in the security considerations).
>>>>>>>>
>>>>>>>> The two-step process allows the current discovery process to
>>>>>>>> continue. I disagree with this. This is why I put forward an
>>>>>>>> “alternate" draft that is almost the same but simply adds the 
>>>>>>>> check
>>>>>>>> before returning the configuration data.  I worry that  developers
>>>>>>>> would have no incentive to do the two-step approach. They would
>>>>>>>> just start at step 2 which in turn puts AS’s at risk of exposing
>>>>>>>> tokens because it works. This makes OAuth promiscuous.
>>>>>>>>
>>>>>>>> Regarding existing implementations. Most of those implementations
>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use of
>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well 
>>>>>>>> defined
>>>>>>>> and the likelihood of a client mis-informed about the resource
>>>>>>>> endpoint is not there.  IMO This does not apply to the broader
>>>>>>>> OAuth community.
>>>>>>>>
>>>>>>>> Item 2:  It may be appropriate to have a separate configuration
>>>>>>>> registry specification, but I think we should hold off until we
>>>>>>>> have a complete solution and then make the decision what drafts
>>>>>>>> should exist and how many pieces.  A big concern is the perceived
>>>>>>>> complexity of multiple solutions and multiple drafts.
>>>>>>>>
>>>>>>>> As to John Bradley’s comments:
>>>>>>>>
>>>>>>>> Re: Discovery is the wrong place to mitigate threats.
>>>>>>>> I’m confused by this.  Our mandate was to solve a security threat
>>>>>>>> by having a discovery specification to prevent clients being
>>>>>>>> mis-lead about endpoints (of which resource service is one) in an
>>>>>>>> oauth protected exchange.  Maybe what you mean is we should not 
>>>>>>>> use
>>>>>>>> .well-known of any kind and we should just create a “/Configâ€
>>>>>>>> endpoint to OAuth?
>>>>>>>>
>>>>>>>> Re: Your proposal for MITM mitigation
>>>>>>>> You propose that instead the resource endpoint check should be in
>>>>>>>> the oauth protocol itself.  The difference is that validation is
>>>>>>>> transferred back to the client to get it right. As well, without
>>>>>>>> the client informing the AS, I can’t see a way for the AS to know
>>>>>>>> what endpoint the client is using.  The webfinger approach does
>>>>>>>> this once and only requires that the host name be checked in many
>>>>>>>> cases.
>>>>>>>>
>>>>>>>> As a principle, the members have discussed many times that the AS
>>>>>>>> service should do validation when possible — this was particularly
>>>>>>>> true at the Germany meeting when this came up. This is why I 
>>>>>>>> prefer
>>>>>>>> the client tell the service provider what it intends to do and the
>>>>>>>> service provider can fail that request immediately if 
>>>>>>>> necessary. We
>>>>>>>> don’t have to depend on the developer getting the spec correct to
>>>>>>>> fail the correct way.
>>>>>>>>
>>>>>>>> I worry that adding more parameters to the authz and token 
>>>>>>>> protocol
>>>>>>>> flows increases complexity and attack surface. It also means per
>>>>>>>> authorization validation has to take place vs. a one-time
>>>>>>>> validation at config time.  Placing it in the configuration lookup
>>>>>>>> phase (whether via web finger or just a special OAuth endpoint)
>>>>>>>> seems more appropriate and far less complex - as the request 
>>>>>>>> itself
>>>>>>>> is simple and has only one parameter. Here we are not considered
>>>>>>>> about legitimacy of the client. we’re just concerned with the 
>>>>>>>> issue
>>>>>>>> "has the client been correctly informed?â€
>>>>>>>>
>>>>>>>> That said, it may be that when we consider all the use cases, some
>>>>>>>> combination of AS protocol and discovery may be both needed. I’m
>>>>>>>> not ready to make conclusions about this. The current
>>>>>>>> oauth-discovery spec seems to put future generic clients at risk
>>>>>>>> and that is my primary concern.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> @independentid
>>>>>>>> www.independentid.com 
>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>> >>>>>>>> >
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete example of
>>>>>>>>> a way that protected resource discovery could be added to
>>>>>>>>> authorization server metadata discovery, and as such, should
>>>>>>>>> provide useful input for working group discussions on this topic.
>>>>>>>>> It’s always great when someone takes the time to write an actual
>>>>>>>>> draft that can be examined and implemented, and I appreciate you
>>>>>>>>> doing that.
>>>>>>>>> The content of your draft points out that there appears to be
>>>>>>>>> complete agreement on what the authorization server metadata
>>>>>>>>> format should be, which is great!  I’ll note that Section 3 of
>>>>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server
>>>>>>>>> Metadata†is an exact copy of Section 2 of
>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>>>>>>>>> applying a correction suggested by the working group.  To me this
>>>>>>>>> suggests that the authorization server metadata definitions in
>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative
>>>>>>>>> content of the draft) are clearly ready for standardization, 
>>>>>>>>> since
>>>>>>>>> even your alternative proposal includes them verbatim.
>>>>>>>>> Reading your draft, the problem I have with it is that you are
>>>>>>>>> returning the AS metadata only as a WebFinger response, rather
>>>>>>>>> than as an https-protected resource published by the 
>>>>>>>>> authorization
>>>>>>>>> server.  The choice to only return this via WebFinger makes your
>>>>>>>>> draft incompatible with most deployed implementations of OAuth
>>>>>>>>> metadata, including the 22 implementations using it listed
>>>>>>>>> athttp://openid.net/certification/(see the “OP Config†column in
>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft’s “ADALâ€
>>>>>>>>> library, which uses the metadata path for client configuration.
>>>>>>>>> Without having ASs provide the metadata as an https-protected
>>>>>>>>> resource, implementations such as ADAL can’t use it for client
>>>>>>>>> configuration as the currently do.
>>>>>>>>> Therefore, I would request that you make these minor revisions to
>>>>>>>>> your draft and republish, so as to provide a unified way forward
>>>>>>>>> that is compatible with all known existing OAuth Discovery
>>>>>>>>> deployments:
>>>>>>>>> 1.Modify your section 2 “Authorization Server WebFinger 
>>>>>>>>> Discoveryâ€
>>>>>>>>> to have the WebFinger request return the issuer identifier for 
>>>>>>>>> the
>>>>>>>>> AS as the “WebFinger “rel†value, rather than returning the
>>>>>>>>> metadata values by value as the “properties†value.
>>>>>>>>> 2.Reference the metadata definitions from Section 2 of
>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in your
>>>>>>>>> Section 3.
>>>>>>>>> That would have the advantage of paring your draft down to only
>>>>>>>>> the new things that it proposes, enabling them to be more clearly
>>>>>>>>> understood and evaluated on their own merits.  I look forward to
>>>>>>>>> the discussions of ways of performing additional kinds of OAuth
>>>>>>>>> discovery, and consider your draft a valuable input to those
>>>>>>>>> discussions.
>>>>>>>>> Best wishes,
>>>>>>>>> -- Mike
>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*John 
>>>>>>>>> Bradley
>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>> *To:*Phil Hunt >>>>>>>> >
>>>>>>>>> *Cc:*oauth >
>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>> As I have told Phil off list.
>>>>>>>>> Discovery is the wrong place to try and provide security against
>>>>>>>>> man in the middle attacks on the RS.
>>>>>>>>> This requires the client to know what the RS URI is before
>>>>>>>>> retrieving the information on the AS Configuration.
>>>>>>>>> The proposal Mike and I have been working on requires the client
>>>>>>>>> to have a notion of what API it is looking for and retrieve the
>>>>>>>>> .well-known file for that API from the issuer.   That allows a
>>>>>>>>> protocol like Connect to register its own config file that can
>>>>>>>>> point to the RS.
>>>>>>>>> If the API specific well known is not available the client can 
>>>>>>>>> try
>>>>>>>>> the default oauth-server one.
>>>>>>>>> That then allows us to deal with restricting where AT are
>>>>>>>>> presented as part of the protocol rather then dragging discovery
>>>>>>>>> in as a requirement.
>>>>>>>>> In my opinion the resource the token is targeted to should be
>>>>>>>>> separated from the scope and returned as part of the meta-data
>>>>>>>>> about the AT along with scopes granted and expiry time.   We
>>>>>>>>> should also have a input parameter for resources so that a client
>>>>>>>>> can restrict tokens issued to a subset of the ones granted by the
>>>>>>>>> refresh token.   It would then also be possible to ask a AS for a
>>>>>>>>> token for a unregistered RS and have the AS produce a JWT access
>>>>>>>>> token with the resource as an audience if policy allows.
>>>>>>>>> That however was supposed to be dealt with as part of the 
>>>>>>>>> mixed up
>>>>>>>>> client set of mitigations.
>>>>>>>>> In that the goal was to mitigate the attacks by returning
>>>>>>>>> meta-data about the tokens, and not to require discovery.
>>>>>>>>> We intend to return “iss†and “cleint_id†for the code, and I
>>>>>>>>> intend to discuss at the F2F returning resource for AT as well.
>>>>>>>>> Those mitigate the attack.
>>>>>>>>> I will continue to resist mixing up discovery of configuration
>>>>>>>>> meta-data with mitigation of the attacks.
>>>>>>>>> We return meta-data about the tokens now, because AT are 
>>>>>>>>> opaque to
>>>>>>>>> the client, we neglected to include some of the information for
>>>>>>>>> the client needs to be secure.   We just need to add that in to
>>>>>>>>> the existing flows.
>>>>>>>>> While Phil’s proposal is easier for the AS to implement as an add
>>>>>>>>> on, it puts more of a burden on the client needing to potentially
>>>>>>>>> change how it stores the relationships between AS and RS to
>>>>>>>>> prevent compromise, I think the solution should be biased towards
>>>>>>>>> simplicity on the client side.
>>>>>>>>> If we return the resources as part of the existing meta data the
>>>>>>>>> client checks that against the resource it intends to send the
>>>>>>>>> token to and if it is not in the list then it can’t send the
>>>>>>>>> token.  Simple check every time it gets a new AT, no optionality.
>>>>>>>>> I am not saying anything new Nat has been advocating basically
>>>>>>>>> this for some time, and dis submit a draft.   I prefer to return
>>>>>>>>> the info in the existing format rather than as link headers,  but
>>>>>>>>> that is the largest difference between what Nat and I are saying
>>>>>>>>> with respect to resource.
>>>>>>>>> That is the core of my problem with Phil’s draft.
>>>>>>>>> I guess we will need to have a long conversation in BA.
>>>>>>>>> Regards
>>>>>>>>> John B.
>>>>>>>>>
>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt >>>>>>>> > wrote:
>>>>>>>>>     This draft is a proposed alternate proposal for
>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same
>>>>>>>>>     registry for OAuth Config Metadata as the authors believe 
>>>>>>>>> that
>>>>>>>>>     both solutions are not required, or depending on WG 
>>>>>>>>> discussion
>>>>>>>>>     they will be merged. The intent is to provide a simple
>>>>>>>>>     complete draft for consideration.
>>>>>>>>>     How it works...
>>>>>>>>>     Given that a client has previously discovered an OAuth
>>>>>>>>>     protected resource, the bound configuration method allows a
>>>>>>>>>     client to return the configuration for an oauth authorization
>>>>>>>>>     server that can issue tokens for the resource URI 
>>>>>>>>> specified by
>>>>>>>>>     the client.  The AS is not required to be in the same domain.
>>>>>>>>>      The AS is however required to know if it can issue tokens 
>>>>>>>>> for
>>>>>>>>>     a resource service (which presumes some agreement exists on
>>>>>>>>>     tokens etc).
>>>>>>>>>     The draft does not require that the resource exist (e.g. for
>>>>>>>>>     unconfigured or new user based resources). It only requires
>>>>>>>>>     that the AS service provider agrees it can issue tokens.
>>>>>>>>>     From a security perspective, returning the OAuth service
>>>>>>>>>     configuration for a specified resource URI serves to confirm
>>>>>>>>>     the client is in possession of a valid resource URI ensuring
>>>>>>>>>     the client has received a valid set of endpoints for the
>>>>>>>>>     resource and the associated oauth services.
>>>>>>>>>     I propose that the WG consider the alternate draft carefully
>>>>>>>>>     as well as other submissions and evaluate the broader
>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth 
>>>>>>>>> Discovery.
>>>>>>>>>     Thanks!
>>>>>>>>>     Phil
>>>>>>>>>     @independentid
>>>>>>>>> www.independentid.com 
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Begin forwarded message:
>>>>>>>>>         *From:*internet-drafts@ietf.org 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>         *Subject: New Version Notification for
>>>>>>>>> draft-hunt-oauth-bound-config-00.txt*
>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>> >, "Anthony Nadalin"
>>>>>>>>>         >,
>>>>>>>>>         "Tony Nadalin" >>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         A new version of I-D, 
>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>         has been successfully submitted by Phil Hunt and 
>>>>>>>>> posted to the
>>>>>>>>>         IETF repository.
>>>>>>>>>
>>>>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>>>>         Revision:00
>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>>>         Document date:2016-03-13
>>>>>>>>>         Group:Individual Submission
>>>>>>>>>         Pages:22
>>>>>>>>>         URL:
>>>>>>>>> https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>         Status:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>>>         Htmlized:
>>>>>>>>> https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Abstract:
>>>>>>>>>           This specification defines a mechanism for the 
>>>>>>>>> client of
>>>>>>>>>         an OAuth 2.0
>>>>>>>>>           protected resource service to obtain the configuration
>>>>>>>>>         details of an
>>>>>>>>>           OAuth 2.0 authorization server that is capable of
>>>>>>>>>         authorizing access
>>>>>>>>>           to a specific resource service. The information
>>>>>>>>>         includes the OAuth
>>>>>>>>>           2.0 component endpoint location URIs and as well as
>>>>>>>>>         authorization
>>>>>>>>>           server capabilities.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Please note that it may take a couple of minutes from the
>>>>>>>>>         time of submission
>>>>>>>>>         until the htmlized version and diff are available
>>>>>>>>> attools.ietf.org  
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>         The IETF Secretariat
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>>     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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>
>


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


  
    
  
  
    I'm not against binding
      audiences to a token. (Note that in many deployments today, a
      single access token can be used at many endpoints representing
      different services. It's not uncommon for a client to request a
      token to access the mail endpoints, messaging endpoints, contacts
      endpoints, etc. This requires the ability to associate multiple
      audiences to a single token.)
    
      
    
      The issue is whether it's possible to represent the RS with an
      abstract audience identifier (e.g. URN?) rather than a specific
      endpoint. Taking this approach provides a level of indirection
      that is much easier to configure. The AS likely knows (or can be
      configured) that it supports a Instant-Messaging RS. The client
      can then use some other mechanism to determine the exact endpoint
      of that abstract audience identifier. This keeps the relationships
      defined without the tight-coupling of registering endpoints (even
      with wild cards).
    
      
    
      Now if the direction is to move to a token can only have one
      audience, to me that isn't OAuth2. It's a perfectly fine model,
      but we should be addressing that as the next gen spec, not trying
      to layer it on the existing one that has different deployment
      semantics.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/15/16 11:37 AM, John Bradley
      wrote:
    
    
    
    
    
      
      Yes,  I think bearer tokens with no audience are a bad idea.
      

    
      
    
      
    The AS needs to infer an audience from the scopes
        snd/or have the client specify the desired audience.
    
      

    
      
    
      
    If the AT has a audience or audiences then as long
        as the endpoint URI are provided as meta-data with the token,
        the client can determine if it is sending the token to the
        correct place.
    
      

    
      
    
      
    I think Phil would prefer the server rather than the
        client do the check, but the client always needs to take some
        responsibility to not leak tokens giving them to the wrong RS or
        the code to the wrong token endpoint is leaking.
    
      

    
      
    
      
    I imagine that claims based access tokens are going
        to become more popular and the static relationship between one
        RS and one AS will not be the majority of deployments over
        time. 
    
      

    
      
    
      
    In any case where the client is configured up front
        to know the RS and the AS it seems like that would not require
        Phil’s Solution, but that is the only case supported by that
        discovery.
    
      
      
    
      
    If the client itself is bad there is not much you
        can do to stop it from passing on the AT in way way it wants.
         That however is a different problem and needs claimed URI or
        attestations to prevent client spoofing.
    
      
    William and I are working on that in the mobile best
        practices draft.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 12:09 PM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
              
              
     I worry
                  about two directions I see in this thread...
    
                  
    
                  1. Client's accessing resources dynamically so that
                  discovery is required to know the correct AS, etc.
                  This is pretty much the classic use case for UMA and
                  I'd rather not re-invent the wheel.
    
                  
    
                  2. Creating a tight coupling between RS and AS such
                  that RS endpoint changes must be continually
                  communicated to the AS. If an RS supports multiple
                  AS's then the RS has to deal with "guaranteed"
                  delivery. The AS needs an endpoint to receive such
                  communications. If not dynamic via APIs, then
                  deployment of the new RS is bound by the associated
                  AS's getting and deploying the new endpoints. Can both
                  endpoints of the RS be supported within the AS for
                  some period of time, etc. This is an operation
                  nightmare and almost assuredly going to go wrong in
                  production.
    
                  
    
                  Maybe an OAuth2 "audience binding" spec is what's
                  needed for those deployments that require this. I
                  believe that is what John Bradley is suggesting.
    
                  
    
                  Thanks,
    
                  George
    
                
    
                
    On 3/14/16 7:29 PM, Hans
                  Zandbelt wrote:
    
                
    
                
    +1, I've found the very same in
                  OAuth deployments that I was involved in; the hard
                  part is to give names and descriptions to these
                  concepts so that they cover all use cases and can be
                  applied unambiguously 
    
                  
    
                  Hans. 
    
                  
    
                  On 3/14/16 10:44 PM, Justin Richer wrote: 
    
                  
    I agree that this is
                    valuable, and not just for PoP. In all honesty, 
    
                    it’s not even really required for PoP to function in
                    many cases — it’s 
    
                    just an optimization for one particular kind of key
                    distribution 
    
                    mechanism in that case. 
    
                    
    
                    In the years of deployment experience with OAuth 2,
                    I think we’ve really 
    
                    got three different kinds of things that currently
                    get folded into 
    
                    “scope†that we might want to try separating out
                    better: 
    
                    
    
                    
    
                      - What things do I want to access? (photos,
                    profile) 
    
                      - What actions do I want to take on these things?
                    (read, write, delete) 
    
                      - How long do I want these tokens to work? 
    
                    (offline_access/refresh_token, one time use, next
                    hour, etc) 
    
                    
    
                    
    
                    I think the first one is close to the
                    audience/resource parameters that 
    
                    have been bandied about a few times, including in
                    the current token 
    
                    exchange document. We should be consistent across
                    drafts in that regard. 
    
                    The second is more traditional scope-ish. The third
                    has been patched in 
    
                    with things like “offline_access†in certain APIs. 
    
                    
    
                    Just another vector to think about if we’re going to
                    be adding things 
    
                    like “audience†or “resource†or both to the token
                    requests. 
    
                    
    
                      — Justin 
    
                    
    
                    
    
                    
    On Mar 14, 2016, at
                      6:26 PM, John Bradley <ve7jtb@ve7jtb.com
                      
    
                      <mailto:ve7jtb@ve7jtb.com>>
                      wrote: 
    
                      
    
                      Yes I will work on another proposal for allowing
                      clients to specify 
    
                      what resource they want a token for and providing
                      the meta-data to the 
    
                      client about the resources that a token is valid
                      for. 
    
                      
    
                      We have part of it in the POP key distribution
                      spec and talked about 
    
                      separating it, as it is used more places than just
                      for assigning keys. 
    
                      I know some AS use different token formats for
                      different RS so are 
    
                      all-ready needing to pass the resource in the
                      request to avoid making 
    
                      a mess of scopes. 
    
                      
    
                      John B. 
    
                      
    
                      
    
                      
    
                      
    
                      
    
                      
    On Mar 14, 2016,
                        at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com
                        
    
                        <mailto:phil.hunt@oracle.com>>
                        wrote: 
    
                        
    
                        Inline 
    
                        
    
                        Phil 
    
                        
    
                        On Mar 14, 2016, at 14:13, John Bradley <ve7jtb@ve7jtb.com
                        
    
                        <mailto:ve7jtb@ve7jtb.com>>
                        wrote: 
    
                        
    
                        
    We had two
                          mandates.  One was to provide a spec for AS
                          metadata. 
    
                          The other was to mitigate the client mixup
                          attack.  The request was 
    
                          to do the latter without requiring the former
                          for clients that don’t 
    
                          otherwise need discovery. 
    
                        
    
                        There is no mandate for any of this. See 
    
                        http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
                        
    
                        
     
    
                          Returning the issuer and client_id from the
                          authorization endpoint 
    
                          and the client checking them can be done by
                          the client without 
    
                          discovery. 
    
                        
    
                        
    
                        How does this address the issue of whether the
                        client is talking to 
    
                        the wrong endpoint? 
    
                        
     
    
                          Any client that has the resource and issuer
                          hard coded probably 
    
                          doesn’t need discovery. 
    
                        
    
                        We agree 
    
                        
    
                        
    
                        
    One of the
                          things that a client will need discovery for
                          is to find 
    
                          the RS, so requiring the client to know the RS
                          URI before getting 
    
                          the AS config seems backwards to me. 
    
                        
    
                        How can you make an assumption on order? You
                        seem to be conflating 
    
                        authentication with authorization by assuming
                        the identity drives 
    
                        what the resource is. 
    
                        
    
                        There are lots of applications that require user
                        rights but are not 
    
                        identify centric. For example a document
                        service. 
    
                        
     
    
                          Unless the client tells the AS where it
                          intends to use the token we 
    
                          will be leaving a security hole because the
                          bearer tokens will have 
    
                          too loose an audience if they have one at all.
                          
    
                        
    
                        This is the biggest risk we have IMHO. 
    
                        
     
    
                          True you are telling the AS (Webfinger
                          service) what the RS is but 
    
                          that is not at a place that is useful in the
                          token production process. 
    
                        
    
                        
    
                        This has nothing to do with token production. 
    
                        
    
                        What we want to ensure is whether an honest
                        client is correctly 
    
                        configured and has not been mislead - eg by a
                        phishing page. 
    
                        
     
    
                          I also think there are use cases where the AS
                          doesn’t know all the 
    
                          possible RS.   That is not something that a
                          out of band check can 
    
                          address. 
    
                        
    
                        
    
                        May be. Lets identify them. 
    
                        
    
                        
    There are also
                          cases where a token might be good at multiple
                          RS 
    
                          endpoints intentionally. 
    
                        
    
                        
    
                        
     In your
                          solution the client would need to make a
                          discovery request 
    
                          for each endpoint. 
    
                        
    
                        Sure. Otherwise how would it know if there is
                        one AS or a pool of AS 
    
                        servers assigned to each instance? 
    
                        
    Those requests
                          lack the context of who the client and
                          resource owner 
    
                          are.  I think that will be a problem in some
                          use cases. 
    
                        
    
                        
    
                        Not sure I agree. This is about discovering a
                        valid set of endpoints. 
    
                        For mitm, we mainly want to check the hostname
                        is correct. If a 
    
                        client chooses evil.com <http://evil.com/>
                        the cert can be valid and 
    
                        TLS will pass. How does it otherwise know it is
                        supposed to talk to 
    
                        res.example.com
                        <http://res.example.com/>?
                        
    
                        
     
    
                          If this is added to the token endpoint it
                          would be checked when code 
    
                          or refresh are exchanged, not every time the
                          token is used. 
    
                        
    
                        Your proposal requires rhe client to check. I am
                        not clear how the AS 
    
                        can know the exact uri. It is far easier to
                        validate than to lookup 
    
                        since as you say the client may be authorized to
                        use multiple ASs. 
    
                        
    With a out of
                          band check the client would never know if a RS
                          was 
    
                          removed/revoked. 
    
                        
    
                        
    
                        Not sure that is in scope. 
    
                        
    
                        None of the current proposals address this
                        issue. 
    
                        
     
    
                          I don’t see checking when refreshing a token
                          as something that is a 
    
                          huge burden. 
    
                        
    
                        
    
                        Still its a lot more than once. 
    
                        
    
                        Why don't you draft another alternative? 
    
                        
     
    
                          If the server wants to do the check on it’s
                          side then we could 
    
                          require the client to send the RS URI in the
                          token request. that way 
    
                          you really know the client is not going to get
                          a token for the wrong 
    
                          RS endpoint. 
    
                          If you check out of band in discovery you
                          really have no idea if the 
    
                          client is checking. 
    
                        
    
                        
    
                        In the new webfinger draft, the client isn't
                        checking. The service 
    
                        provider simply does not disclose oauth
                        information to misconfigured 
    
                        clients. 
    
                        
     
    
                          John B. 
    
                          
    
                          
    
                          
    On Mar 14,
                            2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com
                            
    
                            <mailto:phil.hunt@oracle.com>>
                            wrote: 
    
                            
    
                            Thanks to Mike and John for their feedback. 
                            I’ll take each in turn: 
    
                            
    
                            Mike, 
    
                            
    
                            Regarding your suggested amendments 
    
                            
    
                            Item 1: Returning the config URL would
                            create two problems. One,it 
    
                            makes bound discovery a two-step process -
                            that adds complexity. 
    
                             It seems far simpler to mandate TLS (which
                            I think it already does 
    
                            in the security considerations). 
    
                            
    
                            The two-step process allows the current
                            discovery process to 
    
                            continue. I disagree with this. This is why
                            I put forward an 
    
                            “alternate" draft that is almost the same
                            but simply adds the check 
    
                            before returning the configuration data.  I
                            worry that  developers 
    
                            would have no incentive to do the two-step
                            approach. They would 
    
                            just start at step 2 which in turn puts AS’s
                            at risk of exposing 
    
                            tokens because it works. This makes OAuth
                            promiscuous. 
    
                            
    
                            Regarding existing implementations. Most of
                            those implementations 
    
                            are for OIDC.  I think it makes sense for
                            OIDF to continue use of 
    
                            OIDC's discovery spec because the UserInfo
                            endpoint is well defined 
    
                            and the likelihood of a client mis-informed
                            about the resource 
    
                            endpoint is not there.  IMO This does not
                            apply to the broader 
    
                            OAuth community. 
    
                            
    
                            Item 2:  It may be appropriate to have a
                            separate configuration 
    
                            registry specification, but I think we
                            should hold off until we 
    
                            have a complete solution and then make the
                            decision what drafts 
    
                            should exist and how many pieces.  A big
                            concern is the perceived 
    
                            complexity of multiple solutions and
                            multiple drafts. 
    
                            
    
                            As to John Bradley’s comments: 
    
                            
    
                            Re: Discovery is the wrong place to mitigate
                            threats. 
    
                            I’m confused by this.  Our mandate was to
                            solve a security threat 
    
                            by having a discovery specification to
                            prevent clients being 
    
                            mis-lead about endpoints (of which resource
                            service is one) in an 
    
                            oauth protected exchange.  Maybe what you
                            mean is we should not use 
    
                            .well-known of any kind and we should just
                            create a “/Config†
    
                            endpoint to OAuth? 
    
                            
    
                            Re: Your proposal for MITM mitigation 
    
                            You propose that instead the resource
                            endpoint check should be in 
    
                            the oauth protocol itself.  The difference
                            is that validation is 
    
                            transferred back to the client to get it
                            right. As well, without 
    
                            the client informing the AS, I can’t see a
                            way for the AS to know 
    
                            what endpoint the client is using.  The
                            webfinger approach does 
    
                            this once and only requires that the host
                            name be checked in many 
    
                            cases. 
    
                            
    
                            As a principle, the members have discussed
                            many times that the AS 
    
                            service should do validation when possible —
                            this was particularly 
    
                            true at the Germany meeting when this came
                            up. This is why I prefer 
    
                            the client tell the service provider what it
                            intends to do and the 
    
                            service provider can fail that request
                            immediately if necessary. We 
    
                            don’t have to depend on the developer
                            getting the spec correct to 
    
                            fail the correct way. 
    
                            
    
                            I worry that adding more parameters to the
                            authz and token protocol 
    
                            flows increases complexity and attack
                            surface. It also means per 
    
                            authorization validation has to take place
                            vs. a one-time 
    
                            validation at config time.  Placing it in
                            the configuration lookup 
    
                            phase (whether via web finger or just a
                            special OAuth endpoint) 
    
                            seems more appropriate and far less complex
                            - as the request itself 
    
                            is simple and has only one parameter. Here
                            we are not considered 
    
                            about legitimacy of the client. we’re just
                            concerned with the issue 
    
                            "has the client been correctly informed?†
    
                            
    
                            That said, it may be that when we consider
                            all the use cases, some 
    
                            combination of AS protocol and discovery may
                            be both needed. I’m 
    
                            not ready to make conclusions about this. 
                            The current 
    
                            oauth-discovery spec seems to put future
                            generic clients at risk 
    
                            and that is my primary concern. 
    
                            
    
                            Best Regards, 
    
                            
    
                            Phil 
    
                            
    
                            @independentid 
    
                            www.independentid.com
                            <http://www.independentid.com/>
                            
    
                            phil.hunt@oracle.com
                            <mailto:phil.hunt@oracle.com>
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    On Mar 13,
                              2016, at 10:28 PM, Mike Jones 
    
                              <Michael.Jones@microsoft.com
                              <mailto:Michael.Jones@microsoft.com>>

                              
    
                              wrote: 
    
                              
    
                              Thanks for posting this, Phil.  It
                              provides a concrete example of 
    
                              a way that protected resource discovery
                              could be added to 
    
                              authorization server metadata discovery,
                              and as such, should 
    
                              provide useful input for working group
                              discussions on this topic. 
    
                              It’s always great when someone takes the
                              time to write an actual 
    
                              draft that can be examined and
                              implemented, and I appreciate you 
    
                              doing that. 
    
                              The content of your draft points out that
                              there appears to be 
    
                              complete agreement on what the
                              authorization server metadata 
    
                              format should be, which is great!  I’ll
                              note that Section 3 of 
    
                              draft-hunt-oauth-bound-config-00 titled
                              “Authorization Server 
    
                              Metadata†is an exact copy of Section 2 of
                              
    
                              draft-ietf-oauth-discovery-01 (with the
                              same title), modulo 
    
                              applying a correction suggested by the
                              working group.  To me this 
    
                              suggests that the authorization server
                              metadata definitions in 
    
                              draft-ietf-oauth-discovery (which is now
                              the whole normative 
    
                              content of the draft) are clearly ready
                              for standardization, since 
    
                              even your alternative proposal includes
                              them verbatim. 
    
                              Reading your draft, the problem I have
                              with it is that you are 
    
                              returning the AS metadata only as a
                              WebFinger response, rather 
    
                              than as an https-protected resource
                              published by the authorization 
    
                              server.  The choice to only return this
                              via WebFinger makes your 
    
                              draft incompatible with most deployed
                              implementations of OAuth 
    
                              metadata, including the 22 implementations
                              using it listed 
    
                              athttp://openid.net/certification/(see
                              the “OP Config†column in 
    
                              the table) andOAuth 2.0 libraries such as
                              Microsoft’s “ADAL†
    
                              library, which uses the metadata path for
                              client configuration. 
    
                              Without having ASs provide the metadata as
                              an https-protected 
    
                              resource, implementations such as ADAL
                              can’t use it for client 
    
                              configuration as the currently do. 
    
                              Therefore, I would request that you make
                              these minor revisions to 
    
                              your draft and republish, so as to provide
                              a unified way forward 
    
                              that is compatible with all known existing
                              OAuth Discovery 
    
                              deployments: 
    
                              1.Modify your section 2 “Authorization
                              Server WebFinger Discovery†
    
                              to have the WebFinger request return the
                              issuer identifier for the 
    
                              AS as the “WebFinger “rel†value, rather
                              than returning the 
    
                              metadata values by value as the
                              “properties†value. 
    
                              2.Reference the metadata definitions from
                              Section 2 of 
    
                              draft-ietf-oauth-discovery, rather than
                              duplicating them in your 
    
                              Section 3. 
    
                              That would have the advantage of paring
                              your draft down to only 
    
                              the new things that it proposes, enabling
                              them to be more clearly 
    
                              understood and evaluated on their own
                              merits.  I look forward to 
    
                              the discussions of ways of performing
                              additional kinds of OAuth 
    
                              discovery, and consider your draft a
                              valuable input to those 
    
                              discussions. 
    
                                                                                       

                              Best wishes, 
    
                                                                                       

                              -- Mike 
    
                              *From:*OAuth [mailto:oauth-bounces@ietf.org]*On
                              Behalf Of*John Bradley 
    
                              *Sent:*Sunday, March 13, 2016 6:45 PM 
    
                              *To:*Phil Hunt <phil.hunt@oracle.com
                              <mailto:phil.hunt@oracle.com>>

                              
    
                              *Cc:*oauth <oauth@ietf.org
                              <mailto:oauth@ietf.org>>

                              
    
                              *Subject:*Re: [OAUTH-WG] New Version
                              Notification for 
    
                              draft-hunt-oauth-bound-config-00.txt 
    
                              As I have told Phil off list. 
    
                              Discovery is the wrong place to try and
                              provide security against 
    
                              man in the middle attacks on the RS. 
    
                              This requires the client to know what the
                              RS URI is before 
    
                              retrieving the information on the AS
                              Configuration. 
    
                              The proposal Mike and I have been working
                              on requires the client 
    
                              to have a notion of what API it is looking
                              for and retrieve the 
    
                              .well-known file for that API from the
                              issuer.   That allows a 
    
                              protocol like Connect to register its own
                              config file that can 
    
                              point to the RS. 
    
                              If the API specific well known is not
                              available the client can try 
    
                              the default oauth-server one. 
    
                              That then allows us to deal with
                              restricting where AT are 
    
                              presented as part of the protocol rather
                              then dragging discovery 
    
                              in as a requirement. 
    
                              In my opinion the resource the token is
                              targeted to should be 
    
                              separated from the scope and returned as
                              part of the meta-data 
    
                              about the AT along with scopes granted and
                              expiry time.   We 
    
                              should also have a input parameter for
                              resources so that a client 
    
                              can restrict tokens issued to a subset of
                              the ones granted by the 
    
                              refresh token.   It would then also be
                              possible to ask a AS for a 
    
                              token for a unregistered RS and have the
                              AS produce a JWT access 
    
                              token with the resource as an audience if
                              policy allows. 
    
                              That however was supposed to be dealt with
                              as part of the mixed up 
    
                              client set of mitigations. 
    
                              In that the goal was to mitigate the
                              attacks by returning 
    
                              meta-data about the tokens, and not to
                              require discovery. 
    
                              We intend to return “iss†and “cleint_idâ€
                              for the code, and I 
    
                              intend to discuss at the F2F returning
                              resource for AT as well. 
    
                              Those mitigate the attack. 
    
                              I will continue to resist mixing up
                              discovery of configuration 
    
                              meta-data with mitigation of the attacks.
                              
    
                              We return meta-data about the tokens now,
                              because AT are opaque to 
    
                              the client, we neglected to include some
                              of the information for 
    
                              the client needs to be secure.   We just
                              need to add that in to 
    
                              the existing flows. 
    
                              While Phil’s proposal is easier for the AS
                              to implement as an add 
    
                              on, it puts more of a burden on the client
                              needing to potentially 
    
                              change how it stores the relationships
                              between AS and RS to 
    
                              prevent compromise, I think the solution
                              should be biased towards 
    
                              simplicity on the client side. 
    
                              If we return the resources as part of the
                              existing meta data the 
    
                              client checks that against the resource it
                              intends to send the 
    
                              token to and if it is not in the list then
                              it can’t send the 
    
                              token.  Simple check every time it gets a
                              new AT, no optionality. 
    
                              I am not saying anything new Nat has been
                              advocating basically 
    
                              this for some time, and dis submit a
                              draft.   I prefer to return 
    
                              the info in the existing format rather
                              than as link headers,  but 
    
                              that is the largest difference between
                              what Nat and I are saying 
    
                              with respect to resource. 
    
                              That is the core of my problem with Phil’s
                              draft. 
    
                              I guess we will need to have a long
                              conversation in BA. 
    
                              Regards 
    
                              John B. 
    
                              
    
                                  On Mar 13, 2016, at 8:12 PM, Phil Hunt
                              <phil.hunt@oracle.com
                              
    
                                  <mailto:phil.hunt@oracle.com>>
                              wrote: 
    
                                  This draft is a proposed alternate
                              proposal for 
    
                                  draft-ietf-oauth-discovery.  As such,
                              it contains the same 
    
                                  registry for OAuth Config Metadata as
                              the authors believe that 
    
                                  both solutions are not required, or
                              depending on WG discussion 
    
                                  they will be merged. The intent is to
                              provide a simple 
    
                                  complete draft for consideration. 
    
                                  How it works... 
    
                                  Given that a client has previously
                              discovered an OAuth 
    
                                  protected resource, the bound
                              configuration method allows a 
    
                                  client to return the configuration for
                              an oauth authorization 
    
                                  server that can issue tokens for the
                              resource URI specified by 
    
                                  the client.  The AS is not required to
                              be in the same domain. 
    
                                   The AS is however required to know if
                              it can issue tokens for 
    
                                  a resource service (which presumes
                              some agreement exists on 
    
                                  tokens etc). 
    
                                  The draft does not require that the
                              resource exist (e.g. for 
    
                                  unconfigured or new user based
                              resources). It only requires 
    
                                  that the AS service provider agrees it
                              can issue tokens. 
    
                                  From a security perspective, returning
                              the OAuth service 
    
                                  configuration for a specified resource
                              URI serves to confirm 
    
                                  the client is in possession of a valid
                              resource URI ensuring 
    
                                  the client has received a valid set of
                              endpoints for the 
    
                                  resource and the associated oauth
                              services. 
    
                                  I propose that the WG consider the
                              alternate draft carefully 
    
                                  as well as other submissions and
                              evaluate the broader 
    
                                  discovery problem before proceeding
                              with WGLC on OAuth Discovery. 
    
                                  Thanks! 
    
                                  Phil 
    
                                  @independentid 
    
                                  www.independentid.com
                              <http://www.independentid.com/>
                              
    
                                  phil.hunt@oracle.com
                              <mailto:phil.hunt@oracle.com>
                              
    
                              
    
                              
    
                                      Begin forwarded message: 
    
                                      *From:*internet-drafts@ietf.org 
    
                                      <mailto:internet-drafts@ietf.org>
                              
    
                                      *Subject: New Version Notification
                              for 
    
                                     
                              draft-hunt-oauth-bound-config-00.txt* 
    
                                      *Date:*March 13, 2016 at 3:53:37
                              PM PDT 
    
                                      *To:*"Phil Hunt" <phil.hunt@yahoo.com
                              
    
                                      <mailto:phil.hunt@yahoo.com>>,

                              "Anthony Nadalin" 
    
                                      <tonynad@microsoft.com
                              <mailto:tonynad@microsoft.com>>,

                              
    
                                      "Tony Nadalin" <tonynad@microsoft.com
                              
    
                                      <mailto:tonynad@microsoft.com>>

                              
    
                              
    
                              
    
                                      A new version of I-D,
                              draft-hunt-oauth-bound-config-00.txt 
    
                                      has been successfully submitted by
                              Phil Hunt and posted to the 
    
                                      IETF repository. 
    
                              
    
                                      Name:draft-hunt-oauth-bound-config
                              
    
                                      Revision:00 
    
                                      Title:OAuth 2.0 Bound
                              Configuration Lookup 
    
                                      Document date:2016-03-13 
    
                                      Group:Individual Submission 
    
                                      Pages:22 
    
                                      URL: 
    
                                     
                              https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                                      Status: 
    
                                      https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                              
    
                                      Htmlized: 
    
                                      https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                              
    
                              
    
                              
    
                                      Abstract: 
    
                                        This specification defines a
                              mechanism for the client of 
    
                                      an OAuth 2.0 
    
                                        protected resource service to
                              obtain the configuration 
    
                                      details of an 
    
                                        OAuth 2.0 authorization server
                              that is capable of 
    
                                      authorizing access 
    
                                        to a specific resource service. 
                              The information 
    
                                      includes the OAuth 
    
                                        2.0 component endpoint location
                              URIs and as well as 
    
                                      authorization 
    
                                        server capabilities. 
    
                              
    
                              
    
                              
    
                              
    
                                      Please note that it may take a
                              couple of minutes from the 
    
                                      time of submission 
    
                                      until the htmlized version and
                              diff are available 
    
                                      attools.ietf.org
                              <http://tools.ietf.org/>.
                              
    
                              
    
                                      The IETF Secretariat 
    
                              
    
                                 
                              _______________________________________________
                              
    
                                  OAuth mailing list 
    
                                  OAuth@ietf.org
                              <mailto:OAuth@ietf.org>
                              
    
                                  https://www.ietf.org/mailman/listinfo/oauth
                              
    
                            
    
                            
    
                          
    
                          
    
                        
    
                      
    
                      
    
                      _______________________________________________ 
    
                      OAuth mailing list 
    
                      OAuth@ietf.org
                      <mailto:OAuth@ietf.org>
                      
    
                      https://www.ietf.org/mailman/listinfo/oauth
                      
    
                    
    
                    
    
                    
    
                    
    
                    _______________________________________________ 
    
                    OAuth mailing list 
    
                    OAuth@ietf.org 
    
                    https://www.ietf.org/mailman/listinfo/oauth
                    
    
                    
    
                  
    
                  
    
                
    
                
    
              
    
            
    
          
    
        
    
        
    
      
    
    
    
    
    
  


--------------070904020201050001060202--


From nobody Tue Mar 15 09:02:30 2016
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 A7E1112DCDF for ; Tue, 15 Mar 2016 09:02:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 UL7gZfU08nm1 for ; Tue, 15 Mar 2016 09:02:08 -0700 (PDT)
Received: from omr-m012e.mx.aol.com (omr-m012e.mx.aol.com [204.29.186.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFEC12DCD0 for ; Tue, 15 Mar 2016 09:01:26 -0700 (PDT)
Received: from mtaout-aae02.mx.aol.com (mtaout-aae02.mx.aol.com [172.27.1.98]) by omr-m012e.mx.aol.com (Outbound Mail Relay) with ESMTP id C23A0380009E; Tue, 15 Mar 2016 12:01:25 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aae02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id EA06338000088; Tue, 15 Mar 2016 12:01:24 -0400 (EDT)
To: Phil Hunt 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E831D4.1090609@aol.com>
Date: Tue, 15 Mar 2016 12:01:24 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060909000706030806000105"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458057685; bh=wV4mFvNROq9UjPeAJ05PfRknAWdSBaniX8MGISsN8P0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ZY927myruAoUCN9xOcT16htl6yzNNbycTQvwDx3n7TWg4aLo8mMI/Wz0vgW9WXKyP lPxqcxGyYe0HdoLUgnUOPSGygqfWvJjUDlZcRcwvix+w3b7XpA9FStiSAa3taxzRP2 WO0w93dIo+dii8EK4qEZicHaeQ55C78L0xVCr7I8=
x-aol-sid: 3039ac1b016256e831d41cf6
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 16:02:29 -0000

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

I understand the benefit of having the client specify where it wants to 
present the token. However, in general, the client knows which kind of 
resource it's going to connect to (even if it doesn't know the exact 
endpoint). For example, if the client speaks PortableContacts, then it 
can potentially discover any PortableContact RS and attempt to get 
authorization to access the endpoints, but the client can't connect to 
the mail RS because it's not coded to work with those endpoints.

Therefore, the client has an understanding of the protocol of the RS and 
can possibly discover related endpoints (what webfinger was really 
designed for) but it can't support some random new protocol. As I wrote 
in my response to John Bradley, I believe audience binding should use an 
abstract identifier not an API endpoint.

Thanks,
George

On 3/15/16 11:40 AM, Phil Hunt wrote:
> Regarding 2.
>
> The bound config spec makes no such requirement of knowing the and its 
> path structure.
>
> If you feel that you have other security measures and that clients 
> will always have the proper AS, then you can wildcard the whole 
> resource parameter.  It still might be advisable to at least check 
> that your clients are using a URL of the form https://*.aol.com/* or 
> https://*.partner.com/*.
>
> The benefit is that at least you know the client is intending to wield 
> the token somewhere in your domain or your partner’s domain. as 
> opposed to something like news.aol.myevildomain.com 
> .
>
> The difference here is that security remains the responsibility of the 
> service provider in all cases.  The check is up to the service 
> provider rather than the client. This means that we don’t have to rely 
> on trusting that the client developer bothered to check the 
> configuration (as in other proposals that modify OAuth protocol 
> itself) — we know well they won’t because they won’t have to. The 
> server side validation is trivial.  I’m not sure how much easier this 
> can be.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Mar 15, 2016, at 8:09 AM, George Fletcher > > wrote:
>>
>> I worry about two directions I see in this thread...
>>
>> 1. Client's accessing resources dynamically so that discovery is 
>> required to know the correct AS, etc. This is pretty much the classic 
>> use case for UMA and I'd rather not re-invent the wheel.
>>
>> 2. Creating a tight coupling between RS and AS such that RS endpoint 
>> changes must be continually communicated to the AS. If an RS supports 
>> multiple AS's then the RS has to deal with "guaranteed" delivery. The 
>> AS needs an endpoint to receive such communications. If not dynamic 
>> via APIs, then deployment of the new RS is bound by the associated 
>> AS's getting and deploying the new endpoints. Can both endpoints of 
>> the RS be supported within the AS for some period of time, etc. This 
>> is an operation nightmare and almost assuredly going to go wrong in 
>> production.
>>
>> Maybe an OAuth2 "audience binding" spec is what's needed for those 
>> deployments that require this. I believe that is what John Bradley is 
>> suggesting.
>>
>> Thanks,
>> George
>>
>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>> +1, I've found the very same in OAuth deployments that I was 
>>> involved in; the hard part is to give names and descriptions to 
>>> these concepts so that they cover all use cases and can be applied 
>>> unambiguously
>>>
>>> Hans.
>>>
>>> On 3/14/16 10:44 PM, Justin Richer wrote:
>>>> I agree that this is valuable, and not just for PoP. In all honesty,
>>>> it’s not even really required for PoP to function in many cases — it’s
>>>> just an optimization for one particular kind of key distribution
>>>> mechanism in that case.
>>>>
>>>> In the years of deployment experience with OAuth 2, I think we’ve 
>>>> really
>>>> got three different kinds of things that currently get folded into
>>>> “scope†that we might want to try separating out better:
>>>>
>>>>
>>>>   - What things do I want to access? (photos, profile)
>>>>   - What actions do I want to take on these things? (read, write, 
>>>> delete)
>>>>   - How long do I want these tokens to work?
>>>> (offline_access/refresh_token, one time use, next hour, etc)
>>>>
>>>>
>>>> I think the first one is close to the audience/resource parameters 
>>>> that
>>>> have been bandied about a few times, including in the current token
>>>> exchange document. We should be consistent across drafts in that 
>>>> regard.
>>>> The second is more traditional scope-ish. The third has been 
>>>> patched in
>>>> with things like “offline_access†in certain APIs.
>>>>
>>>> Just another vector to think about if we’re going to be adding things
>>>> like “audience†or “resource†or both to the token requests.
>>>>
>>>>   — Justin
>>>>
>>>>
>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>> > wrote:
>>>>>
>>>>> Yes I will work on another proposal for allowing clients to specify
>>>>> what resource they want a token for and providing the meta-data to 
>>>>> the
>>>>> client about the resources that a token is valid for.
>>>>>
>>>>> We have part of it in the POP key distribution spec and talked about
>>>>> separating it, as it is used more places than just for assigning 
>>>>> keys.
>>>>> I know some AS use different token formats for different RS so are
>>>>> all-ready needing to pass the resource in the request to avoid making
>>>>> a mess of scopes.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>> > wrote:
>>>>>>
>>>>>> Inline
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>> > wrote:
>>>>>>
>>>>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>>>>> The other was to mitigate the client mixup attack.  The request was
>>>>>>> to do the latter without requiring the former for clients that 
>>>>>>> don’t
>>>>>>> otherwise need discovery.
>>>>>> There is no mandate for any of this. See
>>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
>>>>>>
>>>>>>>
>>>>>>> Returning the issuer and client_id from the authorization endpoint
>>>>>>> and the client checking them can be done by the client without
>>>>>>> discovery.
>>>>>>
>>>>>> How does this address the issue of whether the client is talking to
>>>>>> the wrong endpoint?
>>>>>>>
>>>>>>> Any client that has the resource and issuer hard coded probably
>>>>>>> doesn’t need discovery.
>>>>>> We agree
>>>>>>
>>>>>>
>>>>>>> One of the things that a client will need discovery for is to find
>>>>>>> the RS, so requiring the client to know the RS URI before getting
>>>>>>> the AS config seems backwards to me.
>>>>>> How can you make an assumption on order? You seem to be conflating
>>>>>> authentication with authorization by assuming the identity drives
>>>>>> what the resource is.
>>>>>>
>>>>>> There are lots of applications that require user rights but are not
>>>>>> identify centric. For example a document service.
>>>>>>>
>>>>>>> Unless the client tells the AS where it intends to use the token we
>>>>>>> will be leaving a security hole because the bearer tokens will have
>>>>>>> too loose an audience if they have one at all.
>>>>>> This is the biggest risk we have IMHO.
>>>>>>>
>>>>>>> True you are telling the AS (Webfinger service) what the RS is but
>>>>>>> that is not at a place that is useful in the token production 
>>>>>>> process.
>>>>>>
>>>>>> This has nothing to do with token production.
>>>>>>
>>>>>> What we want to ensure is whether an honest client is correctly
>>>>>> configured and has not been mislead - eg by a phishing page.
>>>>>>>
>>>>>>> I also think there are use cases where the AS doesn’t know all the
>>>>>>> possible RS.   That is not something that a out of band check can
>>>>>>> address.
>>>>>>
>>>>>> May be. Lets identify them.
>>>>>>
>>>>>>> There are also cases where a token might be good at multiple RS
>>>>>>> endpoints intentionally.
>>>>>>
>>>>>>>  In your solution the client would need to make a discovery request
>>>>>>> for each endpoint.
>>>>>> Sure. Otherwise how would it know if there is one AS or a pool of AS
>>>>>> servers assigned to each instance?
>>>>>>> Those requests lack the context of who the client and resource 
>>>>>>> owner
>>>>>>> are.  I think that will be a problem in some use cases.
>>>>>>
>>>>>> Not sure I agree. This is about discovering a valid set of 
>>>>>> endpoints.
>>>>>> For mitm, we mainly want to check the hostname is correct. If a
>>>>>> client chooses evil.com   the 
>>>>>> cert can be valid and
>>>>>> TLS will pass. How does it otherwise know it is supposed to talk to
>>>>>> res.example.com  ?
>>>>>>>
>>>>>>> If this is added to the token endpoint it would be checked when 
>>>>>>> code
>>>>>>> or refresh are exchanged, not every time the token is used.
>>>>>> Your proposal requires rhe client to check. I am not clear how 
>>>>>> the AS
>>>>>> can know the exact uri. It is far easier to validate than to lookup
>>>>>> since as you say the client may be authorized to use multiple ASs.
>>>>>>> With a out of band check the client would never know if a RS was
>>>>>>> removed/revoked.
>>>>>>
>>>>>> Not sure that is in scope.
>>>>>>
>>>>>> None of the current proposals address this issue.
>>>>>>>
>>>>>>> I don’t see checking when refreshing a token as something that is a
>>>>>>> huge burden.
>>>>>>
>>>>>> Still its a lot more than once.
>>>>>>
>>>>>> Why don't you draft another alternative?
>>>>>>>
>>>>>>> If the server wants to do the check on it’s side then we could
>>>>>>> require the client to send the RS URI in the token request. that 
>>>>>>> way
>>>>>>> you really know the client is not going to get a token for the 
>>>>>>> wrong
>>>>>>> RS endpoint.
>>>>>>> If you check out of band in discovery you really have no idea if 
>>>>>>> the
>>>>>>> client is checking.
>>>>>>
>>>>>> In the new webfinger draft, the client isn't checking. The service
>>>>>> provider simply does not disclose oauth information to misconfigured
>>>>>> clients.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Thanks to Mike and John for their feedback. I’ll take each in 
>>>>>>>> turn:
>>>>>>>>
>>>>>>>> Mike,
>>>>>>>>
>>>>>>>> Regarding your suggested amendments
>>>>>>>>
>>>>>>>> Item 1: Returning the config URL would create two problems. One,it
>>>>>>>> makes bound discovery a two-step process - that adds complexity.
>>>>>>>>  It seems far simpler to mandate TLS (which I think it already 
>>>>>>>> does
>>>>>>>> in the security considerations).
>>>>>>>>
>>>>>>>> The two-step process allows the current discovery process to
>>>>>>>> continue. I disagree with this. This is why I put forward an
>>>>>>>> “alternate" draft that is almost the same but simply adds the 
>>>>>>>> check
>>>>>>>> before returning the configuration data.  I worry that  developers
>>>>>>>> would have no incentive to do the two-step approach. They would
>>>>>>>> just start at step 2 which in turn puts AS’s at risk of exposing
>>>>>>>> tokens because it works. This makes OAuth promiscuous.
>>>>>>>>
>>>>>>>> Regarding existing implementations. Most of those implementations
>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use of
>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well 
>>>>>>>> defined
>>>>>>>> and the likelihood of a client mis-informed about the resource
>>>>>>>> endpoint is not there.  IMO This does not apply to the broader
>>>>>>>> OAuth community.
>>>>>>>>
>>>>>>>> Item 2:  It may be appropriate to have a separate configuration
>>>>>>>> registry specification, but I think we should hold off until we
>>>>>>>> have a complete solution and then make the decision what drafts
>>>>>>>> should exist and how many pieces.  A big concern is the perceived
>>>>>>>> complexity of multiple solutions and multiple drafts.
>>>>>>>>
>>>>>>>> As to John Bradley’s comments:
>>>>>>>>
>>>>>>>> Re: Discovery is the wrong place to mitigate threats.
>>>>>>>> I’m confused by this.  Our mandate was to solve a security threat
>>>>>>>> by having a discovery specification to prevent clients being
>>>>>>>> mis-lead about endpoints (of which resource service is one) in an
>>>>>>>> oauth protected exchange.  Maybe what you mean is we should not 
>>>>>>>> use
>>>>>>>> .well-known of any kind and we should just create a “/Configâ€
>>>>>>>> endpoint to OAuth?
>>>>>>>>
>>>>>>>> Re: Your proposal for MITM mitigation
>>>>>>>> You propose that instead the resource endpoint check should be in
>>>>>>>> the oauth protocol itself.  The difference is that validation is
>>>>>>>> transferred back to the client to get it right. As well, without
>>>>>>>> the client informing the AS, I can’t see a way for the AS to know
>>>>>>>> what endpoint the client is using.  The webfinger approach does
>>>>>>>> this once and only requires that the host name be checked in many
>>>>>>>> cases.
>>>>>>>>
>>>>>>>> As a principle, the members have discussed many times that the AS
>>>>>>>> service should do validation when possible — this was particularly
>>>>>>>> true at the Germany meeting when this came up. This is why I 
>>>>>>>> prefer
>>>>>>>> the client tell the service provider what it intends to do and the
>>>>>>>> service provider can fail that request immediately if 
>>>>>>>> necessary. We
>>>>>>>> don’t have to depend on the developer getting the spec correct to
>>>>>>>> fail the correct way.
>>>>>>>>
>>>>>>>> I worry that adding more parameters to the authz and token 
>>>>>>>> protocol
>>>>>>>> flows increases complexity and attack surface. It also means per
>>>>>>>> authorization validation has to take place vs. a one-time
>>>>>>>> validation at config time.  Placing it in the configuration lookup
>>>>>>>> phase (whether via web finger or just a special OAuth endpoint)
>>>>>>>> seems more appropriate and far less complex - as the request 
>>>>>>>> itself
>>>>>>>> is simple and has only one parameter. Here we are not considered
>>>>>>>> about legitimacy of the client. we’re just concerned with the 
>>>>>>>> issue
>>>>>>>> "has the client been correctly informed?â€
>>>>>>>>
>>>>>>>> That said, it may be that when we consider all the use cases, some
>>>>>>>> combination of AS protocol and discovery may be both needed. I’m
>>>>>>>> not ready to make conclusions about this. The current
>>>>>>>> oauth-discovery spec seems to put future generic clients at risk
>>>>>>>> and that is my primary concern.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> @independentid
>>>>>>>> www.independentid.com 
>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>> >>>>>>>> >
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete example of
>>>>>>>>> a way that protected resource discovery could be added to
>>>>>>>>> authorization server metadata discovery, and as such, should
>>>>>>>>> provide useful input for working group discussions on this topic.
>>>>>>>>> It’s always great when someone takes the time to write an actual
>>>>>>>>> draft that can be examined and implemented, and I appreciate you
>>>>>>>>> doing that.
>>>>>>>>> The content of your draft points out that there appears to be
>>>>>>>>> complete agreement on what the authorization server metadata
>>>>>>>>> format should be, which is great!  I’ll note that Section 3 of
>>>>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server
>>>>>>>>> Metadata†is an exact copy of Section 2 of
>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>>>>>>>>> applying a correction suggested by the working group.  To me this
>>>>>>>>> suggests that the authorization server metadata definitions in
>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative
>>>>>>>>> content of the draft) are clearly ready for standardization, 
>>>>>>>>> since
>>>>>>>>> even your alternative proposal includes them verbatim.
>>>>>>>>> Reading your draft, the problem I have with it is that you are
>>>>>>>>> returning the AS metadata only as a WebFinger response, rather
>>>>>>>>> than as an https-protected resource published by the 
>>>>>>>>> authorization
>>>>>>>>> server.  The choice to only return this via WebFinger makes your
>>>>>>>>> draft incompatible with most deployed implementations of OAuth
>>>>>>>>> metadata, including the 22 implementations using it listed
>>>>>>>>> athttp://openid.net/certification/(see the “OP Config†column in
>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft’s “ADALâ€
>>>>>>>>> library, which uses the metadata path for client configuration.
>>>>>>>>> Without having ASs provide the metadata as an https-protected
>>>>>>>>> resource, implementations such as ADAL can’t use it for client
>>>>>>>>> configuration as the currently do.
>>>>>>>>> Therefore, I would request that you make these minor revisions to
>>>>>>>>> your draft and republish, so as to provide a unified way forward
>>>>>>>>> that is compatible with all known existing OAuth Discovery
>>>>>>>>> deployments:
>>>>>>>>> 1.Modify your section 2 “Authorization Server WebFinger 
>>>>>>>>> Discoveryâ€
>>>>>>>>> to have the WebFinger request return the issuer identifier for 
>>>>>>>>> the
>>>>>>>>> AS as the “WebFinger “rel†value, rather than returning the
>>>>>>>>> metadata values by value as the “properties†value.
>>>>>>>>> 2.Reference the metadata definitions from Section 2 of
>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in your
>>>>>>>>> Section 3.
>>>>>>>>> That would have the advantage of paring your draft down to only
>>>>>>>>> the new things that it proposes, enabling them to be more clearly
>>>>>>>>> understood and evaluated on their own merits.  I look forward to
>>>>>>>>> the discussions of ways of performing additional kinds of OAuth
>>>>>>>>> discovery, and consider your draft a valuable input to those
>>>>>>>>> discussions.
>>>>>>>>> Best wishes,
>>>>>>>>> -- Mike
>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*John 
>>>>>>>>> Bradley
>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>> *To:*Phil Hunt >>>>>>>> >
>>>>>>>>> *Cc:*oauth >
>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>> As I have told Phil off list.
>>>>>>>>> Discovery is the wrong place to try and provide security against
>>>>>>>>> man in the middle attacks on the RS.
>>>>>>>>> This requires the client to know what the RS URI is before
>>>>>>>>> retrieving the information on the AS Configuration.
>>>>>>>>> The proposal Mike and I have been working on requires the client
>>>>>>>>> to have a notion of what API it is looking for and retrieve the
>>>>>>>>> .well-known file for that API from the issuer.   That allows a
>>>>>>>>> protocol like Connect to register its own config file that can
>>>>>>>>> point to the RS.
>>>>>>>>> If the API specific well known is not available the client can 
>>>>>>>>> try
>>>>>>>>> the default oauth-server one.
>>>>>>>>> That then allows us to deal with restricting where AT are
>>>>>>>>> presented as part of the protocol rather then dragging discovery
>>>>>>>>> in as a requirement.
>>>>>>>>> In my opinion the resource the token is targeted to should be
>>>>>>>>> separated from the scope and returned as part of the meta-data
>>>>>>>>> about the AT along with scopes granted and expiry time.   We
>>>>>>>>> should also have a input parameter for resources so that a client
>>>>>>>>> can restrict tokens issued to a subset of the ones granted by the
>>>>>>>>> refresh token.   It would then also be possible to ask a AS for a
>>>>>>>>> token for a unregistered RS and have the AS produce a JWT access
>>>>>>>>> token with the resource as an audience if policy allows.
>>>>>>>>> That however was supposed to be dealt with as part of the 
>>>>>>>>> mixed up
>>>>>>>>> client set of mitigations.
>>>>>>>>> In that the goal was to mitigate the attacks by returning
>>>>>>>>> meta-data about the tokens, and not to require discovery.
>>>>>>>>> We intend to return “iss†and “cleint_id†for the code, and I
>>>>>>>>> intend to discuss at the F2F returning resource for AT as well.
>>>>>>>>> Those mitigate the attack.
>>>>>>>>> I will continue to resist mixing up discovery of configuration
>>>>>>>>> meta-data with mitigation of the attacks.
>>>>>>>>> We return meta-data about the tokens now, because AT are 
>>>>>>>>> opaque to
>>>>>>>>> the client, we neglected to include some of the information for
>>>>>>>>> the client needs to be secure.   We just need to add that in to
>>>>>>>>> the existing flows.
>>>>>>>>> While Phil’s proposal is easier for the AS to implement as an add
>>>>>>>>> on, it puts more of a burden on the client needing to potentially
>>>>>>>>> change how it stores the relationships between AS and RS to
>>>>>>>>> prevent compromise, I think the solution should be biased towards
>>>>>>>>> simplicity on the client side.
>>>>>>>>> If we return the resources as part of the existing meta data the
>>>>>>>>> client checks that against the resource it intends to send the
>>>>>>>>> token to and if it is not in the list then it can’t send the
>>>>>>>>> token.  Simple check every time it gets a new AT, no optionality.
>>>>>>>>> I am not saying anything new Nat has been advocating basically
>>>>>>>>> this for some time, and dis submit a draft.   I prefer to return
>>>>>>>>> the info in the existing format rather than as link headers,  but
>>>>>>>>> that is the largest difference between what Nat and I are saying
>>>>>>>>> with respect to resource.
>>>>>>>>> That is the core of my problem with Phil’s draft.
>>>>>>>>> I guess we will need to have a long conversation in BA.
>>>>>>>>> Regards
>>>>>>>>> John B.
>>>>>>>>>
>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt >>>>>>>> > wrote:
>>>>>>>>>     This draft is a proposed alternate proposal for
>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same
>>>>>>>>>     registry for OAuth Config Metadata as the authors believe 
>>>>>>>>> that
>>>>>>>>>     both solutions are not required, or depending on WG 
>>>>>>>>> discussion
>>>>>>>>>     they will be merged. The intent is to provide a simple
>>>>>>>>>     complete draft for consideration.
>>>>>>>>>     How it works...
>>>>>>>>>     Given that a client has previously discovered an OAuth
>>>>>>>>>     protected resource, the bound configuration method allows a
>>>>>>>>>     client to return the configuration for an oauth authorization
>>>>>>>>>     server that can issue tokens for the resource URI 
>>>>>>>>> specified by
>>>>>>>>>     the client.  The AS is not required to be in the same domain.
>>>>>>>>>      The AS is however required to know if it can issue tokens 
>>>>>>>>> for
>>>>>>>>>     a resource service (which presumes some agreement exists on
>>>>>>>>>     tokens etc).
>>>>>>>>>     The draft does not require that the resource exist (e.g. for
>>>>>>>>>     unconfigured or new user based resources). It only requires
>>>>>>>>>     that the AS service provider agrees it can issue tokens.
>>>>>>>>>     From a security perspective, returning the OAuth service
>>>>>>>>>     configuration for a specified resource URI serves to confirm
>>>>>>>>>     the client is in possession of a valid resource URI ensuring
>>>>>>>>>     the client has received a valid set of endpoints for the
>>>>>>>>>     resource and the associated oauth services.
>>>>>>>>>     I propose that the WG consider the alternate draft carefully
>>>>>>>>>     as well as other submissions and evaluate the broader
>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth 
>>>>>>>>> Discovery.
>>>>>>>>>     Thanks!
>>>>>>>>>     Phil
>>>>>>>>>     @independentid
>>>>>>>>> www.independentid.com 
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Begin forwarded message:
>>>>>>>>>         *From:*internet-drafts@ietf.org 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>         *Subject: New Version Notification for
>>>>>>>>> draft-hunt-oauth-bound-config-00.txt*
>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>> >, "Anthony Nadalin"
>>>>>>>>>         >,
>>>>>>>>>         "Tony Nadalin" >>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         A new version of I-D, 
>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>         has been successfully submitted by Phil Hunt and 
>>>>>>>>> posted to the
>>>>>>>>>         IETF repository.
>>>>>>>>>
>>>>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>>>>         Revision:00
>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>>>         Document date:2016-03-13
>>>>>>>>>         Group:Individual Submission
>>>>>>>>>         Pages:22
>>>>>>>>>         URL:
>>>>>>>>> https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>         Status:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>>>         Htmlized:
>>>>>>>>> https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Abstract:
>>>>>>>>>           This specification defines a mechanism for the 
>>>>>>>>> client of
>>>>>>>>>         an OAuth 2.0
>>>>>>>>>           protected resource service to obtain the configuration
>>>>>>>>>         details of an
>>>>>>>>>           OAuth 2.0 authorization server that is capable of
>>>>>>>>>         authorizing access
>>>>>>>>>           to a specific resource service. The information
>>>>>>>>>         includes the OAuth
>>>>>>>>>           2.0 component endpoint location URIs and as well as
>>>>>>>>>         authorization
>>>>>>>>>           server capabilities.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Please note that it may take a couple of minutes from the
>>>>>>>>>         time of submission
>>>>>>>>>         until the htmlized version and diff are available
>>>>>>>>> attools.ietf.org  
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>         The IETF Secretariat
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>>     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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    I understand the benefit
      of having the client specify where it wants to present the token.
      However, in general, the client knows which kind of resource it's
      going to connect to (even if it doesn't know the exact endpoint).
      For example, if the client speaks PortableContacts, then it can
      potentially discover any PortableContact RS and attempt to get
      authorization to access the endpoints, but the client can't
      connect to the mail RS because it's not coded to work with those
      endpoints.
    
      
    
      Therefore, the client has an understanding of the protocol of the
      RS and can possibly discover related endpoints (what webfinger was
      really designed for) but it can't support some random new
      protocol. As I wrote in my response to John Bradley, I believe
      audience binding should use an abstract identifier not an API
      endpoint.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/15/16 11:40 AM, Phil Hunt wrote:
    
    
    
    
    
      
      Regarding 2.
      

    
      
    
      
    The bound config spec makes no such requirement of
        knowing the and its path structure.  
    
      

    
      
    
      
    If you feel that you have other security measures
        and that clients will always have the proper AS, then you can
        wildcard the whole resource parameter.  It still might be
        advisable to at least check that your clients are using a URL of
        the form https://*.aol.com/* or https://*.partner.com/*.
    
      

    
      
    
      
    The benefit is that at least you know the client is
        intending to wield the token somewhere in your domain or your
        partner’s domain. as opposed to something like news.aol.myevildomain.com.
    
      

    
      
    
      
    The difference here is that security remains the
        responsibility of the service provider in all cases.  The check
        is up to the service provider rather than the client. This means
        that we don’t have to rely on trusting that the client developer
        bothered to check the configuration (as in other proposals that
        modify OAuth protocol itself) — we know well they won’t because
        they won’t have to. The server side validation is trivial.  I’m
        not sure how much easier this can be.  
    
      

    
      
    
      
    
        
        
    
        
    
          
    
            
    On Mar 15, 2016, at 8:09 AM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
              
              
     I worry
                  about two directions I see in this thread...
    
                  
    
                  1. Client's accessing resources dynamically so that
                  discovery is required to know the correct AS, etc.
                  This is pretty much the classic use case for UMA and
                  I'd rather not re-invent the wheel.
    
                  
    
                  2. Creating a tight coupling between RS and AS such
                  that RS endpoint changes must be continually
                  communicated to the AS. If an RS supports multiple
                  AS's then the RS has to deal with "guaranteed"
                  delivery. The AS needs an endpoint to receive such
                  communications. If not dynamic via APIs, then
                  deployment of the new RS is bound by the associated
                  AS's getting and deploying the new endpoints. Can both
                  endpoints of the RS be supported within the AS for
                  some period of time, etc. This is an operation
                  nightmare and almost assuredly going to go wrong in
                  production.
    
                  
    
                  Maybe an OAuth2 "audience binding" spec is what's
                  needed for those deployments that require this. I
                  believe that is what John Bradley is suggesting.
    
                  
    
                  Thanks,
    
                  George
    
                
    
                
    On 3/14/16 7:29 PM, Hans
                  Zandbelt wrote:
    
                
    
                
    +1, I've found the very same in
                  OAuth deployments that I was involved in; the hard
                  part is to give names and descriptions to these
                  concepts so that they cover all use cases and can be
                  applied unambiguously 
    
                  
    
                  Hans. 
    
                  
    
                  On 3/14/16 10:44 PM, Justin Richer wrote: 
    
                  
    I agree that this is
                    valuable, and not just for PoP. In all honesty, 
    
                    it’s not even really required for PoP to function in
                    many cases — it’s 
    
                    just an optimization for one particular kind of key
                    distribution 
    
                    mechanism in that case. 
    
                    
    
                    In the years of deployment experience with OAuth 2,
                    I think we’ve really 
    
                    got three different kinds of things that currently
                    get folded into 
    
                    “scope†that we might want to try separating out
                    better: 
    
                    
    
                    
    
                      - What things do I want to access? (photos,
                    profile) 
    
                      - What actions do I want to take on these things?
                    (read, write, delete) 
    
                      - How long do I want these tokens to work? 
    
                    (offline_access/refresh_token, one time use, next
                    hour, etc) 
    
                    
    
                    
    
                    I think the first one is close to the
                    audience/resource parameters that 
    
                    have been bandied about a few times, including in
                    the current token 
    
                    exchange document. We should be consistent across
                    drafts in that regard. 
    
                    The second is more traditional scope-ish. The third
                    has been patched in 
    
                    with things like “offline_access†in certain APIs. 
    
                    
    
                    Just another vector to think about if we’re going to
                    be adding things 
    
                    like “audience†or “resource†or both to the token
                    requests. 
    
                    
    
                      — Justin 
    
                    
    
                    
    
                    
    On Mar 14, 2016, at
                      6:26 PM, John Bradley <ve7jtb@ve7jtb.com
                      
    
                      <mailto:ve7jtb@ve7jtb.com>>
                      wrote: 
    
                      
    
                      Yes I will work on another proposal for allowing
                      clients to specify 
    
                      what resource they want a token for and providing
                      the meta-data to the 
    
                      client about the resources that a token is valid
                      for. 
    
                      
    
                      We have part of it in the POP key distribution
                      spec and talked about 
    
                      separating it, as it is used more places than just
                      for assigning keys. 
    
                      I know some AS use different token formats for
                      different RS so are 
    
                      all-ready needing to pass the resource in the
                      request to avoid making 
    
                      a mess of scopes. 
    
                      
    
                      John B. 
    
                      
    
                      
    
                      
    
                      
    
                      
    
                      
    On Mar 14, 2016,
                        at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com
                        
    
                        <mailto:phil.hunt@oracle.com>>
                        wrote: 
    
                        
    
                        Inline 
    
                        
    
                        Phil 
    
                        
    
                        On Mar 14, 2016, at 14:13, John Bradley <ve7jtb@ve7jtb.com
                        
    
                        <mailto:ve7jtb@ve7jtb.com>>
                        wrote: 
    
                        
    
                        
    We had two
                          mandates.  One was to provide a spec for AS
                          metadata. 
    
                          The other was to mitigate the client mixup
                          attack.  The request was 
    
                          to do the latter without requiring the former
                          for clients that don’t 
    
                          otherwise need discovery. 
    
                        
    
                        There is no mandate for any of this. See 
    
                        http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
                        
    
                        
     
    
                          Returning the issuer and client_id from the
                          authorization endpoint 
    
                          and the client checking them can be done by
                          the client without 
    
                          discovery. 
    
                        
    
                        
    
                        How does this address the issue of whether the
                        client is talking to 
    
                        the wrong endpoint? 
    
                        
     
    
                          Any client that has the resource and issuer
                          hard coded probably 
    
                          doesn’t need discovery. 
    
                        
    
                        We agree 
    
                        
    
                        
    
                        
    One of the
                          things that a client will need discovery for
                          is to find 
    
                          the RS, so requiring the client to know the RS
                          URI before getting 
    
                          the AS config seems backwards to me. 
    
                        
    
                        How can you make an assumption on order? You
                        seem to be conflating 
    
                        authentication with authorization by assuming
                        the identity drives 
    
                        what the resource is. 
    
                        
    
                        There are lots of applications that require user
                        rights but are not 
    
                        identify centric. For example a document
                        service. 
    
                        
     
    
                          Unless the client tells the AS where it
                          intends to use the token we 
    
                          will be leaving a security hole because the
                          bearer tokens will have 
    
                          too loose an audience if they have one at all.
                          
    
                        
    
                        This is the biggest risk we have IMHO. 
    
                        
     
    
                          True you are telling the AS (Webfinger
                          service) what the RS is but 
    
                          that is not at a place that is useful in the
                          token production process. 
    
                        
    
                        
    
                        This has nothing to do with token production. 
    
                        
    
                        What we want to ensure is whether an honest
                        client is correctly 
    
                        configured and has not been mislead - eg by a
                        phishing page. 
    
                        
     
    
                          I also think there are use cases where the AS
                          doesn’t know all the 
    
                          possible RS.   That is not something that a
                          out of band check can 
    
                          address. 
    
                        
    
                        
    
                        May be. Lets identify them. 
    
                        
    
                        
    There are also
                          cases where a token might be good at multiple
                          RS 
    
                          endpoints intentionally. 
    
                        
    
                        
    
                        
     In your
                          solution the client would need to make a
                          discovery request 
    
                          for each endpoint. 
    
                        
    
                        Sure. Otherwise how would it know if there is
                        one AS or a pool of AS 
    
                        servers assigned to each instance? 
    
                        
    Those requests
                          lack the context of who the client and
                          resource owner 
    
                          are.  I think that will be a problem in some
                          use cases. 
    
                        
    
                        
    
                        Not sure I agree. This is about discovering a
                        valid set of endpoints. 
    
                        For mitm, we mainly want to check the hostname
                        is correct. If a 
    
                        client chooses evil.com <http://evil.com/>
                        the cert can be valid and 
    
                        TLS will pass. How does it otherwise know it is
                        supposed to talk to 
    
                        res.example.com
                        <http://res.example.com/>?
                        
    
                        
     
    
                          If this is added to the token endpoint it
                          would be checked when code 
    
                          or refresh are exchanged, not every time the
                          token is used. 
    
                        
    
                        Your proposal requires rhe client to check. I am
                        not clear how the AS 
    
                        can know the exact uri. It is far easier to
                        validate than to lookup 
    
                        since as you say the client may be authorized to
                        use multiple ASs. 
    
                        
    With a out of
                          band check the client would never know if a RS
                          was 
    
                          removed/revoked. 
    
                        
    
                        
    
                        Not sure that is in scope. 
    
                        
    
                        None of the current proposals address this
                        issue. 
    
                        
     
    
                          I don’t see checking when refreshing a token
                          as something that is a 
    
                          huge burden. 
    
                        
    
                        
    
                        Still its a lot more than once. 
    
                        
    
                        Why don't you draft another alternative? 
    
                        
     
    
                          If the server wants to do the check on it’s
                          side then we could 
    
                          require the client to send the RS URI in the
                          token request. that way 
    
                          you really know the client is not going to get
                          a token for the wrong 
    
                          RS endpoint. 
    
                          If you check out of band in discovery you
                          really have no idea if the 
    
                          client is checking. 
    
                        
    
                        
    
                        In the new webfinger draft, the client isn't
                        checking. The service 
    
                        provider simply does not disclose oauth
                        information to misconfigured 
    
                        clients. 
    
                        
     
    
                          John B. 
    
                          
    
                          
    
                          
    On Mar 14,
                            2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com
                            
    
                            <mailto:phil.hunt@oracle.com>>
                            wrote: 
    
                            
    
                            Thanks to Mike and John for their feedback. 
                            I’ll take each in turn: 
    
                            
    
                            Mike, 
    
                            
    
                            Regarding your suggested amendments 
    
                            
    
                            Item 1: Returning the config URL would
                            create two problems. One,it 
    
                            makes bound discovery a two-step process -
                            that adds complexity. 
    
                             It seems far simpler to mandate TLS (which
                            I think it already does 
    
                            in the security considerations). 
    
                            
    
                            The two-step process allows the current
                            discovery process to 
    
                            continue. I disagree with this. This is why
                            I put forward an 
    
                            “alternate" draft that is almost the same
                            but simply adds the check 
    
                            before returning the configuration data.  I
                            worry that  developers 
    
                            would have no incentive to do the two-step
                            approach. They would 
    
                            just start at step 2 which in turn puts AS’s
                            at risk of exposing 
    
                            tokens because it works. This makes OAuth
                            promiscuous. 
    
                            
    
                            Regarding existing implementations. Most of
                            those implementations 
    
                            are for OIDC.  I think it makes sense for
                            OIDF to continue use of 
    
                            OIDC's discovery spec because the UserInfo
                            endpoint is well defined 
    
                            and the likelihood of a client mis-informed
                            about the resource 
    
                            endpoint is not there.  IMO This does not
                            apply to the broader 
    
                            OAuth community. 
    
                            
    
                            Item 2:  It may be appropriate to have a
                            separate configuration 
    
                            registry specification, but I think we
                            should hold off until we 
    
                            have a complete solution and then make the
                            decision what drafts 
    
                            should exist and how many pieces.  A big
                            concern is the perceived 
    
                            complexity of multiple solutions and
                            multiple drafts. 
    
                            
    
                            As to John Bradley’s comments: 
    
                            
    
                            Re: Discovery is the wrong place to mitigate
                            threats. 
    
                            I’m confused by this.  Our mandate was to
                            solve a security threat 
    
                            by having a discovery specification to
                            prevent clients being 
    
                            mis-lead about endpoints (of which resource
                            service is one) in an 
    
                            oauth protected exchange.  Maybe what you
                            mean is we should not use 
    
                            .well-known of any kind and we should just
                            create a “/Config†
    
                            endpoint to OAuth? 
    
                            
    
                            Re: Your proposal for MITM mitigation 
    
                            You propose that instead the resource
                            endpoint check should be in 
    
                            the oauth protocol itself.  The difference
                            is that validation is 
    
                            transferred back to the client to get it
                            right. As well, without 
    
                            the client informing the AS, I can’t see a
                            way for the AS to know 
    
                            what endpoint the client is using.  The
                            webfinger approach does 
    
                            this once and only requires that the host
                            name be checked in many 
    
                            cases. 
    
                            
    
                            As a principle, the members have discussed
                            many times that the AS 
    
                            service should do validation when possible —
                            this was particularly 
    
                            true at the Germany meeting when this came
                            up. This is why I prefer 
    
                            the client tell the service provider what it
                            intends to do and the 
    
                            service provider can fail that request
                            immediately if necessary. We 
    
                            don’t have to depend on the developer
                            getting the spec correct to 
    
                            fail the correct way. 
    
                            
    
                            I worry that adding more parameters to the
                            authz and token protocol 
    
                            flows increases complexity and attack
                            surface. It also means per 
    
                            authorization validation has to take place
                            vs. a one-time 
    
                            validation at config time.  Placing it in
                            the configuration lookup 
    
                            phase (whether via web finger or just a
                            special OAuth endpoint) 
    
                            seems more appropriate and far less complex
                            - as the request itself 
    
                            is simple and has only one parameter. Here
                            we are not considered 
    
                            about legitimacy of the client. we’re just
                            concerned with the issue 
    
                            "has the client been correctly informed?†
    
                            
    
                            That said, it may be that when we consider
                            all the use cases, some 
    
                            combination of AS protocol and discovery may
                            be both needed. I’m 
    
                            not ready to make conclusions about this. 
                            The current 
    
                            oauth-discovery spec seems to put future
                            generic clients at risk 
    
                            and that is my primary concern. 
    
                            
    
                            Best Regards, 
    
                            
    
                            Phil 
    
                            
    
                            @independentid 
    
                            www.independentid.com
                            <http://www.independentid.com/>
                            
    
                            phil.hunt@oracle.com
                            <mailto:phil.hunt@oracle.com>
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    On Mar 13,
                              2016, at 10:28 PM, Mike Jones 
    
                              <Michael.Jones@microsoft.com
                              <mailto:Michael.Jones@microsoft.com>>

                              
    
                              wrote: 
    
                              
    
                              Thanks for posting this, Phil.  It
                              provides a concrete example of 
    
                              a way that protected resource discovery
                              could be added to 
    
                              authorization server metadata discovery,
                              and as such, should 
    
                              provide useful input for working group
                              discussions on this topic. 
    
                              It’s always great when someone takes the
                              time to write an actual 
    
                              draft that can be examined and
                              implemented, and I appreciate you 
    
                              doing that. 
    
                              The content of your draft points out that
                              there appears to be 
    
                              complete agreement on what the
                              authorization server metadata 
    
                              format should be, which is great!  I’ll
                              note that Section 3 of 
    
                              draft-hunt-oauth-bound-config-00 titled
                              “Authorization Server 
    
                              Metadata†is an exact copy of Section 2 of
                              
    
                              draft-ietf-oauth-discovery-01 (with the
                              same title), modulo 
    
                              applying a correction suggested by the
                              working group.  To me this 
    
                              suggests that the authorization server
                              metadata definitions in 
    
                              draft-ietf-oauth-discovery (which is now
                              the whole normative 
    
                              content of the draft) are clearly ready
                              for standardization, since 
    
                              even your alternative proposal includes
                              them verbatim. 
    
                              Reading your draft, the problem I have
                              with it is that you are 
    
                              returning the AS metadata only as a
                              WebFinger response, rather 
    
                              than as an https-protected resource
                              published by the authorization 
    
                              server.  The choice to only return this
                              via WebFinger makes your 
    
                              draft incompatible with most deployed
                              implementations of OAuth 
    
                              metadata, including the 22 implementations
                              using it listed 
    
                              athttp://openid.net/certification/(see
                              the “OP Config†column in 
    
                              the table) andOAuth 2.0 libraries such as
                              Microsoft’s “ADAL†
    
                              library, which uses the metadata path for
                              client configuration. 
    
                              Without having ASs provide the metadata as
                              an https-protected 
    
                              resource, implementations such as ADAL
                              can’t use it for client 
    
                              configuration as the currently do. 
    
                              Therefore, I would request that you make
                              these minor revisions to 
    
                              your draft and republish, so as to provide
                              a unified way forward 
    
                              that is compatible with all known existing
                              OAuth Discovery 
    
                              deployments: 
    
                              1.Modify your section 2 “Authorization
                              Server WebFinger Discovery†
    
                              to have the WebFinger request return the
                              issuer identifier for the 
    
                              AS as the “WebFinger “rel†value, rather
                              than returning the 
    
                              metadata values by value as the
                              “properties†value. 
    
                              2.Reference the metadata definitions from
                              Section 2 of 
    
                              draft-ietf-oauth-discovery, rather than
                              duplicating them in your 
    
                              Section 3. 
    
                              That would have the advantage of paring
                              your draft down to only 
    
                              the new things that it proposes, enabling
                              them to be more clearly 
    
                              understood and evaluated on their own
                              merits.  I look forward to 
    
                              the discussions of ways of performing
                              additional kinds of OAuth 
    
                              discovery, and consider your draft a
                              valuable input to those 
    
                              discussions. 
    
                                                                                       

                              Best wishes, 
    
                                                                                       

                              -- Mike 
    
                              *From:*OAuth [mailto:oauth-bounces@ietf.org]*On
                              Behalf Of*John Bradley 
    
                              *Sent:*Sunday, March 13, 2016 6:45 PM 
    
                              *To:*Phil Hunt <phil.hunt@oracle.com
                              <mailto:phil.hunt@oracle.com>>

                              
    
                              *Cc:*oauth <oauth@ietf.org
                              <mailto:oauth@ietf.org>>

                              
    
                              *Subject:*Re: [OAUTH-WG] New Version
                              Notification for 
    
                              draft-hunt-oauth-bound-config-00.txt 
    
                              As I have told Phil off list. 
    
                              Discovery is the wrong place to try and
                              provide security against 
    
                              man in the middle attacks on the RS. 
    
                              This requires the client to know what the
                              RS URI is before 
    
                              retrieving the information on the AS
                              Configuration. 
    
                              The proposal Mike and I have been working
                              on requires the client 
    
                              to have a notion of what API it is looking
                              for and retrieve the 
    
                              .well-known file for that API from the
                              issuer.   That allows a 
    
                              protocol like Connect to register its own
                              config file that can 
    
                              point to the RS. 
    
                              If the API specific well known is not
                              available the client can try 
    
                              the default oauth-server one. 
    
                              That then allows us to deal with
                              restricting where AT are 
    
                              presented as part of the protocol rather
                              then dragging discovery 
    
                              in as a requirement. 
    
                              In my opinion the resource the token is
                              targeted to should be 
    
                              separated from the scope and returned as
                              part of the meta-data 
    
                              about the AT along with scopes granted and
                              expiry time.   We 
    
                              should also have a input parameter for
                              resources so that a client 
    
                              can restrict tokens issued to a subset of
                              the ones granted by the 
    
                              refresh token.   It would then also be
                              possible to ask a AS for a 
    
                              token for a unregistered RS and have the
                              AS produce a JWT access 
    
                              token with the resource as an audience if
                              policy allows. 
    
                              That however was supposed to be dealt with
                              as part of the mixed up 
    
                              client set of mitigations. 
    
                              In that the goal was to mitigate the
                              attacks by returning 
    
                              meta-data about the tokens, and not to
                              require discovery. 
    
                              We intend to return “iss†and “cleint_idâ€
                              for the code, and I 
    
                              intend to discuss at the F2F returning
                              resource for AT as well. 
    
                              Those mitigate the attack. 
    
                              I will continue to resist mixing up
                              discovery of configuration 
    
                              meta-data with mitigation of the attacks.
                              
    
                              We return meta-data about the tokens now,
                              because AT are opaque to 
    
                              the client, we neglected to include some
                              of the information for 
    
                              the client needs to be secure.   We just
                              need to add that in to 
    
                              the existing flows. 
    
                              While Phil’s proposal is easier for the AS
                              to implement as an add 
    
                              on, it puts more of a burden on the client
                              needing to potentially 
    
                              change how it stores the relationships
                              between AS and RS to 
    
                              prevent compromise, I think the solution
                              should be biased towards 
    
                              simplicity on the client side. 
    
                              If we return the resources as part of the
                              existing meta data the 
    
                              client checks that against the resource it
                              intends to send the 
    
                              token to and if it is not in the list then
                              it can’t send the 
    
                              token.  Simple check every time it gets a
                              new AT, no optionality. 
    
                              I am not saying anything new Nat has been
                              advocating basically 
    
                              this for some time, and dis submit a
                              draft.   I prefer to return 
    
                              the info in the existing format rather
                              than as link headers,  but 
    
                              that is the largest difference between
                              what Nat and I are saying 
    
                              with respect to resource. 
    
                              That is the core of my problem with Phil’s
                              draft. 
    
                              I guess we will need to have a long
                              conversation in BA. 
    
                              Regards 
    
                              John B. 
    
                              
    
                                  On Mar 13, 2016, at 8:12 PM, Phil Hunt
                              <phil.hunt@oracle.com
                              
    
                                  <mailto:phil.hunt@oracle.com>>
                              wrote: 
    
                                  This draft is a proposed alternate
                              proposal for 
    
                                  draft-ietf-oauth-discovery.  As such,
                              it contains the same 
    
                                  registry for OAuth Config Metadata as
                              the authors believe that 
    
                                  both solutions are not required, or
                              depending on WG discussion 
    
                                  they will be merged. The intent is to
                              provide a simple 
    
                                  complete draft for consideration. 
    
                                  How it works... 
    
                                  Given that a client has previously
                              discovered an OAuth 
    
                                  protected resource, the bound
                              configuration method allows a 
    
                                  client to return the configuration for
                              an oauth authorization 
    
                                  server that can issue tokens for the
                              resource URI specified by 
    
                                  the client.  The AS is not required to
                              be in the same domain. 
    
                                   The AS is however required to know if
                              it can issue tokens for 
    
                                  a resource service (which presumes
                              some agreement exists on 
    
                                  tokens etc). 
    
                                  The draft does not require that the
                              resource exist (e.g. for 
    
                                  unconfigured or new user based
                              resources). It only requires 
    
                                  that the AS service provider agrees it
                              can issue tokens. 
    
                                  From a security perspective, returning
                              the OAuth service 
    
                                  configuration for a specified resource
                              URI serves to confirm 
    
                                  the client is in possession of a valid
                              resource URI ensuring 
    
                                  the client has received a valid set of
                              endpoints for the 
    
                                  resource and the associated oauth
                              services. 
    
                                  I propose that the WG consider the
                              alternate draft carefully 
    
                                  as well as other submissions and
                              evaluate the broader 
    
                                  discovery problem before proceeding
                              with WGLC on OAuth Discovery. 
    
                                  Thanks! 
    
                                  Phil 
    
                                  @independentid 
    
                                  www.independentid.com
                              <http://www.independentid.com/>
                              
    
                                  phil.hunt@oracle.com
                              <mailto:phil.hunt@oracle.com>
                              
    
                              
    
                              
    
                                      Begin forwarded message: 
    
                                      *From:*internet-drafts@ietf.org 
    
                                      <mailto:internet-drafts@ietf.org>
                              
    
                                      *Subject: New Version Notification
                              for 
    
                                     
                              draft-hunt-oauth-bound-config-00.txt* 
    
                                      *Date:*March 13, 2016 at 3:53:37
                              PM PDT 
    
                                      *To:*"Phil Hunt" <phil.hunt@yahoo.com
                              
    
                                      <mailto:phil.hunt@yahoo.com>>,

                              "Anthony Nadalin" 
    
                                      <tonynad@microsoft.com
                              <mailto:tonynad@microsoft.com>>,

                              
    
                                      "Tony Nadalin" <tonynad@microsoft.com
                              
    
                                      <mailto:tonynad@microsoft.com>>

                              
    
                              
    
                              
    
                                      A new version of I-D,
                              draft-hunt-oauth-bound-config-00.txt 
    
                                      has been successfully submitted by
                              Phil Hunt and posted to the 
    
                                      IETF repository. 
    
                              
    
                                      Name:draft-hunt-oauth-bound-config
                              
    
                                      Revision:00 
    
                                      Title:OAuth 2.0 Bound
                              Configuration Lookup 
    
                                      Document date:2016-03-13 
    
                                      Group:Individual Submission 
    
                                      Pages:22 
    
                                      URL: 
    
                                     
                              https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                                      Status: 
    
                                      https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                              
    
                                      Htmlized: 
    
                                      https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                              
    
                              
    
                              
    
                                      Abstract: 
    
                                        This specification defines a
                              mechanism for the client of 
    
                                      an OAuth 2.0 
    
                                        protected resource service to
                              obtain the configuration 
    
                                      details of an 
    
                                        OAuth 2.0 authorization server
                              that is capable of 
    
                                      authorizing access 
    
                                        to a specific resource service. 
                              The information 
    
                                      includes the OAuth 
    
                                        2.0 component endpoint location
                              URIs and as well as 
    
                                      authorization 
    
                                        server capabilities. 
    
                              
    
                              
    
                              
    
                              
    
                                      Please note that it may take a
                              couple of minutes from the 
    
                                      time of submission 
    
                                      until the htmlized version and
                              diff are available 
    
                                      attools.ietf.org
                              <http://tools.ietf.org/>.
                              
    
                              
    
                                      The IETF Secretariat 
    
                              
    
                                 
                              _______________________________________________
                              
    
                                  OAuth mailing list 
    
                                  OAuth@ietf.org
                              <mailto:OAuth@ietf.org>
                              
    
                                  https://www.ietf.org/mailman/listinfo/oauth
                              
    
                            
    
                            
    
                          
    
                          
    
                        
    
                      
    
                      
    
                      _______________________________________________ 
    
                      OAuth mailing list 
    
                      OAuth@ietf.org
                      <mailto:OAuth@ietf.org>
                      
    
                      https://www.ietf.org/mailman/listinfo/oauth
                      
    
                    
    
                    
    
                    
    
                    
    
                    _______________________________________________ 
    
                    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
    
            
    
          
    
        
    
        
    
      
    
    
    
    
    
    
    -- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

    
  


--------------060909000706030806000105--


From nobody Tue Mar 15 09:35:14 2016
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 1EE8D12DAF4 for ; Tue, 15 Mar 2016 09:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 xZpYKTH6e41V for ; Tue, 15 Mar 2016 09:34:46 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 397EC12DAF0 for ; Tue, 15 Mar 2016 09:34:27 -0700 (PDT)
Received: by mail-lb0-x22b.google.com with SMTP id bc4so30540357lbc.2 for ; Tue, 15 Mar 2016 09:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=HYEtJleU74SpDpZaLewOG+ZGZ4x/jnoZtiTUBeF0o2k=; b=KJI3lyRAv6lCHuVvgZgi14BIYdHVMHCckJDyGqTnsW+ufnqNK0H1ZEyqCb9A2VykMO fFPrrhiEHPDGwjy30WKzI5iFIK7owQVXAInIBX37+pDwUrUJR/cX4+l3I1mPTIqZtBe6 wM9QZW6UYypniPO1pnnVL9Z5RKrNasknp/Pjopb/kP/VGQ1qJdXWzdpiYLLpfp3HDhdX wgc9VLB0j0brlPNrJ8z+HYa3bxYFqwMsHv97BiQWzysDT0QNT/kjUNbRibYfEoVubFlU Zj0AzXtR/uG1nae0yWwiELlDTutBNyaMqQFQMmYDa+AJco+2NFC7k8+zZrYb+DGFf3tz tAIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HYEtJleU74SpDpZaLewOG+ZGZ4x/jnoZtiTUBeF0o2k=; b=AAvv8xAVZwPtvl4i+0Rt11LVC2KxTBfJgAyDgSxAj4nMVzCywdU4zN6b5BcIED8BkD 2uZRLlfczQacDAX+2SxEKMigZ97g9XPvEt3ktKgGIAKeFjTmGwEZuSuElUPaoCnNWL1B io5q34r8w+bJTh+m4HnU4cJ4QDgKgOHKApEFdNAZ3yYMwQDb7zd/1XGGleIT+EBoGMe3 z/imzwQ7hTLaeen3MWy9nJoLwYhAOuYkCDVTyz2ppID9SYCVdxx9XrrhzAWefz0uIU55 0mVvJ8zRLRrpVsBy89wz8tiytNLhdlKMb4OcAIlZGJflKf9uX35m+PJn532nkawN1hlP +uiw==
X-Gm-Message-State: AD7BkJJQRpDNF/JvLRJhnzfqmjndKHiOh4JQCruvTpEsvCcC1g8ln71RTrA+0IfGniifG9vVU2ojHtWed3Sw5A==
X-Received: by 10.25.16.207 with SMTP id 76mr11036025lfq.133.1458059665265; Tue, 15 Mar 2016 09:34:25 -0700 (PDT)
MIME-Version: 1.0
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com>
In-Reply-To: <56E8079C.3010402@gmail.com>
From: Thomas Broyer 
Date: Tue, 15 Mar 2016 16:34:15 +0000
Message-ID: 
To: Sergey Beryozkin , oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a113fb41a68e1cb052e18f86c
Archived-At: 
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 16:34:52 -0000

--001a113fb41a68e1cb052e18f86c
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin 
wrote:

> Hi
>
> After following the recent thread on multiple authorization servers, but
> also reading some other related threads, I have a question related to
> when the token introspection can be avoided.
>
> My understanding has been that given that access tokens are opaque the
> RS does not know anything about its content, hence that was the purpose
> of the token introspection spec: provide an interoperable way for RS to
> submit a token to AS and get the token data for RS to make a final
> decision about this token.
>
> I think if the access tokens are really opaque, i.e, they are sequences
> RS can not look into, then having the introspection option is the only
> way to check what the token is really about.
>
> But the recent replies with respect to using JWS or JWE tokens have
> confused me.
>
> 1. AccessToken as JWS JWT Token:
>
> RS can easily look into it, but Justin mentioned that in one case they
> first validate this JWS token and then forward it for some further
> introspection. Why start introspecting if the token has been validated
> and its content is visible ?
>

Because you want to know whether it's been revoked before its expiration.
Introspection is the only way (unless AS and RS are colocated), as only the
AS knows.


> Perhaps because some token data which are sensitive are only visible in
> the introspection response ? If yes then why use a self-contained token
> if some more external data are associated with it.
>

If the token is not valid (bad issuer, bad signature, expired; or if the
scopes are included: insufficient scopes), it saves you a request to the
introspection endpoint ;-)
Only if the token passes the first checks would you introspect it to see if
it's still active (not revoked) and possibly retrieve more data about it.


> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of
> times recently, Jonh B. suggested in the other thread the introspection
> may not be needed (sorry if I misread it).
> The question here, how can RS deal with a JWE token, it would need to
> share the decrypting key with AS.
>

I think that was the idea yes (didn't someone commented on the thread that
they deployed JWT tokens with shared secrets or symmetric keys?)


> So, is introspection needed only for the completely opaque tokens or it
> is also needed for JWS and JWE tokens. I'd say it might be reasonable to
> skip it in case of JWS, depending on the specific requirements (as the
> expiry, issuer, will be typically set in JWS JWT), while with JWE I can
> not see how RS can avoid introspecting unless it shares the
> secret/private key with AS.
>

As Justin mentioned in the other thread: introspection is useful
(required?) for checking the "liveness" of the token.

Side-note: given the size of a JWT compared to some "simpler", opaque
tokens (mere identifiers), and the fact introspection response are likely
to be cached for a few minutes by the RS, I wonder if using a JWT so you
can possibly avoid an introspection request outweights (sic!) the bloat of
a JWT sent repeatedly over the network (possibly a network with high
latency, low bandwidth, and sometimes paid based on exchanged volumes).
This is rhetoric actually: I side on the "small token that require
introspection" until someone comes with a compelling argument to go the
other way.

--001a113fb41a68e1cb052e18f86c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On Tue=
, Mar 15, 2016 at 2:02 PM Sergey Beryozkin <sberyozkin@gmail.com> wrote:
    Hi
    

    
After following the recent thread on multiple authorization servers, but
also reading some other related threads, I have a question related to
    
when the token introspection can be avoided.
    

    
My understanding has been that given that access tokens are opaque the
    
RS does not know anything about its content, hence that was the purpose
    
of the token introspection spec: provide an interoperable way for RS to
    
submit a token to AS and get the token data for RS to make a final
    
decision about this token.
    

    
I think if the access tokens are really opaque, i.e, they are sequences
    
RS can not look into, then having the introspection option is the only
    
way to check what the token is really about.
    

    
But the recent replies with respect to using JWS or JWE tokens have
    
confused me.
    

    
1. AccessToken as JWS JWT Token:
    

    
RS can easily look into it, but Justin mentioned that in one case they
    
first validate this JWS token and then forward it for some further
    
introspection. Why start introspecting if the token has been validated
    
and its content is visible ?

    Because yo=
u want to know whether it's been revoked before its expiration. Introsp=
ection is the only way (unless AS and RS are colocated), as only the AS kno=
ws.
    =C2=A0
    
Perhaps because some token data which are sensitive are only visible in
    
the introspection response ? If yes then why use a self-contained token
    
if some more external data are associated with it.
    If the token is not valid (bad issuer, bad signature, expired; =
or if the scopes are included: insufficient scopes), it saves you a request=
 to the introspection endpoint ;-)
    Only if the token passes the f=
irst checks would you introspect it to see if it's still active (not re=
voked) and possibly retrieve more data about it.
    =C2=A0
    
2. AccessToken as JWE JWT Token: this option was mentioned a couple of
    
times recently, Jonh B. suggested in the other thread the introspection
    
may not be needed (sorry if I misread it).
    
The question here, how can RS deal with a JWE token, it would need to
    
share the decrypting key with AS.

    I thi=
nk that was the idea yes (didn't someone commented on the thread that t=
hey deployed JWT tokens with shared secrets or symmetric keys?)
    =
=C2=A0
    
So, is introspection needed only for the completely opaque tokens or it
    
is also needed for JWS and JWE tokens. I'd say it might be reasonable t=
o
    
skip it in case of JWS, depending on the specific requirements (as the
    
expiry, issuer, will be typically set in JWS JWT), while with JWE I can
    
not see how RS can avoid introspecting unless it shares the
    
secret/private key with AS.

    As Justin m=
entioned in the other thread: introspection is useful (required?) for check=
ing the "liveness" of the token.

    Side-no=
te: given the size of a JWT compared to some "simpler", opaque to=
kens (mere identifiers), and the fact introspection response are likely to =
be cached for a few minutes by the RS, I wonder if using a JWT so you can p=
ossibly avoid an introspection request outweights (sic!) the bloat of a JWT=
 sent repeatedly over the network (possibly a network with high latency, lo=
w bandwidth, and sometimes paid based on exchanged volumes).
    This=
 is rhetoric actually: I side on the "small token that require introsp=
ection" until someone comes with a compelling argument to go the other=
 way.
    

--001a113fb41a68e1cb052e18f86c--


From nobody Tue Mar 15 09:44:31 2016
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 665D512DB10 for ; Tue, 15 Mar 2016 09:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 sVUJYQMBpop3 for ; Tue, 15 Mar 2016 09:44:25 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 C26A612DAC0 for ; Tue, 15 Mar 2016 09:42:31 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2FGgRYC000341 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2016 16:42:28 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2FGgQMl027022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 16:42:26 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2FGgQeM028301; Tue, 15 Mar 2016 16:42:26 GMT
Received: from [25.168.240.211] (/24.114.25.254) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Mar 2016 09:42:25 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-01EAC0E5-9C90-41B0-8D21-E5340D0BF4F4
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: <56E831D4.1090609@aol.com>
Date: Tue, 15 Mar 2016 09:42:22 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <54C3E288-6E8E-4AF3-AA60-7FD82417A4E4@oracle.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com>  <56E831D4.1090609@aol.com>
To: George Fletcher 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 16:44:30 -0000

--Apple-Mail-01EAC0E5-9C90-41B0-8D21-E5340D0BF4F4
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks George

I think we have to discuss cases where mitigstion is not needed such as oidc=
.=20

My concern is to make the mitigation choice the AS's and not the client.=20

Phil

> On Mar 15, 2016, at 09:01, George Fletcher  wrote:
>=20
> I understand the benefit of having the client specify where it wants to pr=
esent the token. However, in general, the client knows which kind of resourc=
e it's going to connect to (even if it doesn't know the exact endpoint). For=
 example, if the client speaks PortableContacts, then it can potentially dis=
cover any PortableContact RS and attempt to get authorization to access the e=
ndpoints, but the client can't connect to the mail RS because it's not coded=
 to work with those endpoints.
>=20
> Therefore, the client has an understanding of the protocol of the RS and c=
an possibly discover related endpoints (what webfinger was really designed f=
or) but it can't support some random new protocol. As I wrote in my response=
 to John Bradley, I believe audience binding should use an abstract identifi=
er not an API endpoint.
>=20
> Thanks,
> George
>=20
>> On 3/15/16 11:40 AM, Phil Hunt wrote:
>> Regarding 2.
>>=20
>> The bound config spec makes no such requirement of knowing the and its pa=
th structure. =20
>>=20
>> If you feel that you have other security measures and that clients will a=
lways have the proper AS, then you can wildcard the whole resource parameter=
.  It still might be advisable to at least check that your clients are using=
 a URL of the form https://*.aol.com/* or https://*.partner.com/*.
>>=20
>> The benefit is that at least you know the client is intending to wield th=
e token somewhere in your domain or your partner=E2=80=99s domain. as oppose=
d to something like news.aol.myevildomain.com.
>>=20
>> The difference here is that security remains the responsibility of the se=
rvice provider in all cases.  The check is up to the service provider rather=
 than the client. This means that we don=E2=80=99t have to rely on trusting t=
hat the client developer bothered to check the configuration (as in other pr=
oposals that modify OAuth protocol itself) =E2=80=94 we know well they won=E2=
=80=99t because they won=E2=80=99t have to. The server side validation is tr=
ivial.  I=E2=80=99m not sure how much easier this can be. =20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 15, 2016, at 8:09 AM, George Fletcher  wrote:
>>>=20
>>> I worry about two directions I see in this thread...
>>>=20
>>> 1. Client's accessing resources dynamically so that discovery is require=
d to know the correct AS, etc. This is pretty much the classic use case for U=
MA and I'd rather not re-invent the wheel.
>>>=20
>>> 2. Creating a tight coupling between RS and AS such that RS endpoint cha=
nges must be continually communicated to the AS. If an RS supports multiple A=
S's then the RS has to deal with "guaranteed" delivery. The AS needs an endp=
oint to receive such communications. If not dynamic via APIs, then deploymen=
t of the new RS is bound by the associated AS's getting and deploying the ne=
w endpoints. Can both endpoints of the RS be supported within the AS for som=
e period of time, etc. This is an operation nightmare and almost assuredly g=
oing to go wrong in production.
>>>=20
>>> Maybe an OAuth2 "audience binding" spec is what's needed for those deplo=
yments that require this. I believe that is what John Bradley is suggesting.=

>>>=20
>>> Thanks,
>>> George
>>>=20
>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>> +1, I've found the very same in OAuth deployments that I was involved i=
n; the hard part is to give names and descriptions to these concepts so that=
 they cover all use cases and can be applied unambiguously=20
>>>>=20
>>>> Hans.=20
>>>>=20
>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>> I agree that this is valuable, and not just for PoP. In all honesty,=20=

>>>>> it=E2=80=99s not even really required for PoP to function in many case=
s =E2=80=94 it=E2=80=99s=20
>>>>> just an optimization for one particular kind of key distribution=20
>>>>> mechanism in that case.=20
>>>>>=20
>>>>> In the years of deployment experience with OAuth 2, I think we=E2=80=99=
ve really=20
>>>>> got three different kinds of things that currently get folded into=20
>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out bette=
r:=20
>>>>>=20
>>>>>=20
>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>   - What actions do I want to take on these things? (read, write, dele=
te)=20
>>>>>   - How long do I want these tokens to work?=20
>>>>> (offline_access/refresh_token, one time use, next hour, etc)=20
>>>>>=20
>>>>>=20
>>>>> I think the first one is close to the audience/resource parameters tha=
t=20
>>>>> have been bandied about a few times, including in the current token=20=

>>>>> exchange document. We should be consistent across drafts in that regar=
d.=20
>>>>> The second is more traditional scope-ish. The third has been patched i=
n=20
>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.=20
>>>>>=20
>>>>> Just another vector to think about if we=E2=80=99re going to be adding=
 things=20
>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or both t=
o the token requests.=20
>>>>>=20
>>>>>   =E2=80=94 Justin=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>>> > wrote:=20
>>>>>>=20
>>>>>> Yes I will work on another proposal for allowing clients to specify=20=

>>>>>> what resource they want a token for and providing the meta-data to th=
e=20
>>>>>> client about the resources that a token is valid for.=20
>>>>>>=20
>>>>>> We have part of it in the POP key distribution spec and talked about=20=

>>>>>> separating it, as it is used more places than just for assigning keys=
.=20
>>>>>> I know some AS use different token formats for different RS so are=20=

>>>>>> all-ready needing to pass the resource in the request to avoid making=
=20
>>>>>> a mess of scopes.=20
>>>>>>=20
>>>>>> John B.=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>> > wrote:=20
>>>>>>>=20
>>>>>>> Inline=20
>>>>>>>=20
>>>>>>> Phil=20
>>>>>>>=20
>>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>>> > wrote:=20
>>>>>>>=20
>>>>>>>> We had two mandates.  One was to provide a spec for AS metadata.=20=

>>>>>>>> The other was to mitigate the client mixup attack.  The request was=
=20
>>>>>>>> to do the latter without requiring the former for clients that don=E2=
=80=99t=20
>>>>>>>> otherwise need discovery.
>>>>>>> There is no mandate for any of this. See=20
>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01=
-22.txt=20
>>>>>>>>=20
>>>>>>>> Returning the issuer and client_id from the authorization endpoint=20=

>>>>>>>> and the client checking them can be done by the client without=20
>>>>>>>> discovery.
>>>>>>>=20
>>>>>>> How does this address the issue of whether the client is talking to=20=

>>>>>>> the wrong endpoint?=20
>>>>>>>>=20
>>>>>>>> Any client that has the resource and issuer hard coded probably=20
>>>>>>>> doesn=E2=80=99t need discovery.
>>>>>>> We agree=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> One of the things that a client will need discovery for is to find=20=

>>>>>>>> the RS, so requiring the client to know the RS URI before getting=20=

>>>>>>>> the AS config seems backwards to me.
>>>>>>> How can you make an assumption on order? You seem to be conflating=20=

>>>>>>> authentication with authorization by assuming the identity drives=20=

>>>>>>> what the resource is.=20
>>>>>>>=20
>>>>>>> There are lots of applications that require user rights but are not=20=

>>>>>>> identify centric. For example a document service.=20
>>>>>>>>=20
>>>>>>>> Unless the client tells the AS where it intends to use the token we=
=20
>>>>>>>> will be leaving a security hole because the bearer tokens will have=
=20
>>>>>>>> too loose an audience if they have one at all.
>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>=20
>>>>>>>> True you are telling the AS (Webfinger service) what the RS is but=20=

>>>>>>>> that is not at a place that is useful in the token production proce=
ss.
>>>>>>>=20
>>>>>>> This has nothing to do with token production.=20
>>>>>>>=20
>>>>>>> What we want to ensure is whether an honest client is correctly=20
>>>>>>> configured and has not been mislead - eg by a phishing page.=20
>>>>>>>>=20
>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99t know a=
ll the=20
>>>>>>>> possible RS.   That is not something that a out of band check can=20=

>>>>>>>> address.
>>>>>>>=20
>>>>>>> May be. Lets identify them.=20
>>>>>>>=20
>>>>>>>> There are also cases where a token might be good at multiple RS=20
>>>>>>>> endpoints intentionally.
>>>>>>>=20
>>>>>>>>  In your solution the client would need to make a discovery request=
=20
>>>>>>>> for each endpoint.
>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool of AS=
=20
>>>>>>> servers assigned to each instance?=20
>>>>>>>> Those requests lack the context of who the client and resource owne=
r=20
>>>>>>>> are.  I think that will be a problem in some                       =
    use cases.
>>>>>>>=20
>>>>>>> Not sure I agree. This is about discovering a valid set of endpoints=
.=20
>>>>>>> For mitm, we mainly want to check the hostname is correct. If a=20
>>>>>>> client chooses evil.com                          t=
he cert can be valid and=20
>>>>>>> TLS will pass. How does it otherwise know it is supposed to talk to=20=

>>>>>>> res.example.com ?=20
>>>>>>>>=20
>>>>>>>> If this is added to the token endpoint it would be checked when cod=
e=20
>>>>>>>> or refresh are exchanged, not every time the token is used.
>>>>>>> Your proposal requires rhe client to check. I am not clear how the A=
S=20
>>>>>>> can know the exact uri. It is far easier to validate than to lookup=20=

>>>>>>> since as you say the client may be authorized to use multiple ASs.=20=

>>>>>>>> With a out of band check the client would never know if a RS was=20=

>>>>>>>> removed/revoked.
>>>>>>>=20
>>>>>>> Not sure that is in scope.=20
>>>>>>>=20
>>>>>>> None of the current proposals address this issue.=20
>>>>>>>>=20
>>>>>>>> I don=E2=80=99t see checking when refreshing a token as something t=
hat is a=20
>>>>>>>> huge burden.
>>>>>>>=20
>>>>>>> Still its a lot more than once.=20
>>>>>>>=20
>>>>>>> Why don't you draft another alternative?=20
>>>>>>>>=20
>>>>>>>> If the server wants to do the check on it=E2=80=99s side then we co=
uld=20
>>>>>>>> require the client to send the RS URI in the token request. that wa=
y=20
>>>>>>>> you really know the client is not going to get a token for the wron=
g=20
>>>>>>>> RS endpoint.=20
>>>>>>>> If you check out of band in discovery you really have no idea if th=
e=20
>>>>>>>> client is checking.
>>>>>>>=20
>>>>>>> In the new webfinger draft, the client isn't checking. The service=20=

>>>>>>> provider simply does not disclose oauth information to misconfigured=
=20
>>>>>>> clients.=20
>>>>>>>>=20
>>>>>>>> John B.=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >>>>>>>> > wrote:=20
>>>>>>>>>=20
>>>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take eac=
h in turn:=20
>>>>>>>>>=20
>>>>>>>>> Mike,=20
>>>>>>>>>=20
>>>>>>>>> Regarding your suggested amendments=20
>>>>>>>>>=20
>>>>>>>>> Item 1: Returning the config URL would create two problems. One,it=
=20
>>>>>>>>> makes bound discovery a two-step process - that adds complexity.=20=

>>>>>>>>>  It seems far simpler to mandate TLS (which I think it already doe=
s=20
>>>>>>>>> in the security considerations).=20
>>>>>>>>>=20
>>>>>>>>> The two-step process allows the current discovery process to=20
>>>>>>>>> continue. I disagree with this. This is why                       =
      I put forward an=20
>>>>>>>>> =E2=80=9Calternate" draft that is almost the same but simply adds t=
he check=20
>>>>>>>>> before returning the configuration data.  I                       =
      worry that  developers=20
>>>>>>>>> would have no incentive to do the two-step approach. They would=20=

>>>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at risk of ex=
posing=20
>>>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>>>=20
>>>>>>>>> Regarding existing implementations. Most of those implementations=20=

>>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use of=20=

>>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well define=
d=20
>>>>>>>>> and the likelihood of a client mis-informed about the resource=20
>>>>>>>>> endpoint is not there.  IMO This does not                         =
    apply to the broader=20
>>>>>>>>> OAuth community.=20
>>>>>>>>>=20
>>>>>>>>> Item 2:  It may be appropriate to have a separate configuration=20=

>>>>>>>>> registry specification, but I think we should hold off until we=20=

>>>>>>>>> have a complete solution and then make the decision what drafts=20=

>>>>>>>>> should exist and how many pieces.  A big concern is the perceived=20=

>>>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>>>=20
>>>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>>>=20
>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a security=
 threat=20
>>>>>>>>> by having a discovery specification to prevent clients being=20
>>>>>>>>> mis-lead about endpoints (of which resource service is one) in an=20=

>>>>>>>>> oauth protected exchange.  Maybe what you mean is we should not us=
e=20
>>>>>>>>> .well-known of any kind and we should just create a =E2=80=9C/Conf=
ig=E2=80=9D=20
>>>>>>>>> endpoint to OAuth?=20
>>>>>>>>>=20
>>>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>>>> You propose that instead the resource endpoint check should be in=20=

>>>>>>>>> the oauth protocol itself.  The difference is that validation is=20=

>>>>>>>>> transferred back to the client to get it right. As well, without=20=

>>>>>>>>> the client informing the AS, I can=E2=80=99t see a way for the AS t=
o know=20
>>>>>>>>> what endpoint the client is using.  The webfinger approach does=20=

>>>>>>>>> this once and only requires that the host name be checked in many=20=

>>>>>>>>> cases.=20
>>>>>>>>>=20
>>>>>>>>> As a principle, the members have discussed many times that the AS=20=

>>>>>>>>> service should do validation when possible =E2=80=94 this was part=
icularly=20
>>>>>>>>> true at the Germany meeting when this came up. This is why I prefe=
r=20
>>>>>>>>> the client tell the service provider what it intends to do and the=
=20
>>>>>>>>> service provider can fail that request immediately if necessary. W=
e=20
>>>>>>>>> don=E2=80=99t have to depend on the developer getting the spec cor=
rect to=20
>>>>>>>>> fail the correct way.=20
>>>>>>>>>=20
>>>>>>>>> I worry that adding more parameters to the authz and token protoco=
l=20
>>>>>>>>> flows increases complexity and attack surface. It also means per=20=

>>>>>>>>> authorization validation has to take place                        =
     vs. a one-time=20
>>>>>>>>> validation at config time.  Placing it in the configuration lookup=
=20
>>>>>>>>> phase (whether via web finger or just a special OAuth endpoint)=20=

>>>>>>>>> seems more appropriate and far less complex - as the request itsel=
f=20
>>>>>>>>> is simple and has only one parameter. Here we are not considered=20=

>>>>>>>>> about legitimacy of the client. we=E2=80=99re just concerned with t=
he issue=20
>>>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>>>=20
>>>>>>>>> That said, it may be that when we consider all the use cases, some=
=20
>>>>>>>>> combination of AS protocol and discovery may be both needed. I=E2=80=
=99m=20
>>>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>>>> oauth-discovery spec seems to put future generic clients at risk=20=

>>>>>>>>> and that is my primary concern.=20
>>>>>>>>>=20
>>>>>>>>> Best Regards,=20
>>>>>>>>>=20
>>>>>>>>> Phil=20
>>>>>>>>>=20
>>>>>>>>> @independentid=20
>>>>>>>>> www.independentid.com =20
>>>>>>>>> phil.hunt@oracle.com =20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>>> =
>=20
>>>>>>>>>> wrote:=20
>>>>>>>>>>=20
>>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete example of=
=20
>>>>>>>>>> a way that protected resource discovery                          =
     could be added to=20
>>>>>>>>>> authorization server metadata discovery, and as such, should=20
>>>>>>>>>> provide useful input for working group discussions on this topic.=
=20
>>>>>>>>>> It=E2=80=99s always great when someone takes the time to write an=
 actual=20
>>>>>>>>>> draft that can be examined and implemented, and I appreciate you=20=

>>>>>>>>>> doing that.=20
>>>>>>>>>> The content of your draft points out that                        =
       there appears to be=20
>>>>>>>>>> complete agreement on what the authorization server metadata=20
>>>>>>>>>> format should be, which is great!  I=E2=80=99ll note that Section=
 3 of=20
>>>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Se=
rver=20
>>>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo=20
>>>>>>>>>> applying a correction suggested by the working group.  To me this=
=20
>>>>>>>>>> suggests that the authorization server metadata definitions in=20=

>>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative=20
>>>>>>>>>> content of the draft) are clearly ready for standardization, sinc=
e=20
>>>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>>>> Reading your draft, the problem I have with it is that you are=20=

>>>>>>>>>> returning the AS metadata only as a WebFinger response, rather=20=

>>>>>>>>>> than as an https-protected resource published by the authorizatio=
n=20
>>>>>>>>>> server.  The choice to only return this via WebFinger makes your=20=

>>>>>>>>>> draft incompatible with most deployed implementations of OAuth=20=

>>>>>>>>>> metadata, including the 22 implementations using it listed=20
>>>>>>>>>> athttp://openid.net/certification/(see the =E2=80=9COP Config=E2=80=
=9D column in=20
>>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=
=80=9CADAL=E2=80=9D=20
>>>>>>>>>> library, which uses the metadata path for client configuration.=20=

>>>>>>>>>> Without having ASs provide the metadata as an https-protected=20
>>>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use it for c=
lient=20
>>>>>>>>>> configuration as the currently do.=20
>>>>>>>>>> Therefore, I would request that you make these minor revisions to=
=20
>>>>>>>>>> your draft and republish, so as to provide a unified way forward=20=

>>>>>>>>>> that is compatible with all known existing OAuth Discovery=20
>>>>>>>>>> deployments:=20
>>>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server WebFinger D=
iscovery=E2=80=9D=20
>>>>>>>>>> to have the WebFinger request return the issuer identifier for th=
e=20
>>>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, rather =
                              than returning the=20
>>>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D valu=
e.=20
>>>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in your=20=

>>>>>>>>>> Section 3.=20
>>>>>>>>>> That would have the advantage of paring your draft down to only=20=

>>>>>>>>>> the new things that it proposes, enabling them to be more clearly=
=20
>>>>>>>>>> understood and evaluated on their own merits.  I look forward to=20=

>>>>>>>>>> the discussions of ways of performing additional kinds of OAuth=20=

>>>>>>>>>> discovery, and consider your draft a valuable input to those=20
>>>>>>>>>> discussions.=20
>>>>>>>>>>                                                           Best wi=
shes,=20
>>>>>>>>>>                                                           -- Mike=
=20
>>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*John Br=
adley=20
>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>>>> *To:*Phil Hunt >=20
>>>>>>>>>> *Cc:*oauth >=20
>>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>> As I have told Phil off list.=20
>>>>>>>>>> Discovery is the wrong place to try and provide security against=20=

>>>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>>>> This requires the client to know what the RS URI is before=20
>>>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>>>> The proposal Mike and I have been working on requires the client=20=

>>>>>>>>>> to have a notion of what API it is looking                       =
        for and retrieve the=20
>>>>>>>>>> .well-known file for that API from the issuer.   That allows a=20=

>>>>>>>>>> protocol like Connect to register its own config file that can=20=

>>>>>>>>>> point to the RS.=20
>>>>>>>>>> If the API specific well known is not available the client can tr=
y=20
>>>>>>>>>> the default oauth-server one.=20
>>>>>>>>>> That then allows us to deal with restricting where AT are=20
>>>>>>>>>> presented as part of the protocol rather then dragging discovery=20=

>>>>>>>>>> in as a requirement.=20
>>>>>>>>>> In my opinion the resource the token is targeted to should be=20
>>>>>>>>>> separated from the scope and returned as part of the meta-data=20=

>>>>>>>>>> about the AT along with scopes granted and expiry time.   We=20
>>>>>>>>>> should also have a input parameter for resources so that a client=
=20
>>>>>>>>>> can restrict tokens issued to a subset of the ones granted by the=
=20
>>>>>>>>>> refresh token.   It would then also be possible to ask a AS for a=
=20
>>>>>>>>>> token for a unregistered RS and have the AS produce a JWT access=20=

>>>>>>>>>> token with the resource as an audience if policy allows.=20
>>>>>>>>>> That however was supposed to be dealt with as part of the mixed u=
p=20
>>>>>>>>>> client set of mitigations.=20
>>>>>>>>>> In that the goal was to mitigate the attacks by returning=20
>>>>>>>>>> meta-data about the tokens, and not to require discovery.=20
>>>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=
=80=9D for the code, and I=20
>>>>>>>>>> intend to discuss at the F2F returning resource for AT as well.=20=

>>>>>>>>>> Those mitigate the attack.=20
>>>>>>>>>> I will continue to resist mixing up discovery of configuration=20=

>>>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>>>> We return meta-data about the tokens now, because AT are opaque t=
o=20
>>>>>>>>>> the client, we neglected to include some                         =
      of the information for=20
>>>>>>>>>> the client needs to be secure.   We just need to add that in to=20=

>>>>>>>>>> the existing flows.=20
>>>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS               =
                to implement as an add=20
>>>>>>>>>> on, it puts more of a burden on the client needing to potentially=
=20
>>>>>>>>>> change how it stores the relationships between AS and RS to=20
>>>>>>>>>> prevent compromise, I think the solution                         =
      should be biased towards=20
>>>>>>>>>> simplicity on the client side.=20
>>>>>>>>>> If we return the resources as part of the existing meta data the=20=

>>>>>>>>>> client checks that against the resource it intends to send the=20=

>>>>>>>>>> token to and if it is not in the list then it can=E2=80=99t send t=
he=20
>>>>>>>>>> token.  Simple check every time it gets a                        =
       new AT, no optionality.=20
>>>>>>>>>> I am not saying anything new Nat has been advocating basically=20=

>>>>>>>>>> this for some time, and dis submit a draft.   I prefer to return=20=

>>>>>>>>>> the info in the existing format rather than as link headers,  but=
=20
>>>>>>>>>> that is the largest difference between what Nat and I are saying=20=

>>>>>>>>>> with respect to resource.=20
>>>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20
>>>>>>>>>> I guess we will need to have a long conversation in BA.=20
>>>>>>>>>> Regards=20
>>>>>>>>>> John B.=20
>>>>>>>>>>=20
>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt >>>>>>>>>     > wrote:=20
>>>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same=20=

>>>>>>>>>>     registry for OAuth Config Metadata as                        =
       the authors believe that=20
>>>>>>>>>>     both solutions are not required, or depending on WG discussio=
n=20
>>>>>>>>>>     they will be merged. The intent is to provide a simple=20
>>>>>>>>>>     complete draft for consideration.=20
>>>>>>>>>>     How it works...=20
>>>>>>>>>>     Given that a client has previously discovered an OAuth=20
>>>>>>>>>>     protected resource, the bound configuration method allows a=20=

>>>>>>>>>>     client to return the configuration for an oauth authorization=
=20
>>>>>>>>>>     server that can issue tokens for the resource URI specified b=
y=20
>>>>>>>>>>     the client.  The AS is not required to be in the same domain.=
=20
>>>>>>>>>>      The AS is however required to know if it can issue tokens fo=
r=20
>>>>>>>>>>     a resource service (which presumes some agreement exists on=20=

>>>>>>>>>>     tokens etc).=20
>>>>>>>>>>     The draft does not require that the resource exist (e.g. for=20=

>>>>>>>>>>     unconfigured or new user based resources). It only requires=20=

>>>>>>>>>>     that the AS service provider agrees it can issue tokens.=20
>>>>>>>>>>     =46rom a security perspective, returning                     =
          the OAuth service=20
>>>>>>>>>>     configuration for a specified resource URI serves to confirm=20=

>>>>>>>>>>     the client is in possession of a valid resource URI ensuring=20=

>>>>>>>>>>     the client has received a valid set of endpoints for the=20
>>>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>>>     I propose that the WG consider the alternate draft carefully=20=

>>>>>>>>>>     as well as other submissions and evaluate the broader=20
>>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth Discov=
ery.=20
>>>>>>>>>>     Thanks!=20
>>>>>>>>>>     Phil=20
>>>>>>>>>>     @independentid=20
>>>>>>>>>>     www.independentid.com =20
>>>>>>>>>>     phil.hunt@oracle.com =20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Begin forwarded message:=20
>>>>>>>>>>         *From:*internet-drafts@ietf.org=20
>>>>>>>>>>         =20
>>>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>>>         >, "Anthony Nadalin"=20
>>>>>>>>>>         >,=20=

>>>>>>>>>>         "Tony Nadalin" >>>>>>>>>         >                          =
     =20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         A new version of I-D, draft-hunt-oauth-bound-config-00.tx=
t=20
>>>>>>>>>>         has been successfully submitted by Phil Hunt and posted t=
o the=20
>>>>>>>>>>         IETF repository.=20
>>>>>>>>>>=20
>>>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>>>         Revision:00=20
>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>>>         Group:Individual Submission=20
>>>>>>>>>>         Pages:22=20
>>>>>>>>>>         URL:=20
>>>>>>>>>>         https://www.ietf.org/internet-drafts/draft-hunt-oauth-bou=
nd-config-00.txt
>>>>>>>>>>         Status:=20
>>>>>>>>>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-c=
onfig/=20
>>>>>>>>>>         Htmlized:=20
>>>>>>>>>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config=
-00=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Abstract:=20
>>>>>>>>>>           This specification defines a mechanism for the client o=
f=20
>>>>>>>>>>         an OAuth 2.0=20
>>>>>>>>>>           protected resource service to obtain the configuration=20=

>>>>>>>>>>         details of an=20
>>>>>>>>>>           OAuth 2.0 authorization server that is capable of=20
>>>>>>>>>>         authorizing access=20
>>>>>>>>>>           to a specific resource service.  The information=20
>>>>>>>>>>         includes the OAuth=20
>>>>>>>>>>           2.0 component endpoint location URIs and as well as=20
>>>>>>>>>>         authorization=20
>>>>>>>>>>           server capabilities.=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Please note that it may take a couple of minutes from the=
=20
>>>>>>>>>>         time of submission=20
>>>>>>>>>>         until the htmlized version and diff are available=20
>>>>>>>>>>         attools.ietf.org .=20
>>>>>>>>>>=20
>>>>>>>>>>         The IETF Secretariat=20
>>>>>>>>>>=20
>>>>>>>>>>     _______________________________________________=20
>>>>>>>>>>     OAuth mailing list=20
>>>>>>>>>>     OAuth@ietf.org =20
>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>> _______________________________________________=20
>>>>>> OAuth mailing list=20
>>>>>> OAuth@ietf.org =20
>>>>>> https://www.ietf.org/mailman/listinfo/oauth                      =20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________=20
>>>>> OAuth mailing list=20
>>>>> OAuth@ietf.org=20
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
> Office: +1-703-265-2544           Photos: http://georgefletcher.photograph=
y

--Apple-Mail-01EAC0E5-9C90-41B0-8D21-E5340D0BF4F4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Thanks George

    I think we have to disc=
uss cases where mitigstion is not needed such as oidc. 

    My concern is t=
o make the mitigation choice the AS's and not the client. 

    Phil<=
/div>

    On Mar 15, 2016, at 09:01, George Fletcher <gffletch@aol.com> wrote:

    
 =20
    
 =20
 =20
    I understand the benefit
      of having the client specify where it wants to present the token.
      However, in general, the client knows which kind of resource it's
      going to connect to (even if it doesn't know the exact endpoint).
      For example, if the client speaks PortableContacts, then it can
      potentially discover any PortableContact RS and attempt to get
      authorization to access the endpoints, but the client can't
      connect to the mail RS because it's not coded to work with those
      endpoints.
    
      
    
      Therefore, the client has an understanding of the protocol of the
      RS and can possibly discover related endpoints (what webfinger was
      really designed for) but it can't support some random new
      protocol. As I wrote in my response to John Bradley, I believe
      audience binding should use an abstract identifier not an API
      endpoint.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/15/16 11:40 AM, Phil Hunt wrote:
    =

    
    
    
    
      
      Regarding 2.
      

    
      
    
      
    The bound config spec makes no such requirement of
        knowing the and its path structure.  
    
      

    
      
    
      
    If you feel that you have other security measures
        and that clients will always have the proper AS, then you can
        wildcard the whole resource parameter.  It still might be
        advisable to at least check that your clients are using a URL of
        the form https://*.aol.com/* or https://*.partner.com/*.
    
      

    
      
    
      
    The benefit is that at least you know the client is
        intending to wield the token somewhere in your domain or your
        partner=E2=80=99s domain. as opposed to something like news.aol=
.myevildomain.com.
    
      

    
      
    
      
    The difference here is that security remains the
        responsibility of the service provider in all cases.  The check=

        is up to the service provider rather than the client. This means
        that we don=E2=80=99t have to rely on trusting that the client devel=
oper
        bothered to check the configuration (as in other proposals that
        modify OAuth protocol itself) =E2=80=94 we know well they won=E2=80=99=
t because
        they won=E2=80=99t have to. The server side validation is trivial. &=
nbsp;I=E2=80=99m
        not sure how much easier this can be.  
    
      

    
      
    
      
    
        
    
          
    
            
    
              
    
                  
    
                    
    
                      
    
                        
    Phil
    
                        

    
                        
    
                        
    @independentid
    
                        
    www.independentid.com
    
                      
    
                    
    
                  
    
                    phil.hunt@oracle.com=

    
              

    
              
    
            
    
            
    
          
    
          
    
          
    
        
    
        
    
        
    
          
    
            
    On Mar 15, 2016, at 8:09 AM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
              
              
     I worry
                  about two directions I see in this thread...
    
                  
    
                  1. Client's accessing resources dynamically so that
                  discovery is required to know the correct AS, etc.
                  This is pretty much the classic use case for UMA and
                  I'd rather not re-invent the wheel.
    
                  
    
                  2. Creating a tight coupling between RS and AS such
                  that RS endpoint changes must be continually
                  communicated to the AS. If an RS supports multiple
                  AS's then the RS has to deal with "guaranteed"
                  delivery. The AS needs an endpoint to receive such
                  communications. If not dynamic via APIs, then
                  deployment of the new RS is bound by the associated
                  AS's getting and deploying the new endpoints. Can both
                  endpoints of the RS be supported within the AS for
                  some period of time, etc. This is an operation
                  nightmare and almost assuredly going to go wrong in
                  production.
    
                  
    
                  Maybe an OAuth2 "audience binding" spec is what's
                  needed for those deployments that require this. I
                  believe that is what John Bradley is suggesting.
    
                  
    
                  Thanks,
    
                  George
    
                
    
                
    On 3/14/16 7:29 PM, Hans
                  Zandbelt wrote:
    
                
    
                
    +1, I've found the very same in
                  OAuth deployments that I was involved in; the hard
                  part is to give names and descriptions to these
                  concepts so that they cover all use cases and can be
                  applied unambiguously 
    
                  
    
                  Hans. 
    
                  
    
                  On 3/14/16 10:44 PM, Justin Richer wrote: 
    
                  
    I agree that this is
                    valuable, and not just for PoP. In all honesty, 
    
                    it=E2=80=99s not even really required for PoP to functio=
n in
                    many cases =E2=80=94 it=E2=80=99s 
    
                    just an optimization for one particular kind of key
                    distribution 
    
                    mechanism in that case. 
    
                    
    
                    In the years of deployment experience with OAuth 2,
                    I think we=E2=80=99ve really 
    
                    got three different kinds of things that currently
                    get folded into 
    
                    =E2=80=9Cscope=E2=80=9D that we might want to try separa=
ting out
                    better: 
    
                    
    
                    
    
                      - What things do I want to access? (photos,
                    profile) 
    
                      - What actions do I want to take on these things?=

                    (read, write, delete) 
    
                      - How long do I want these tokens to work? 
    
                    (offline_access/refresh_token, one time use, next
                    hour, etc) 
    
                    
    
                    
    
                    I think the first one is close to the
                    audience/resource parameters that 
    
                    have been bandied about a few times, including in
                    the current token 
    
                    exchange document. We should be consistent across
                    drafts in that regard. 
    
                    The second is more traditional scope-ish. The third
                    has been patched in 
    
                    with things like =E2=80=9Coffline_access=E2=80=9D in cer=
tain APIs. 
    
                    
    
                    Just another vector to think about if we=E2=80=99re goin=
g to
                    be adding things 
    
                    like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=
=9D or both to the token
                    requests. 
    
                    
    
                      =E2=80=94 Justin 
    
                    
    
                    
    
                    
    On Mar 14, 2016, at=

                      6:26 PM, John Bradley <ve7jtb@v=
e7jtb.com
                      
    
                      <mailto:ve7jtb@ve7jtb.com>=
>
                      wrote: 
    
                      
    
                      Yes I will work on another proposal for allowing
                      clients to specify 
    
                      what resource they want a token for and providing
                      the meta-data to the 
    
                      client about the resources that a token is valid
                      for. 
    
                      
    
                      We have part of it in the POP key distribution
                      spec and talked about 
    
                      separating it, as it is used more places than just
                      for assigning keys. 
    
                      I know some AS use different token formats for
                      different RS so are 
    
                      all-ready needing to pass the resource in the
                      request to avoid making 
    
                      a mess of scopes. 
    
                      
    
                      John B. 
    
                      
    
                      
    
                      
    
                      
    
                      
    
                      
    On Mar 14, 2016,
                        at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com
                        
    
                        <mailto:phil.hunt@oracle.com=
>>
                        wrote: 
    
                        
    
                        Inline 
    
                        
    
                        Phil 
    
                        
    
                        On Mar 14, 2016, at 14:13, John Bradley <ve7jtb@ve7jtb.com
                        
    
                        <mailto:ve7jtb@ve7jtb.com>>
                        wrote: 
    
                        
    
                        
    We had two
                          mandates.  One was to provide a spec for AS
                          metadata. 
    
                          The other was to mitigate the client mixup
                          attack.  The request was 
    
                          to do the latter without requiring the former
                          for clients that don=E2=80=99t 
    
                          otherwise need discovery. 
    
                        
    
                        There is no mandate for any of this. See 
    
                            http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oaut=
h-2016-01-22.txt
                        
    
                        
     
    
                          Returning the issuer and client_id from the
                          authorization endpoint 
    
                          and the client checking them can be done by
                          the client without 
    
                          discovery. 
    
                        
    
                        
    
                        How does this address the issue of whether the
                        client is talking to 
    
                        the wrong endpoint? 
    
                        
     
    
                          Any client that has the resource and issuer
                          hard coded probably 
    
                          doesn=E2=80=99t need discovery. 
    
                        
    
                        We agree 
    
                        
    
                        
    
                        
    One of the
                          things that a client will need discovery for
                          is to find 
    
                          the RS, so requiring the client to know the RS
                          URI before getting 
    
                          the AS config seems backwards to me. 
    
                        
    
                        How can you make an assumption on order? You
                        seem to be conflating 
    
                        authentication with authorization by assuming
                        the identity drives 
    
                        what the resource is. 
    
                        
    
                        There are lots of applications that require user
                        rights but are not 
    
                        identify centric. For example a document
                        service. 
    
                        
     
    
                          Unless the client tells the AS where it
                          intends to use the token we 
    
                          will be leaving a security hole because the
                          bearer tokens will have 
    
                          too loose an audience if they have one at all.
                          
    
                        
    
                        This is the biggest risk we have IMHO. 
    
                        
     
    
                          True you are telling the AS (Webfinger
                          service) what the RS is but 
    
                          that is not at a place that is useful in the
                          token production process. 
    
                        
    
                        
    
                        This has nothing to do with token production. 
    
                        
    
                        What we want to ensure is whether an honest
                        client is correctly 
    
                        configured and has not been mislead - eg by a
                        phishing page. 
    
                        
     
    
                          I also think there are use cases where the AS
                          doesn=E2=80=99t know all the 
    
                          possible RS.   That is not something tha=
t a
                          out of band check can 
    
                          address. 
    
                        
    
                        
    
                        May be. Lets identify them. 
    
                        
    
                        
    There are also
                          cases where a token might be good at multiple
                          RS 
    
                          endpoints intentionally. 
    
                        
    
                        
    
                        
     In your
                          solution the client would need to make a
                          discovery request 
    
                          for each endpoint. 
    
                        
    
                        Sure. Otherwise how would it know if there is
                        one AS or a pool of AS 
    
                        servers assigned to each instance? 
    
                        
    Those requests
                          lack the context of who the client and
                          resource owner 
    
                          are.  I think that will be a problem in some
                          use cases. 
    
                        
    
                        
    
                        Not sure I agree. This is about discovering a
                        valid set of endpoints. 
    
                        For mitm, we mainly want to check the hostname
                        is correct. If a 
    
                        client chooses evil.com <http://evil.com/>
                        the cert can be valid and 
    
                        TLS will pass. How does it otherwise know it is
                        supposed to talk to 
    
                        res.example.com
                        <http://res.example.com/>=
?
                        
    
                        
     
    
                          If this is added to the token endpoint it
                          would be checked when code 
    
                          or refresh are exchanged, not every time the
                          token is used. 
    
                        
    
                        Your proposal requires rhe client to check. I am
                        not clear how the AS 
    
                        can know the exact uri. It is far easier to
                        validate than to lookup 
    
                        since as you say the client may be authorized to
                        use multiple ASs. 
    
                        
    With a out of
                          band check the client would never know if a RS
                          was 
    
                          removed/revoked. 
    
                        
    
                        
    
                        Not sure that is in scope. 
    
                        
    
                        None of the current proposals address this
                        issue. 
    
                        
     
    
                          I don=E2=80=99t see checking when refreshing a tok=
en
                          as something that is a 
    
                          huge burden. 
    
                        
    
                        
    
                        Still its a lot more than once. 
    
                        
    
                        Why don't you draft another alternative? 
    
                        
     
    
                          If the server wants to do the check on it=E2=80=99=
s
                          side then we could 
    
                          require the client to send the RS URI in the
                          token request. that way 
    
                          you really know the client is not going to get
                          a token for the wrong 
    
                          RS endpoint. 
    
                          If you check out of band in discovery you
                          really have no idea if the 
    
                          client is checking. 
    
                        
    
                        
    
                        In the new webfinger draft, the client isn't
                        checking. The service 
    
                        provider simply does not disclose oauth
                        information to misconfigured 
    
                        clients. 
    
                        
     
    
                          John B. 
    
                          
    
                          
    
                          
    On Mar 14,
                            2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com
                            
    
                            <mailto:phil.hunt@oracle=
.com>>
                            wrote: 
    
                            
    
                            Thanks to Mike and John for their feedback. =
;
                            I=E2=80=99ll take each in turn: 
    
                            
    
                            Mike, 
    
                            
    
                            Regarding your suggested amendments 
    
                            
    
                            Item 1: Returning the config URL would
                            create two problems. One,it 
    
                            makes bound discovery a two-step process -
                            that adds complexity. 
    
                             It seems far simpler to mandate TLS (which=

                            I think it already does 
    
                            in the security considerations). 
    =

                            
    
                            The two-step process allows the current
                            discovery process to 
    
                            continue. I disagree with this. This is why
                            I put forward an 
    
                            =E2=80=9Calternate" draft that is almost the sam=
e
                            but simply adds the check 
    
                            before returning the configuration data.  I=

                            worry that  developers 
    
                            would have no incentive to do the two-step
                            approach. They would 
    
                            just start at step 2 which in turn puts AS=E2=80=
=99s
                            at risk of exposing 
    
                            tokens because it works. This makes OAuth
                            promiscuous. 
    
                            
    
                            Regarding existing implementations. Most of
                            those implementations 
    
                            are for OIDC.  I think it makes sense for
                            OIDF to continue use of 
    
                            OIDC's discovery spec because the UserInfo
                            endpoint is well defined 
    
                            and the likelihood of a client mis-informed
                            about the resource 
    
                            endpoint is not there.  IMO This does not
                            apply to the broader 
    
                            OAuth community. 
    
                            
    
                            Item 2:  It may be appropriate to have a
                            separate configuration 
    
                            registry specification, but I think we
                            should hold off until we 
    
                            have a complete solution and then make the
                            decision what drafts 
    
                            should exist and how many pieces.  A big
                            concern is the perceived 
    
                            complexity of multiple solutions and
                            multiple drafts. 
    
                            
    
                            As to John Bradley=E2=80=99s comments: 
    
                            
    
                            Re: Discovery is the wrong place to mitigate
                            threats. 
    
                            I=E2=80=99m confused by this.  Our mandate w=
as to
                            solve a security threat 
    
                            by having a discovery specification to
                            prevent clients being 
    
                            mis-lead about endpoints (of which resource
                            service is one) in an 
    
                            oauth protected exchange.  Maybe what you
                            mean is we should not use 
    
                            .well-known of any kind and we should just
                            create a =E2=80=9C/Config=E2=80=9D 
    
                            endpoint to OAuth? 
    
                            
    
                            Re: Your proposal for MITM mitigation 
    
                            You propose that instead the resource
                            endpoint check should be in 
    
                            the oauth protocol itself.  The difference
                            is that validation is 
    
                            transferred back to the client to get it
                            right. As well, without 
    
                            the client informing the AS, I can=E2=80=99t see=
 a
                            way for the AS to know 
    
                            what endpoint the client is using.  The
                            webfinger approach does 
    
                            this once and only requires that the host
                            name be checked in many 
    
                            cases. 
    
                            
    
                            As a principle, the members have discussed
                            many times that the AS 
    
                            service should do validation when possible =E2=80=
=94
                            this was particularly 
    
                            true at the Germany meeting when this came
                            up. This is why I prefer 
    
                            the client tell the service provider what it
                            intends to do and the 
    
                            service provider can fail that request
                            immediately if necessary. We 
    
                            don=E2=80=99t have to depend on the developer
                            getting the spec correct to 
    
                            fail the correct way. 
    
                            
    
                            I worry that adding more parameters to the
                            authz and token protocol 
    
                            flows increases complexity and attack
                            surface. It also means per 
    
                            authorization validation has to take place
                            vs. a one-time 
    
                            validation at config time.  Placing it in
                            the configuration lookup 
    
                            phase (whether via web finger or just a
                            special OAuth endpoint) 
    
                            seems more appropriate and far less complex
                            - as the request itself 
    
                            is simple and has only one parameter. Here
                            we are not considered 
    
                            about legitimacy of the client. we=E2=80=99re ju=
st
                            concerned with the issue 
    
                            "has the client been correctly informed?=E2=80=9D=
 
    
                            
    
                            That said, it may be that when we consider
                            all the use cases, some 
    
                            combination of AS protocol and discovery may
                            be both needed. I=E2=80=99m 
    
                            not ready to make conclusions about this. 
                            The current 
    
                            oauth-discovery spec seems to put future
                            generic clients at risk 
    
                            and that is my primary concern. 
    
                            
    
                            Best Regards, 
    
                            
    
                            Phil 
    
                            
    
                            @independentid 
    
                            www.independentid.com<=
/a>
                            <http://www.independen=
tid.com/>
                            
    
                            phil.hunt@oracle.com=

                            <mailto:phil.hunt@oracle=
.com>
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    On Mar 13,
                              2016, at 10:28 PM, Mike Jones 
    
                              <Michael.Jon=
es@microsoft.com
                              <mailto:Michael=
.Jones@microsoft.com>>

                              
    
                              wrote: 
    
                              
    
                              Thanks for posting this, Phil.  It
                              provides a concrete example of 
    =

                              a way that protected resource discovery
                              could be added to 
    
                              authorization server metadata discovery,
                              and as such, should 
    
                              provide useful input for working group
                              discussions on this topic. 
    
                              It=E2=80=99s always great when someone takes t=
he
                              time to write an actual 
    
                              draft that can be examined and
                              implemented, and I appreciate you 
    
                              doing that. 
    
                              The content of your draft points out that
                              there appears to be 
    
                              complete agreement on what the
                              authorization server metadata 
    
                              format should be, which is great!  I=E2=80=
=99ll
                              note that Section 3 of 
    
                              draft-hunt-oauth-bound-config-00 titled
                              =E2=80=9CAuthorization Server 
    
                              Metadata=E2=80=9D is an exact copy of Section 2=
 of
                              
    
                              draft-ietf-oauth-discovery-01 (with the
                              same title), modulo 
    
                              applying a correction suggested by the
                              working group.  To me this 
    
                              suggests that the authorization server
                              metadata definitions in 
    
                              draft-ietf-oauth-discovery (which is now
                              the whole normative 
    
                              content of the draft) are clearly ready
                              for standardization, since 
    
                              even your alternative proposal includes
                              them verbatim. 
    
                              Reading your draft, the problem I have
                              with it is that you are 
    
                              returning the AS metadata only as a
                              WebFinger response, rather 
    
                              than as an https-protected resource
                              published by the authorization 
    =

                              server.  The choice to only return this
                              via WebFinger makes your 
    
                              draft incompatible with most deployed
                              implementations of OAuth 
    
                              metadata, including the 22 implementations
                              using it listed 
    
                              athttp://openid.net/certification/(=
see
                              the =E2=80=9COP Config=E2=80=9D column in 
    
                              the table) andOAuth 2.0 libraries such as
                              Microsoft=E2=80=99s =E2=80=9CADAL=E2=80=9D 
                              library, which uses the metadata path for
                              client configuration. 
    
                              Without having ASs provide the metadata as
                              an https-protected 
    
                              resource, implementations such as ADAL
                              can=E2=80=99t use it for client 
    
                              configuration as the currently do. 
    
                              Therefore, I would request that you make
                              these minor revisions to 
    
                              your draft and republish, so as to provide
                              a unified way forward 
    
                              that is compatible with all known existing
                              OAuth Discovery 
    
                              deployments: 
    
                              1.Modify your section 2 =E2=80=9CAuthorization=

                              Server WebFinger Discovery=E2=80=9D 
    
                              to have the WebFinger request return the
                              issuer identifier for the 
    
                              AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=
=9D value, rather
                              than returning the 
    
                              metadata values by value as the
                              =E2=80=9Cproperties=E2=80=9D value. 
    
                              2.Reference the metadata definitions from
                              Section 2 of 
    
                              draft-ietf-oauth-discovery, rather than
                              duplicating them in your 
    
                              Section 3. 
    
                              That would have the advantage of paring
                              your draft down to only 
    
                              the new things that it proposes, enabling
                              them to be more clearly 
    
                              understood and evaluated on their own
                              merits.  I look forward to 
    
                              the discussions of ways of performing
                              additional kinds of OAuth 
    
                              discovery, and consider your draft a
                              valuable input to those 
    
                              discussions. 
    
                                     &nbs=
p;            &n=
bsp;            =
            &nbs=
p;           

                              Best wishes, 
    
                                     &nbs=
p;            &n=
bsp;            =
            &nbs=
p;           

                              -- Mike 
    
                              *From:*OAuth [mailto:oa=
uth-bounces@ietf.org]*On
                              Behalf Of*John Bradley 
    
                              *Sent:*Sunday, March 13, 2016 6:45 PM 
    
                              *To:*Phil Hunt <=
phil.hunt@oracle.com
                              <mailto:phil.hunt@orac=
le.com>>

                              
    
                              *Cc:*oauth <oauth@ietf.or=
g
                              <mailto:oauth@ietf.org>>

                              
    
                              *Subject:*Re: [OAUTH-WG] New Version
                              Notification for 
    
                              draft-hunt-oauth-bound-config-00.txt 
    
                              As I have told Phil off list. 
    
                              Discovery is the wrong place to try and
                              provide security against 
    
                              man in the middle attacks on the RS. 
    
                              This requires the client to know what the
                              RS URI is before 
    
                              retrieving the information on the AS
                              Configuration. 
    
                              The proposal Mike and I have been working
                              on requires the client 
    
                              to have a notion of what API it is looking
                              for and retrieve the 
    
                              .well-known file for that API from the
                              issuer.   That allows a 
    
                              protocol like Connect to register its own
                              config file that can 
    
                              point to the RS. 
    
                              If the API specific well known is not
                              available the client can try 
    
                              the default oauth-server one. 
    
                              That then allows us to deal with
                              restricting where AT are 
    
                              presented as part of the protocol rather
                              then dragging discovery 
    
                              in as a requirement. 
    
                              In my opinion the resource the token is
                              targeted to should be 
    
                              separated from the scope and returned as
                              part of the meta-data 
    
                              about the AT along with scopes granted and
                              expiry time.   We 
    
                              should also have a input parameter for
                              resources so that a client 
    
                              can restrict tokens issued to a subset of
                              the ones granted by the 
    
                              refresh token.   It would then also b=
e
                              possible to ask a AS for a 
    
                              token for a unregistered RS and have the
                              AS produce a JWT access 
    
                              token with the resource as an audience if
                              policy allows. 
    
                              That however was supposed to be dealt with
                              as part of the mixed up 
    
                              client set of mitigations. 
    
                              In that the goal was to mitigate the
                              attacks by returning 
    
                              meta-data about the tokens, and not to
                              require discovery. 
    
                              We intend to return =E2=80=9Ciss=E2=80=9D and =E2=
=80=9Ccleint_id=E2=80=9D
                              for the code, and I 
    
                              intend to discuss at the F2F returning
                              resource for AT as well. 
    
                              Those mitigate the attack. 
    
                              I will continue to resist mixing up
                              discovery of configuration 
    
                              meta-data with mitigation of the attacks.
                              
    
                              We return meta-data about the tokens now,
                              because AT are opaque to 
    
                              the client, we neglected to include some
                              of the information for 
    
                              the client needs to be secure.   We j=
ust
                              need to add that in to 
    
                              the existing flows. 
    
                              While Phil=E2=80=99s proposal is easier for th=
e AS
                              to implement as an add 
    
                              on, it puts more of a burden on the client
                              needing to potentially 
    
                              change how it stores the relationships
                              between AS and RS to 
    
                              prevent compromise, I think the solution
                              should be biased towards 
    
                              simplicity on the client side. 
    =

                              If we return the resources as part of the
                              existing meta data the 
    
                              client checks that against the resource it
                              intends to send the 
    
                              token to and if it is not in the list then
                              it can=E2=80=99t send the 
    
                              token.  Simple check every time it gets a=

                              new AT, no optionality. 
    
                              I am not saying anything new Nat has been
                              advocating basically 
    
                              this for some time, and dis submit a
                              draft.   I prefer to return 
    
                              the info in the existing format rather
                              than as link headers,  but 
    
                              that is the largest difference between
                              what Nat and I are saying 
    
                              with respect to resource. 
    
                              That is the core of my problem with Phil=E2=80=
=99s
                              draft. 
    
                              I guess we will need to have a long
                              conversation in BA. 
    
                              Regards 
    
                              John B. 
    
                              
    
                                  On Mar 13, 2016, at 8:12 PM=
, Phil Hunt
                              <    phil.hunt@oracle.c=
om
                              
    
                                  <ma=
ilto:phil.hunt@oracle.com>>
                              wrote: 
    
                                  This draft is a proposed al=
ternate
                              proposal for 
    
                                  draft-ietf-oauth-discovery.=
  As such,
                              it contains the same 
    
                                  registry for OAuth Config M=
etadata as
                              the authors believe that 
    
                                  both solutions are not requ=
ired, or
                              depending on WG discussion 
    
                                  they will be merged. The in=
tent is to
                              provide a simple 
    
                                  complete draft for consider=
ation. 
    
                                  How it works... 
    
                                  Given that a client has pre=
viously
                              discovered an OAuth 
    
                                  protected resource, the bou=
nd
                              configuration method allows a 
    
                                  client to return the config=
uration for
                              an oauth authorization 
    
                                  server that can issue token=
s for the
                              resource URI specified by 
    
                                  the client.  The AS is=
 not required to
                              be in the same domain. 
    
                                   The AS is however req=
uired to know if
                              it can issue tokens for 
    
                                  a resource service (which p=
resumes
                              some agreement exists on 
    
                                  tokens etc). 
    
                                  The draft does not require t=
hat the
                              resource exist (e.g. for 
    
                                  unconfigured or new user ba=
sed
                              resources). It only requires 
    
                                  that the AS service provide=
r agrees it
                              can issue tokens. 
    
                                  =46rom a security perspecti=
ve, returning
                              the OAuth service 
    
                                  configuration for a specifi=
ed resource
                              URI serves to confirm 
    
                                  the client is in possession=
 of a valid
                              resource URI ensuring 
    
                                  the client has received a v=
alid set of
                              endpoints for the 
    
                                  resource and the associated=
 oauth
                              services. 
    
                                  I propose that the WG consi=
der the
                              alternate draft carefully 
    
                                  as well as other submission=
s and
                              evaluate the broader 
    
                                  discovery problem before pr=
oceeding
                              with WGLC on OAuth Discovery. 
    
                                  Thanks! 
    
                                  Phil 
    
                                  @independentid 
    
                                  w=
ww.independentid.com
                              <http://www.independ=
entid.com/>
                              
    
                                  phi=
l.hunt@oracle.com
                              <mailto:phil.hunt@orac=
le.com>
                              
    
                              
    
                              
    
                                      Beg=
in forwarded message: 
    
                                      *From:=
*internet-drafts@ietf.org 
    
                                      <mailto:internet-drafts@ietf.org>
                              
    
                                      *Su=
bject: New Version Notification
                              for 
    
                                     
                              draft-hunt-oauth-bound-config-00.txt* 
    
                                      *Da=
te:*March 13, 2016 at 3:53:37
                              PM PDT 
    
                                      *To=
:*"Phil Hunt" <phil.hunt@yahoo.com
                              
    
                                      <mailto:phil.hunt@yahoo.com>>,

                              "Anthony Nadalin" 
    
                                      <=
;tonynad@microsoft.com
                              <mailto:tonynad@micro=
soft.com>>,

                              
    
                                      "To=
ny Nadalin" <tonynad@microsoft.com
                              
    
                                      <mailto:tonynad@microsoft.com>>

                              
    
                              
    
                              
    
                                      A n=
ew version of I-D,
                              draft-hunt-oauth-bound-config-00.txt 
    
                                      has=
 been successfully submitted by
                              Phil Hunt and posted to the 
    
                                      IET=
F repository. 
    
                              
    
                                      Nam=
e:draft-hunt-oauth-bound-config
                              
    
                                      Rev=
ision:00 
    
                                      Tit=
le:OAuth 2.0 Bound
                              Configuration Lookup 
    
                                      Doc=
ument date:2016-03-13 
    
                                      Gro=
up:Individual Submission 
    
                                      Pag=
es:22 
    
                                      URL=
: 
    
                                     
                              https://www.ietf.org/internet-drafts/draft-hunt-oauth-b=
ound-config-00.txt
    
                                      Sta=
tus: 
    
                                      https://datatracker.iet=
f.org/doc/draft-hunt-oauth-bound-config/
                              
    
                                      Htm=
lized: 
    
                                      https://tools.ietf.org/htm=
l/draft-hunt-oauth-bound-config-00
                              
    
                              
    
                              
    
                                      Abs=
tract: 
    
                                     &nbs=
p;  This specification defines a
                              mechanism for the client of 
    
                                      an O=
Auth 2.0 
    
                                     &nbs=
p;  protected resource service to
                              obtain the configuration 
    
                                      det=
ails of an 
    
                                     &nbs=
p;  OAuth 2.0 authorization server
                              that is capable of 
    
                                      aut=
horizing access 
    
                                     &nbs=
p;  to a specific resource service. 
                              The information 
    
                                      inc=
ludes the OAuth 
    
                                     &nbs=
p;  2.0 component endpoint location
                              URIs and as well as 
    
                                      aut=
horization 
    
                                     &nbs=
p;  server capabilities. 
    
                              
    
                              
    
                              
    
                              
    
                                      Ple=
ase note that it may take a
                              couple of minutes from the 
    
                                      tim=
e of submission 
    
                                      unt=
il the htmlized version and
                              diff are available 
    
                                      attools.=
ietf.org
                              <http://tools.ietf.org/>=
.
                              
    
                              
    
                                      The=
 IETF Secretariat 
    
                              
    
                                 
                              ______________________________________________=
_
                              
    
                                  OAuth mailing list 
    
                                  OAuth@iet=
f.org
                              <mailto:OAuth@ietf.org>
                              
    
                                      https://www.ietf.org/mailman/listinfo/oauth
                              
    
                            
    
                            
    
                          
    
                          
    
                        
    
                      
    
                      
    
                      _______________________________________________ 
    
                      OAuth mailing list 
    
                      OAuth@ietf.org
                      <mailto:OAuth@ietf.org>
                      
    
                      https://www.ietf.=
org/mailman/listinfo/oauth
                      
    
                    
    
                    
    
                    
    
                    
    
                    _______________________________________________ 
    
                    OAuth mailing list 
    
                    OAuth@ietf.org 
    
                    https://www.ietf.or=
g/mailman/listinfo/oauth
                    
    
                    
    
                  
    
                  
    
                
    
                
    
              
    
              _______________________________________________
    =

              OAuth mailing list
    
              OAuth@ietf.org
    
              https://www.ietf.org/mailman/listinfo/oauth
            
    
          
    
        
    
        
    
      
    
    
    
    
    
    
    --=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photograph=
y

    
 =20


    =

--Apple-Mail-01EAC0E5-9C90-41B0-8D21-E5340D0BF4F4--


From nobody Tue Mar 15 10:04:47 2016
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 A7CCA12DADC for ; Tue, 15 Mar 2016 10:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.013
X-Spam-Level: 
X-Spam-Status: No, score=-0.013 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 t_tp92rKJa4R for ; Tue, 15 Mar 2016 10:04:42 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C7512D63B for ; Tue, 15 Mar 2016 10:04:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5d8jeu7MnvvpD6cXH7g/yovQNVQdqWwe2U5y9curv3Q=; b=LAK7FUyoRRYEpFmESloSjz+41XZuOtM0M4FfqU3e5J9XuGuYG55ilikgNjj1TVOZMhf6HOi7EW13QkyFWDldw7wOI5VPX6rSX4/A8E63raN6gjVYbRGrOjlyPu5SKZyGg1a5zMb6XkVuEjj858jjhxhxO//nbVgoyAMDU+40xIw=
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 15 Mar 2016 17:04:19 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0434.016; Tue, 15 Mar 2016 17:04:18 +0000
From: Anthony Nadalin 
To: Brian Campbell , oauth 
Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
Thread-Index: AQHRfXsw7VgGJE45rUO1dQJbaliLD59YAM+WgAAqlwCAAD5oAIAA4ZyAgAAmbYCAABG0gIAAAnwAgAAAr7CAARUTAIAAC7CQ
Date: Tue, 15 Mar 2016 17:04:18 +0000
Message-ID: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <56E73A7C.3040405@pingidentity.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8::276]
x-ms-office365-filtering-correlation-id: df92eade-b60c-48cf-9c9d-08d34cf3d8e1
x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:2Res1neHcc+QxoVrDPBq15KRPTccbXz4Ywa2fxlsdFX5x609fLO4odSldeE3TJhRBUsOZ4gE4se4hFs0XFMaZ5ETWsOMnj6ZVavqyQrAytEKx4L7B8hWphNRAnGPJhPnJKaJFkJA3B3Oddf6tTCLnw==; 24:THJT5d/4W2p/yqgGW8khMzA1hT/DNloVvAyuraZaU7bRDYhua4dIMsYXZwM/2huLioREZMf2rnhrGu9SpiH15aBqCWbHGVMGTwxZLZXOqXs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; 
x-forefront-prvs: 08828D20BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(13464003)(479174004)(24454002)(189998001)(5004730100002)(7110500001)(1096002)(1220700001)(19580395003)(19580405001)(5001770100001)(3660700001)(5008740100001)(33656002)(16236675004)(86362001)(19625215002)(87936001)(74316001)(76176999)(790700001)(50986999)(107886002)(54356999)(19609705001)(586003)(6116002)(19300405004)(2420400007)(99286002)(5002640100001)(5003600100002)(19617315012)(102836003)(76576001)(77096005)(15975445007)(92566002)(81166005)(93886004)(2950100001)(15650500001)(2900100001)(10090500001)(8990500004)(10290500002)(230783001)(5005710100001)(122556002)(10400500002)(2906002)(106116001)(3280700002)(10710500007)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123410F37DD43A8FD6F486A0A6890BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2016 17:04:18.7706 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233
Archived-At: 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:04:45 -0000

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

UHVzaGluZyBkb2N1bWVudHMgc3VjaCBhcyBBUyBtZXRhZGF0YSBiZWNhdXNlIENvbm5lY3QgdXNl
cyB0aGVtIGRvZXMgbm90IGhlbHAgYW55dGhpbmcgYnV0IG11ZGRpZXMgdGhlIHdhdGVyLCBNZXRh
ZGF0YSBpcyBub3QgYSBzb2x1dGlvbiB0byBNaXgtdXAgYW5kIE1ldGFkYXRhIGlzIG5vdCBhIHNv
bHV0aW9uIHRvIERpc2NvdmVyeSwgYm90aCBEaXNjb3ZlcnkgYW5kIE1peC11cCBhcmUgcHJvYmxl
bXMgd2UgbmVlZCBhbmQgYWdyZWVkIHRvIGZpeC4gU28gSSB0b3RhbGx5IGFncmVlIHRoYXQgd2Ug
c2hvdWxkIG5vdCBiZSBjb25mbGF0aW5nIG1ldGFkYXRhIHdpdGggTWl4LXVwIG9yIERpc2NvdmVy
eS4gSeKAmW0gbm90IGhlYXJpbmcgb3ZlcndoZWxtaW5nIGNvbnNlbnN1cyBvbiBhZG9wdGluZyB0
aGUgbWV0YWRhdGEsIG1heWJlIHRoYXQgaXMganVzdCBjb25zZW5zdXMgYW1vbmdzdCBPcGVuSUQg
Zm9sa3MgYW5kIHllcyB0aGVyZSBhcmUgYSBmZXcgdm9jYWwgcGVvcGxlLg0KDQpNb3N0IFJTIGFu
ZCBBUyByZWxhdGlvbnNoaXBzIGFyZSBub3Qgc3RhdGljIHJlbGF0aW9uc2hpcHMsIHdlIGFyZSBz
ZWVpbmcgdGVuYW50cyB0aGF0IGFyZSBzdXBwbGluZyB0aGVpciBvd24gQVMgaW5mcmFzdHJ1Y3R1
cmUgYXMgd2VsbCBhcyBzZWVpbmcgcG9ydGFibGUgUlPigJlzIHdoaWNoIGdldHMgdXMgaW50byBz
b21lIHZlcnkgZHluYW1pYyBzaXR1YXRpb25zLg0KDQoNCg0KRnJvbTogT0F1dGggW21haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6
IFR1ZXNkYXksIE1hcmNoIDE1LCAyMDE2IDg6MDAgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5v
cmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y
IGRyYWZ0LWh1bnQtb2F1dGgtYm91bmQtY29uZmlnLTAwLnR4dA0KDQpEaXNjb3ZlcnkgaW4gZ2Vu
ZXJhbCBmb3IgT0F1dGggaXNuJ3Qgd2VsbCB1bmRlcnN0b29kLiBUaGlzIGNvbnZlcnNhdGlvbiBh
bmQgb3RoZXJzIGxpa2UgaXQgYXJvdW5kIHRoZSAnZGlzY292ZXJ5JyBkcmFmdCBkZW1vbnN0cmF0
ZSB0aGF0LiBCdXQgcHVibGlzaGluZyBBUyBtZXRhZGF0YSBpcyBzb21ldGhpbmcgdGhhdCBpcyB1
bmRlcnN0b29kIGFuZCBhbHJlYWR5IGluIHdpZGUgdXNlIGZvciBDb25uZWN0LiBUaGUgcm91Z2gg
Y29uc2Vuc3VzIChleGNlcHQgZm9yIGEgdmVyeSBmZXcgYnV0IHZvY2FsIGRpc3NlbnRlcnMpIG9u
IHRoaXMgbGlzdCBvdmVyIHRoZSBsYXN0IGZldyB3ZWVrcy9tb250aHMgaGFzIGJlZW4gdGhhdCBk
cmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeSBzaG91bGQgZGVzY3JpYmluZyBBUyBtZXRhZGF0YSBh
bmQgaXRzIGxvY2F0aW9uLiBJdCdzIGJlZW4gc3VnZ2VzdGVkIHRoYXQgdGhlIHRpdGxlIHJlZmxl
Y3QgdGhhdCBzY29wZSBhbmQgSSBtaWdodCBldmVuIHN1Z2dlc3QgdGhhdCB0aGUgZG9jdW1lbnQg
aWRlbnRpZmllciBiZSBjaGFuZ2VkIHRvIGF2b2lkIGZ1cnRoZXIgY29uZnVzaW9uLg0KVGhlIElE
UCBtaXh1cCBpcyBhZGRyZXNzZWQgYnkgdGhlIEFTIGlkZW50aWZ5aW5nIGl0c2VsZiB0byB0aGUg
Y2xpZW50IGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlIChpdCBoYXMgYSBmZXcgb3RoZXIg
dGhpbmdzIGluIGl0IHRoYXQgYXJndWFibHkgc2hvdWxkbid0IGJlIGluIG9yIHNob3VsZCBiZSBl
bHNld2hlcmUgYnV0IHRoYXQncyBhIGRpZmZlcmVudCBxdWVzdGlvbikuIFRoZSBNaXgtVXAgTWl0
aWdhdGlvbiBkcmFmdCB1c2VzIHRoZSBpc3N1ZXIgdmFsdWUgdG8gZG8gdGhhdC4gSXNzdWVyIGJl
Y29tZXMgYSBsb2dpY2FsIG5hbWUvaWRlbnRpZmllciBmb3IgYW4gQVMuIEFuZCB0aGF0IGNhbiB0
aWUgaXQgdG8gQVMgbWV0YWRhdGEgb3IgZXZlbiBkaXNjb3ZlcnkgaWYvd2hlbiB0aGF0IGV4aXN0
cy4gQnV0IGRpc2NvdmVyeSBvciBBUyBtZXRhZGF0YSBpc24ndCBuZWNlc3NhcnkgdGhlcmUuIFll
cyBUb255LCB3ZSdkIGFsbCBsaWtlIHRvIHNlZSBhIGNvbXByZWhlbnNpdmUgc29sdXRpb24gYnV0
IGNvbmZsYXRpbmcgZGlmZmVyZW50IGFuZCB1bnJlbGF0ZWQgdGhpbmdzIGlzIG9ubHkgbWFraW5n
IG1hdHRlcnMgd29yc2UgKGFzIEknbSBzdXJlIHlvdSBhcmUgd2VsbCBhd2FyZSkuDQpBICdiYWQg
UlMnIHBoaXNoaW5nIGZvciBsZWdpdGltYXRlIGFjY2VzcyB0b2tlbnMgaXMgYSBkaWZmZXJlbnQg
a2luZCBvZiBlbmRwb2ludCBjb25mdXNpb24uIE1vc3QgZGVwbG95bWVudHMgbm93IGhhdmUgYSBz
dGF0aWMgcmVsYXRpb25zaGlwIGRlZmluZWQgYmV0d2VlbiBSUyBhbmQgQVMgc28gaXQncyBtb3Jl
IG9mIGEgcG90ZW50aWFsIHByb2JsZW0gaW4gdGhlIGZ1dHVyZS4gRGVzcGl0ZSB0aGUgY29uY2Vy
biB2b2ljZWQgYWJvdXQgaXQgdGhlIHBvdGVudGlhbCAoYXMgZmFyIGFzIEkgY2FuIHRlbGwgYW55
d2F5KSwgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWcgcHJvdmlkZXMgYSB2ZXJ5IG5pY2Ug
YXR0YWNrIHZlY3RvciBmb3Igc3VjaCBhICdiYWQgUlMnIGJ5IHBvaW50aW5nIHRvIGFuIEFTIHRv
IG9idGFpbiB0b2tlbnMgaXQgY291bGQgbWlzdXNlIGF0IGxlZ2l0aW1hdGUgUlMocykuIEpvaG4g
aGFzIGFsbHVkZWQgdG8gdGhpcy4NCg0KVGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIGluY3Jl
bWVudGFsIHVwZGF0ZXMvZXh0ZW5zaW9ucyB0byBPQXV0aCAyLjAgYW5kIHRoZXJlIGxvb2sgdG8g
YmUgbW9yZSBjb21pbmcuICBDb25jZXJucyBoYXZlIGJlZW4gZXhwcmVzc2VkIG92ZXIgdGhlIG51
bWJlciBvZiBkb2N1bWVudHMgYW5kIGltcGxlbWVudHMga25vd2luZyB3aGF0IHRvIHVzZSB3aGVu
LiBJIGRvbid0IHRoaW5rIHRoZSBhbnN3ZXIgaXMgdG8gdHJ5IGFuZCBqYW0gdW5yZWxhdGVkIG5l
dyBzdHVmZiBpbnRvIG5ldyBkb2NzIHRvIGtlZXAgdGhlIG51bWJlciBvZiBkb2NzIGxvdyBpcyBh
IGdvb2QgaWRlYSB0aG91Z2guIEknZCBtdWNoIHByZWZlciB0byBoYXZlIGNvbmNpc2UgYW5kIGNv
aGVzaXZlIGRvY3VtZW50cy4gVGhlIGxhcmdlciBpc3N1ZSBvZiBjb25mdXNpb24gYXJvdW5kIHRv
byBtYW55IGRvY3VtZW50cyBzaG91bGQgYmUgYWRkcmVzc2VkIGF0IGEgaGlnaGVyIGxldmVsLiBG
b3IgZXhhbXBsZSwgc29tZXRoaW5nIGxpa2UgYW4gaW1wbGVtZW50YXRpb24gZ3VpZGUgb3IgZXZl
biBzb21ldGhpbmcgbGlrZSBhbiBPQXV0aCAyLjEgdGhhdCBkZXNjcmliZXMgdGhlIGF2YWlsYWJs
ZSBleHRlbnNpb25zIGFuZCB3aGVuL3doeSBvbmUgd291bGQgdXNlIHRoZW0uDQoNCg0KDQpPbiBN
b24sIE1hciAxNCwgMjAxNiBhdCA0OjI5IFBNLCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWlj
cm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJIHdvdWxk
IHJlYWxseSBsaWtlIHRvIHNlZSBhIGNvbXByZWhlbnNpdmUgc29sdXRpb24gbm90IHRoaXMgcGll
Y2Ugd29yaywgc28gd2Uga25vdyB3aGF0IHdlIGFyZSBzb2x2aW5nIGFuZCB3aGF0IHdlIGFyZSBu
b3QuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC
ZWhhbGYgT2YgSGFucyBaYW5kYmVsdA0KU2VudDogTW9uZGF5LCBNYXJjaCAxNCwgMjAxNiAzOjI2
IFBNDQpUbzogUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp
bC5odW50QG9yYWNsZS5jb20+PjsgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWls
dG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KQ2M6IG9hdXRoIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86
b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90
aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0wMC50eHQNCg0KT24g
My8xNC8xNiAxMDoxNyBQTSwgUGhpbCBIdW50IChJRE0pIHdyb3RlOg0KPHNuaXA+DQo+IE9uIE1h
ciAxNCwgMjAxNiwgYXQgMTQ6MTMsIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFp
bHRvOnZlN2p0YkB2ZTdqdGIuY29tPg0KPiA8bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPG1haWx0
bzp2ZTdqdGJAdmU3anRiLmNvbT4+PiB3cm90ZToNCj4+IEFueSBjbGllbnQgdGhhdCBoYXMgdGhl
IHJlc291cmNlIGFuZCBpc3N1ZXIgaGFyZCBjb2RlZCBwcm9iYWJseQ0KPj4gZG9lc24ndCBuZWVk
IGRpc2NvdmVyeS4NCj4gV2UgYWdyZWUNCg0KWWV0IGFueSBjbGllbnQgdGhhdCBoYXMgaGFyZCBj
b2RlZCBhIHJlc291cmNlIGFuZCAyIGlzc3VlcnMgZG9lc24ndCBuZWVkIGRpc2NvdmVyeSBlaXRo
ZXIgYnV0IGlzIHZ1bG5lcmFibGUgdG8gdGhlIElEUCBtaXh1cCBhdHRhY2suDQoNCkknZCByZWFs
bHkgbGlrZSB0byBzZWUgdGhlIHR3byBiZWluZyBhZGRyZXNzZWQgaW5kZXBlbmRlbnRseSBvZiBl
YWNoIG90aGVyLCByZWdhcmRsZXNzIG9mIHRoZSBmYWN0IHRoYXQgYSBEaXNjb3Zlcnkgc29sdXRp
b24gKmNvdWxkKiBzb2x2ZSB0aGUgSURQIG1peHVwIGF0dGFjayBhcyB3ZWxsLg0KDQpIYW5zLg0K
DQotLQ0KSGFucyBaYW5kYmVsdCAgICAgICAgICAgICAgfCBTci4gVGVjaG5pY2FsIEFyY2hpdGVj
dA0KaHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmh6YW5kYmVsdEBwaW5naWRlbnRp
dHkuY29tPiB8IFBpbmcgSWRlbnRpdHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp
bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlz
dGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Yzhj
ZDlhOGIyZTAyMDQ0NDM4MmE3MDhkMzRjNTdhNmI0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJnNkYXRhPTFkc3N0SmZoZHVRM21aRVJVeDYlMmZPM09FMjQxUks3YXRhYWxn
NlJZNkptQSUzZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBz
Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm
JTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAx
JTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NkYWM4ZjNjNzQ0NzE0NDQ4MzExMTA4ZDM0Y2Uy
OWVlNyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1IalJISnhS
ZThUU1hZYmkydVlNRmJEckpxaDVwc2dGaTRLWWpicDVFOHVZJTNkPg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlB1c2hpbmcgZG9jdW1lbnRzIHN1Y2ggYXMgQVMgbWV0YWRh
dGEgYmVjYXVzZSBDb25uZWN0IHVzZXMgdGhlbSBkb2VzIG5vdCBoZWxwIGFueXRoaW5nIGJ1dCBt
dWRkaWVzIHRoZSB3YXRlciwgTWV0YWRhdGEgaXMgbm90IGEgc29sdXRpb24gdG8gTWl4LXVwIGFu
ZCBNZXRhZGF0YSBpcyBub3QgYSBzb2x1dGlvbg0KIHRvIERpc2NvdmVyeSwgYm90aCBEaXNjb3Zl
cnkgYW5kIE1peC11cCBhcmUgcHJvYmxlbXMgd2UgbmVlZCBhbmQgYWdyZWVkIHRvIGZpeC4gU28g
SSB0b3RhbGx5IGFncmVlIHRoYXQgd2Ugc2hvdWxkIG5vdCBiZSBjb25mbGF0aW5nIG1ldGFkYXRh
IHdpdGggTWl4LXVwIG9yIERpc2NvdmVyeS4gSeKAmW0gbm90IGhlYXJpbmcgb3ZlcndoZWxtaW5n
IGNvbnNlbnN1cyBvbiBhZG9wdGluZyB0aGUgbWV0YWRhdGEsIG1heWJlIHRoYXQgaXMganVzdCBj
b25zZW5zdXMNCiBhbW9uZ3N0IE9wZW5JRCBmb2xrcyBhbmQgeWVzIHRoZXJlIGFyZSBhIGZldyB2
b2NhbCBwZW9wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1vc3QgUlMgYW5kIEFTIHJlbGF0aW9uc2hpcHMg
YXJlIG5vdCBzdGF0aWMgcmVsYXRpb25zaGlwcywgd2UgYXJlIHNlZWluZyB0ZW5hbnRzIHRoYXQg
YXJlIHN1cHBsaW5nIHRoZWlyIG93biBBUyBpbmZyYXN0cnVjdHVyZSBhcyB3ZWxsIGFzIHNlZWlu
ZyBwb3J0YWJsZSBSU+KAmXMgd2hpY2ggZ2V0cyB1cw0KIGludG8gc29tZSB2ZXJ5IGR5bmFtaWMg
c2l0dWF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1
dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5C
cmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAxNSwgMjAxNiA4
OjAwIEFNPGJyPg0KPGI+VG86PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm
b3IgZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWctMDAudHh0PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPkRpc2NvdmVyeSBpbiBnZW5lcmFsIGZvciBPQXV0aCBpc24ndCB3ZWxsIHVuZGVyc3Rv
b2QuIFRoaXMgY29udmVyc2F0aW9uIGFuZCBvdGhlcnMgbGlrZSBpdCBhcm91bmQgdGhlICdkaXNj
b3ZlcnknIGRyYWZ0IGRlbW9uc3RyYXRlIHRoYXQuIEJ1dCBwdWJsaXNoaW5nIEFTIG1ldGFkYXRh
IGlzIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3Rvb2QgYW5kIGFscmVhZHkNCiBpbiB3aWRlIHVz
ZSBmb3IgQ29ubmVjdC4gVGhlIHJvdWdoIGNvbnNlbnN1cyAoZXhjZXB0IGZvciBhIHZlcnkgZmV3
IGJ1dCB2b2NhbCBkaXNzZW50ZXJzKSBvbiB0aGlzIGxpc3Qgb3ZlciB0aGUgbGFzdCBmZXcgd2Vl
a3MvbW9udGhzIGhhcyBiZWVuIHRoYXQgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3Zlcnkgc2hvdWxk
IGRlc2NyaWJpbmcgQVMgbWV0YWRhdGEgYW5kIGl0cyBsb2NhdGlvbi4gSXQncyBiZWVuIHN1Z2dl
c3RlZCB0aGF0IHRoZSB0aXRsZQ0KIHJlZmxlY3QgdGhhdCBzY29wZSBhbmQgSSBtaWdodCBldmVu
IHN1Z2dlc3QgdGhhdCB0aGUgZG9jdW1lbnQgaWRlbnRpZmllciBiZSBjaGFuZ2VkIHRvIGF2b2lk
IGZ1cnRoZXIgY29uZnVzaW9uLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIElEUCBtaXh1
cCBpcyBhZGRyZXNzZWQgYnkgdGhlIEFTIGlkZW50aWZ5aW5nIGl0c2VsZiB0byB0aGUgY2xpZW50
IGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNlIChpdCBoYXMgYSBmZXcgb3RoZXIgdGhpbmdz
IGluIGl0IHRoYXQgYXJndWFibHkgc2hvdWxkbid0IGJlIGluIG9yIHNob3VsZCBiZSBlbHNld2hl
cmUgYnV0IHRoYXQncyBhIGRpZmZlcmVudA0KIHF1ZXN0aW9uKS4gVGhlIE1peC1VcCBNaXRpZ2F0
aW9uIGRyYWZ0IHVzZXMgdGhlIGlzc3VlciB2YWx1ZSB0byBkbyB0aGF0LiBJc3N1ZXIgYmVjb21l
cyBhIGxvZ2ljYWwgbmFtZS9pZGVudGlmaWVyIGZvciBhbiBBUy4gQW5kIHRoYXQgY2FuIHRpZSBp
dCB0byBBUyBtZXRhZGF0YSBvciBldmVuIGRpc2NvdmVyeSBpZi93aGVuIHRoYXQgZXhpc3RzLiBC
dXQgZGlzY292ZXJ5IG9yIEFTIG1ldGFkYXRhIGlzbid0IG5lY2Vzc2FyeSB0aGVyZS4gWWVzIFRv
bnksDQogd2UnZCBhbGwgbGlrZSB0byBzZWUgYSBjb21wcmVoZW5zaXZlIHNvbHV0aW9uIGJ1dCBj
b25mbGF0aW5nIGRpZmZlcmVudCBhbmQgdW5yZWxhdGVkIHRoaW5ncyBpcyBvbmx5IG1ha2luZyBt
YXR0ZXJzIHdvcnNlIChhcyBJJ20gc3VyZSB5b3UgYXJlIHdlbGwgYXdhcmUpLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSAnYmFkIFJTJyBwaGlz
aGluZyBmb3IgbGVnaXRpbWF0ZSBhY2Nlc3MgdG9rZW5zIGlzIGEgZGlmZmVyZW50IGtpbmQgb2Yg
ZW5kcG9pbnQgY29uZnVzaW9uLiBNb3N0IGRlcGxveW1lbnRzIG5vdyBoYXZlIGEgc3RhdGljIHJl
bGF0aW9uc2hpcCBkZWZpbmVkIGJldHdlZW4gUlMgYW5kIEFTIHNvIGl0J3MgbW9yZSBvZiBhIHBv
dGVudGlhbCBwcm9ibGVtIGluIHRoZSBmdXR1cmUuIERlc3BpdGUgdGhlIGNvbmNlcm4NCiB2b2lj
ZWQgYWJvdXQgaXQgdGhlIHBvdGVudGlhbCAoYXMgZmFyIGFzIEkgY2FuIHRlbGwgYW55d2F5KSwg
ZHJhZnQtaHVudC1vYXV0aC1ib3VuZC1jb25maWcgcHJvdmlkZXMgYSB2ZXJ5IG5pY2UgYXR0YWNr
IHZlY3RvciBmb3Igc3VjaCBhICdiYWQgUlMnIGJ5IHBvaW50aW5nIHRvIGFuIEFTIHRvIG9idGFp
biB0b2tlbnMgaXQgY291bGQgbWlzdXNlIGF0IGxlZ2l0aW1hdGUgUlMocykuIEpvaG4gaGFzIGFs
bHVkZWQgdG8gdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGVyZSBoYXZlIGJlZW4gYSBudW1iZXIgb2YgaW5jcmVtZW50YWwgdXBkYXRlcy9leHRl
bnNpb25zIHRvIE9BdXRoIDIuMCBhbmQgdGhlcmUgbG9vayB0byBiZSBtb3JlIGNvbWluZy4mbmJz
cDsgQ29uY2VybnMgaGF2ZSBiZWVuIGV4cHJlc3NlZCBvdmVyIHRoZSBudW1iZXIgb2YgZG9jdW1l
bnRzIGFuZCBpbXBsZW1lbnRzIGtub3dpbmcgd2hhdCB0byB1c2Ugd2hlbi4gSSBkb24ndCB0aGlu
ayB0aGUgYW5zd2VyIGlzIHRvDQogdHJ5IGFuZCBqYW0gdW5yZWxhdGVkIG5ldyBzdHVmZiBpbnRv
IG5ldyBkb2NzIHRvIGtlZXAgdGhlIG51bWJlciBvZiBkb2NzIGxvdyBpcyBhIGdvb2QgaWRlYSB0
aG91Z2guIEknZCBtdWNoIHByZWZlciB0byBoYXZlIGNvbmNpc2UgYW5kIGNvaGVzaXZlIGRvY3Vt
ZW50cy4gVGhlIGxhcmdlciBpc3N1ZSBvZiBjb25mdXNpb24gYXJvdW5kIHRvbyBtYW55IGRvY3Vt
ZW50cyBzaG91bGQgYmUgYWRkcmVzc2VkIGF0IGEgaGlnaGVyIGxldmVsLiBGb3IgZXhhbXBsZSwN
CiBzb21ldGhpbmcgbGlrZSBhbiBpbXBsZW1lbnRhdGlvbiBndWlkZSBvciBldmVuIHNvbWV0aGlu
ZyBsaWtlIGFuIE9BdXRoIDIuMSB0aGF0IGRlc2NyaWJlcyB0aGUgYXZhaWxhYmxlIGV4dGVuc2lv
bnMgYW5kIHdoZW4vd2h5IG9uZSB3b3VsZCB1c2UgdGhlbS4NCjxicj4NCjxicj4NCiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAx
NCwgMjAxNiBhdCA0OjI5IFBNLCBBbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0
b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj50b255bmFkQG1pY3Jvc29mdC5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JIHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSBhIGNvbXByZWhlbnNpdmUgc29s
dXRpb24gbm90IHRoaXMgcGllY2Ugd29yaywgc28gd2Uga25vdyB3aGF0IHdlIGFyZSBzb2x2aW5n
IGFuZCB3aGF0IHdlIGFyZSBub3QuPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08YnI+DQpGcm9tOiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u
IEJlaGFsZiBPZiBIYW5zIFphbmRiZWx0PGJyPg0KU2VudDogTW9uZGF5LCBNYXJjaCAxNCwgMjAx
NiAzOjI2IFBNPGJyPg0KVG86IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBo
aWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208
L2E+Jmd0OzsgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5j
b20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IG9h
dXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5v
YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTmV3IFZl
cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LW9hdXRoLWJvdW5kLWNvbmZpZy0wMC50
eHQ8YnI+DQo8YnI+DQpPbiAzLzE0LzE2IDEwOjE3IFBNLCBQaGlsIEh1bnQgKElETSkgd3JvdGU6
PGJyPg0KJmx0O3NuaXAmZ3Q7PGJyPg0KJmd0OyBPbiBNYXIgMTQsIDIwMTYsIGF0IDE0OjEzLCBK
b2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSBo
cmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3
anRiLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBBbnkgY2xpZW50IHRoYXQg
aGFzIHRoZSByZXNvdXJjZSBhbmQgaXNzdWVyIGhhcmQgY29kZWQgcHJvYmFibHk8YnI+DQomZ3Q7
Jmd0OyBkb2Vzbid0IG5lZWQgZGlzY292ZXJ5Ljxicj4NCiZndDsgV2UgYWdyZWU8YnI+DQo8YnI+
DQpZZXQgYW55IGNsaWVudCB0aGF0IGhhcyBoYXJkIGNvZGVkIGEgcmVzb3VyY2UgYW5kIDIgaXNz
dWVycyBkb2Vzbid0IG5lZWQgZGlzY292ZXJ5IGVpdGhlciBidXQgaXMgdnVsbmVyYWJsZSB0byB0
aGUgSURQIG1peHVwIGF0dGFjay48YnI+DQo8YnI+DQpJJ2QgcmVhbGx5IGxpa2UgdG8gc2VlIHRo
ZSB0d28gYmVpbmcgYWRkcmVzc2VkIGluZGVwZW5kZW50bHkgb2YgZWFjaCBvdGhlciwgcmVnYXJk
bGVzcyBvZiB0aGUgZmFjdCB0aGF0IGEgRGlzY292ZXJ5IHNvbHV0aW9uICpjb3VsZCogc29sdmUg
dGhlIElEUCBtaXh1cCBhdHRhY2sgYXMgd2VsbC48YnI+DQo8YnI+DQpIYW5zLjxicj4NCjxicj4N
Ci0tPGJyPg0KSGFucyBaYW5kYmVsdCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyB8IFNyLiBUZWNobmljYWwgQXJjaGl0ZWN0PGJyPg0KPGEgaHJlZj0ibWFp
bHRvOmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHphbmRiZWx0
QHBpbmdpZGVudGl0eS5jb208L2E+IHwgUGluZyBJZGVudGl0eTxicj4NCjxicj4NCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu
ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r
cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmcl
MmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0
MG1pY3Jvc29mdC5jb20lN2M4Y2Q5YThiMmUwMjA0NDQzODJhNzA4ZDM0YzU3YTZiNCU3YzcyZjk4
OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9MWRzc3RKZmhkdVEzbVpF
UlV4NiUyZk8zT0UyNDFSSzdhdGFhbGc2Ulk2Sm1BJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl
MmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3
YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M4Y2Q5YThiMmUwMjA0NDQzODJhNzA4ZDM0
YzU3YTZiNCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9
MWRzc3RKZmhkdVEzbVpFUlV4NiUyZk8zT0UyNDFSSzdhdGFhbGc2Ulk2Sm1BJTNkPC9hPjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl
bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYu
b3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3Rvbnlu
YWQlNDBtaWNyb3NvZnQuY29tJTdjZGFjOGYzYzc0NDcxNDQ0ODMxMTEwOGQzNGNlMjllZTclN2M3
MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUhqUkhKeFJlOFRT
WFliaTJ1WU1GYkRySnFoNXBzZ0ZpNEtZamJwNUU4dVklM2QiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BN3PR0301MB123410F37DD43A8FD6F486A0A6890BN3PR0301MB1234_--


From nobody Tue Mar 15 10:18:00 2016
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 F122712DC5C for ; Tue, 15 Mar 2016 10:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 TqYw88CLGidx for ; Tue, 15 Mar 2016 10:17:38 -0700 (PDT)
Received: from omr-m013e.mx.aol.com (omr-m013e.mx.aol.com [204.29.186.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542F812DB3C for ; Tue, 15 Mar 2016 10:17:37 -0700 (PDT)
Received: from mtaout-aaa01.mx.aol.com (mtaout-aaa01.mx.aol.com [172.27.1.225]) by omr-m013e.mx.aol.com (Outbound Mail Relay) with ESMTP id 8E53B380007D; Tue, 15 Mar 2016 13:17:36 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 0C4633800008E; Tue, 15 Mar 2016 13:17:35 -0400 (EDT)
To: "Phil Hunt (IDM)" 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com>  <56E831D4.1090609@aol.com> <54C3E288-6E8E-4AF3-AA60-7FD82417A4E4@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E843AF.2090302@aol.com>
Date: Tue, 15 Mar 2016 13:17:35 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <54C3E288-6E8E-4AF3-AA60-7FD82417A4E4@oracle.com>
Content-Type: multipart/alternative; boundary="------------020308070707030405080302"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458062256; bh=BxlXMEQOsK1NUIlUxkOgCOEck+PymSxKLIWIOl3rvLc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=gWs+E7RJWGDUvOFQAvlvQftbe/6iG8nWiHT+0VfW4P7kub3Nm+r1eT7QXx8ReJBZP berxEYM4eAoCEozUD7GjK+mi/YPtwLNgKnuDpzksbgCVh9x9HTYpGGXtq0jRzc19dw PwWmYAQ4j/kPucpXNvLRIKB+wfNsYVlaJu8Tjt4s=
x-aol-sid: 3039ac1b01e156e843af14f5
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:17:44 -0000

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

I'm less concerned about making the mitigation choice the AS's because 
to prevent the leaking of tokens you need a "good" client in both cases. 
An evil client can still request a token correctly and then send it to 
an evil RS.

If a client that "does the right thing" is required, then I don't see a 
huge advantage to either the client or the AS for performing this check.

On 3/15/16 12:42 PM, Phil Hunt (IDM) wrote:
> Thanks George
>
> I think we have to discuss cases where mitigstion is not needed such 
> as oidc.
>
> My concern is to make the mitigation choice the AS's and not the client.
>
> Phil
>
> On Mar 15, 2016, at 09:01, George Fletcher  > wrote:
>
>> I understand the benefit of having the client specify where it wants 
>> to present the token. However, in general, the client knows which 
>> kind of resource it's going to connect to (even if it doesn't know 
>> the exact endpoint). For example, if the client speaks 
>> PortableContacts, then it can potentially discover any 
>> PortableContact RS and attempt to get authorization to access the 
>> endpoints, but the client can't connect to the mail RS because it's 
>> not coded to work with those endpoints.
>>
>> Therefore, the client has an understanding of the protocol of the RS 
>> and can possibly discover related endpoints (what webfinger was 
>> really designed for) but it can't support some random new protocol. 
>> As I wrote in my response to John Bradley, I believe audience binding 
>> should use an abstract identifier not an API endpoint.
>>
>> Thanks,
>> George
>>
>> On 3/15/16 11:40 AM, Phil Hunt wrote:
>>> Regarding 2.
>>>
>>> The bound config spec makes no such requirement of knowing the and 
>>> its path structure.
>>>
>>> If you feel that you have other security measures and that clients 
>>> will always have the proper AS, then you can wildcard the whole 
>>> resource parameter.  It still might be advisable to at least check 
>>> that your clients are using a URL of the form https://*.aol.com/* or 
>>> https://*.partner.com/*.
>>>
>>> The benefit is that at least you know the client is intending to 
>>> wield the token somewhere in your domain or your partner’s domain. 
>>> as opposed to something like news.aol.myevildomain.com 
>>> .
>>>
>>> The difference here is that security remains the responsibility of 
>>> the service provider in all cases.  The check is up to the service 
>>> provider rather than the client. This means that we don’t have to 
>>> rely on trusting that the client developer bothered to check the 
>>> configuration (as in other proposals that modify OAuth protocol 
>>> itself) — we know well they won’t because they won’t have to. The 
>>> server side validation is trivial.  I’m not sure how much easier 
>>> this can be.
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com 
>>> phil.hunt@oracle.com 
>>>
>>>
>>>
>>>
>>>
>>>> On Mar 15, 2016, at 8:09 AM, George Fletcher >>> > wrote:
>>>>
>>>> I worry about two directions I see in this thread...
>>>>
>>>> 1. Client's accessing resources dynamically so that discovery is 
>>>> required to know the correct AS, etc. This is pretty much the 
>>>> classic use case for UMA and I'd rather not re-invent the wheel.
>>>>
>>>> 2. Creating a tight coupling between RS and AS such that RS 
>>>> endpoint changes must be continually communicated to the AS. If an 
>>>> RS supports multiple AS's then the RS has to deal with "guaranteed" 
>>>> delivery. The AS needs an endpoint to receive such communications. 
>>>> If not dynamic via APIs, then deployment of the new RS is bound by 
>>>> the associated AS's getting and deploying the new endpoints. Can 
>>>> both endpoints of the RS be supported within the AS for some period 
>>>> of time, etc. This is an operation nightmare and almost assuredly 
>>>> going to go wrong in production.
>>>>
>>>> Maybe an OAuth2 "audience binding" spec is what's needed for those 
>>>> deployments that require this. I believe that is what John Bradley 
>>>> is suggesting.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>> +1, I've found the very same in OAuth deployments that I was 
>>>>> involved in; the hard part is to give names and descriptions to 
>>>>> these concepts so that they cover all use cases and can be applied 
>>>>> unambiguously
>>>>>
>>>>> Hans.
>>>>>
>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:
>>>>>> I agree that this is valuable, and not just for PoP. In all honesty,
>>>>>> it’s not even really required for PoP to function in many cases — 
>>>>>> it’s
>>>>>> just an optimization for one particular kind of key distribution
>>>>>> mechanism in that case.
>>>>>>
>>>>>> In the years of deployment experience with OAuth 2, I think we’ve 
>>>>>> really
>>>>>> got three different kinds of things that currently get folded into
>>>>>> “scope†that we might want to try separating out better:
>>>>>>
>>>>>>
>>>>>>   - What things do I want to access? (photos, profile)
>>>>>>   - What actions do I want to take on these things? (read, write, 
>>>>>> delete)
>>>>>>   - How long do I want these tokens to work?
>>>>>> (offline_access/refresh_token, one time use, next hour, etc)
>>>>>>
>>>>>>
>>>>>> I think the first one is close to the audience/resource 
>>>>>> parameters that
>>>>>> have been bandied about a few times, including in the current token
>>>>>> exchange document. We should be consistent across drafts in that 
>>>>>> regard.
>>>>>> The second is more traditional scope-ish. The third has been 
>>>>>> patched in
>>>>>> with things like “offline_access†in certain APIs.
>>>>>>
>>>>>> Just another vector to think about if we’re going to be adding 
>>>>>> things
>>>>>> like “audience†or “resource†or both to the token requests.
>>>>>>
>>>>>>   — Justin
>>>>>>
>>>>>>
>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>>>> > wrote:
>>>>>>>
>>>>>>> Yes I will work on another proposal for allowing clients to specify
>>>>>>> what resource they want a token for and providing the meta-data 
>>>>>>> to the
>>>>>>> client about the resources that a token is valid for.
>>>>>>>
>>>>>>> We have part of it in the POP key distribution spec and talked 
>>>>>>> about
>>>>>>> separating it, as it is used more places than just for assigning 
>>>>>>> keys.
>>>>>>> I know some AS use different token formats for different RS so are
>>>>>>> all-ready needing to pass the resource in the request to avoid 
>>>>>>> making
>>>>>>> a mess of scopes.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Inline
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>>>>>>> The other was to mitigate the client mixup attack.  The 
>>>>>>>>> request was
>>>>>>>>> to do the latter without requiring the former for clients that 
>>>>>>>>> don’t
>>>>>>>>> otherwise need discovery.
>>>>>>>> There is no mandate for any of this. See
>>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Returning the issuer and client_id from the authorization 
>>>>>>>>> endpoint
>>>>>>>>> and the client checking them can be done by the client without
>>>>>>>>> discovery.
>>>>>>>>
>>>>>>>> How does this address the issue of whether the client is 
>>>>>>>> talking to
>>>>>>>> the wrong endpoint?
>>>>>>>>>
>>>>>>>>> Any client that has the resource and issuer hard coded probably
>>>>>>>>> doesn’t need discovery.
>>>>>>>> We agree
>>>>>>>>
>>>>>>>>
>>>>>>>>> One of the things that a client will need discovery for is to 
>>>>>>>>> find
>>>>>>>>> the RS, so requiring the client to know the RS URI before getting
>>>>>>>>> the AS config seems backwards to me.
>>>>>>>> How can you make an assumption on order? You seem to be conflating
>>>>>>>> authentication with authorization by assuming the identity drives
>>>>>>>> what the resource is.
>>>>>>>>
>>>>>>>> There are lots of applications that require user rights but are 
>>>>>>>> not
>>>>>>>> identify centric. For example a document service.
>>>>>>>>>
>>>>>>>>> Unless the client tells the AS where it intends to use the 
>>>>>>>>> token we
>>>>>>>>> will be leaving a security hole because the bearer tokens will 
>>>>>>>>> have
>>>>>>>>> too loose an audience if they have one at all.
>>>>>>>> This is the biggest risk we have IMHO.
>>>>>>>>>
>>>>>>>>> True you are telling the AS (Webfinger service) what the RS is 
>>>>>>>>> but
>>>>>>>>> that is not at a place that is useful in the token production 
>>>>>>>>> process.
>>>>>>>>
>>>>>>>> This has nothing to do with token production.
>>>>>>>>
>>>>>>>> What we want to ensure is whether an honest client is correctly
>>>>>>>> configured and has not been mislead - eg by a phishing page.
>>>>>>>>>
>>>>>>>>> I also think there are use cases where the AS doesn’t know all 
>>>>>>>>> the
>>>>>>>>> possible RS.   That is not something that a out of band check can
>>>>>>>>> address.
>>>>>>>>
>>>>>>>> May be. Lets identify them.
>>>>>>>>
>>>>>>>>> There are also cases where a token might be good at multiple RS
>>>>>>>>> endpoints intentionally.
>>>>>>>>
>>>>>>>>>  In your solution the client would need to make a discovery 
>>>>>>>>> request
>>>>>>>>> for each endpoint.
>>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool 
>>>>>>>> of AS
>>>>>>>> servers assigned to each instance?
>>>>>>>>> Those requests lack the context of who the client and resource 
>>>>>>>>> owner
>>>>>>>>> are.  I think that will be a problem in some use cases.
>>>>>>>>
>>>>>>>> Not sure I agree. This is about discovering a valid set of 
>>>>>>>> endpoints.
>>>>>>>> For mitm, we mainly want to check the hostname is correct. If a
>>>>>>>> client chooses evil.com   
>>>>>>>> the cert can be valid and
>>>>>>>> TLS will pass. How does it otherwise know it is supposed to 
>>>>>>>> talk to
>>>>>>>> res.example.com  
>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> If this is added to the token endpoint it would be checked 
>>>>>>>>> when code
>>>>>>>>> or refresh are exchanged, not every time the token is used.
>>>>>>>> Your proposal requires rhe client to check. I am not clear how 
>>>>>>>> the AS
>>>>>>>> can know the exact uri. It is far easier to validate than to 
>>>>>>>> lookup
>>>>>>>> since as you say the client may be authorized to use multiple ASs.
>>>>>>>>> With a out of band check the client would never know if a RS was
>>>>>>>>> removed/revoked.
>>>>>>>>
>>>>>>>> Not sure that is in scope.
>>>>>>>>
>>>>>>>> None of the current proposals address this issue.
>>>>>>>>>
>>>>>>>>> I don’t see checking when refreshing a token as something that 
>>>>>>>>> is a
>>>>>>>>> huge burden.
>>>>>>>>
>>>>>>>> Still its a lot more than once.
>>>>>>>>
>>>>>>>> Why don't you draft another alternative?
>>>>>>>>>
>>>>>>>>> If the server wants to do the check on it’s side then we could
>>>>>>>>> require the client to send the RS URI in the token request. 
>>>>>>>>> that way
>>>>>>>>> you really know the client is not going to get a token for the 
>>>>>>>>> wrong
>>>>>>>>> RS endpoint.
>>>>>>>>> If you check out of band in discovery you really have no idea 
>>>>>>>>> if the
>>>>>>>>> client is checking.
>>>>>>>>
>>>>>>>> In the new webfinger draft, the client isn't checking. The service
>>>>>>>> provider simply does not disclose oauth information to 
>>>>>>>> misconfigured
>>>>>>>> clients.
>>>>>>>>>
>>>>>>>>> John B.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks to Mike and John for their feedback.  I’ll take each 
>>>>>>>>>> in turn:
>>>>>>>>>>
>>>>>>>>>> Mike,
>>>>>>>>>>
>>>>>>>>>> Regarding your suggested amendments
>>>>>>>>>>
>>>>>>>>>> Item 1: Returning the config URL would create two problems. 
>>>>>>>>>> One,it
>>>>>>>>>> makes bound discovery a two-step process - that adds complexity.
>>>>>>>>>>  It seems far simpler to mandate TLS (which I think it 
>>>>>>>>>> already does
>>>>>>>>>> in the security considerations).
>>>>>>>>>>
>>>>>>>>>> The two-step process allows the current discovery process to
>>>>>>>>>> continue. I disagree with this. This is why I put forward an
>>>>>>>>>> “alternate" draft that is almost the same but simply adds the 
>>>>>>>>>> check
>>>>>>>>>> before returning the configuration data.  I worry that  
>>>>>>>>>> developers
>>>>>>>>>> would have no incentive to do the two-step approach. They would
>>>>>>>>>> just start at step 2 which in turn puts AS’s at risk of exposing
>>>>>>>>>> tokens because it works. This makes OAuth promiscuous.
>>>>>>>>>>
>>>>>>>>>> Regarding existing implementations. Most of those 
>>>>>>>>>> implementations
>>>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue 
>>>>>>>>>> use of
>>>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well 
>>>>>>>>>> defined
>>>>>>>>>> and the likelihood of a client mis-informed about the resource
>>>>>>>>>> endpoint is not there.  IMO This does not apply to the broader
>>>>>>>>>> OAuth community.
>>>>>>>>>>
>>>>>>>>>> Item 2:  It may be appropriate to have a separate configuration
>>>>>>>>>> registry specification, but I think we should hold off until we
>>>>>>>>>> have a complete solution and then make the decision what drafts
>>>>>>>>>> should exist and how many pieces.  A big concern is the 
>>>>>>>>>> perceived
>>>>>>>>>> complexity of multiple solutions and multiple drafts.
>>>>>>>>>>
>>>>>>>>>> As to John Bradley’s comments:
>>>>>>>>>>
>>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.
>>>>>>>>>> I’m confused by this.  Our mandate was to solve a security 
>>>>>>>>>> threat
>>>>>>>>>> by having a discovery specification to prevent clients being
>>>>>>>>>> mis-lead about endpoints (of which resource service is one) 
>>>>>>>>>> in an
>>>>>>>>>> oauth protected exchange.  Maybe what you mean is we should 
>>>>>>>>>> not use
>>>>>>>>>> .well-known of any kind and we should just create a “/Configâ€
>>>>>>>>>> endpoint to OAuth?
>>>>>>>>>>
>>>>>>>>>> Re: Your proposal for MITM mitigation
>>>>>>>>>> You propose that instead the resource endpoint check should 
>>>>>>>>>> be in
>>>>>>>>>> the oauth protocol itself.  The difference is that validation is
>>>>>>>>>> transferred back to the client to get it right. As well, without
>>>>>>>>>> the client informing the AS, I can’t see a way for the AS to 
>>>>>>>>>> know
>>>>>>>>>> what endpoint the client is using. The webfinger approach does
>>>>>>>>>> this once and only requires that the host name be checked in 
>>>>>>>>>> many
>>>>>>>>>> cases.
>>>>>>>>>>
>>>>>>>>>> As a principle, the members have discussed many times that 
>>>>>>>>>> the AS
>>>>>>>>>> service should do validation when possible — this was 
>>>>>>>>>> particularly
>>>>>>>>>> true at the Germany meeting when this came up. This is why I 
>>>>>>>>>> prefer
>>>>>>>>>> the client tell the service provider what it intends to do 
>>>>>>>>>> and the
>>>>>>>>>> service provider can fail that request immediately if 
>>>>>>>>>> necessary. We
>>>>>>>>>> don’t have to depend on the developer getting the spec 
>>>>>>>>>> correct to
>>>>>>>>>> fail the correct way.
>>>>>>>>>>
>>>>>>>>>> I worry that adding more parameters to the authz and token 
>>>>>>>>>> protocol
>>>>>>>>>> flows increases complexity and attack surface. It also means per
>>>>>>>>>> authorization validation has to take place vs. a one-time
>>>>>>>>>> validation at config time.  Placing it in the configuration 
>>>>>>>>>> lookup
>>>>>>>>>> phase (whether via web finger or just a special OAuth endpoint)
>>>>>>>>>> seems more appropriate and far less complex - as the request 
>>>>>>>>>> itself
>>>>>>>>>> is simple and has only one parameter. Here we are not considered
>>>>>>>>>> about legitimacy of the client. we’re just concerned with the 
>>>>>>>>>> issue
>>>>>>>>>> "has the client been correctly informed?â€
>>>>>>>>>>
>>>>>>>>>> That said, it may be that when we consider all the use cases, 
>>>>>>>>>> some
>>>>>>>>>> combination of AS protocol and discovery may be both needed. I’m
>>>>>>>>>> not ready to make conclusions about this.  The current
>>>>>>>>>> oauth-discovery spec seems to put future generic clients at risk
>>>>>>>>>> and that is my primary concern.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> @independentid
>>>>>>>>>> www.independentid.com 
>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>>>> >>>>>>>>>> >
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete 
>>>>>>>>>>> example of
>>>>>>>>>>> a way that protected resource discovery could be added to
>>>>>>>>>>> authorization server metadata discovery, and as such, should
>>>>>>>>>>> provide useful input for working group discussions on this 
>>>>>>>>>>> topic.
>>>>>>>>>>> It’s always great when someone takes the time to write an 
>>>>>>>>>>> actual
>>>>>>>>>>> draft that can be examined and implemented, and I appreciate 
>>>>>>>>>>> you
>>>>>>>>>>> doing that.
>>>>>>>>>>> The content of your draft points out that there appears to be
>>>>>>>>>>> complete agreement on what the authorization server metadata
>>>>>>>>>>> format should be, which is great! I’ll note that Section 3 of
>>>>>>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server
>>>>>>>>>>> Metadata†is an exact copy of Section 2 of
>>>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>>>>>>>>>>> applying a correction suggested by the working group.  To me 
>>>>>>>>>>> this
>>>>>>>>>>> suggests that the authorization server metadata definitions in
>>>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative
>>>>>>>>>>> content of the draft) are clearly ready for standardization, 
>>>>>>>>>>> since
>>>>>>>>>>> even your alternative proposal includes them verbatim.
>>>>>>>>>>> Reading your draft, the problem I have with it is that you are
>>>>>>>>>>> returning the AS metadata only as a WebFinger response, rather
>>>>>>>>>>> than as an https-protected resource published by the 
>>>>>>>>>>> authorization
>>>>>>>>>>> server.  The choice to only return this via WebFinger makes 
>>>>>>>>>>> your
>>>>>>>>>>> draft incompatible with most deployed implementations of OAuth
>>>>>>>>>>> metadata, including the 22 implementations using it listed
>>>>>>>>>>> athttp://openid.net/certification/(see the “OP Config†
>>>>>>>>>>> column in
>>>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft’s “ADALâ€
>>>>>>>>>>> library, which uses the metadata path for client configuration.
>>>>>>>>>>> Without having ASs provide the metadata as an https-protected
>>>>>>>>>>> resource, implementations such as ADAL can’t use it for client
>>>>>>>>>>> configuration as the currently do.
>>>>>>>>>>> Therefore, I would request that you make these minor 
>>>>>>>>>>> revisions to
>>>>>>>>>>> your draft and republish, so as to provide a unified way 
>>>>>>>>>>> forward
>>>>>>>>>>> that is compatible with all known existing OAuth Discovery
>>>>>>>>>>> deployments:
>>>>>>>>>>> 1.Modify your section 2 “Authorization Server WebFinger 
>>>>>>>>>>> Discoveryâ€
>>>>>>>>>>> to have the WebFinger request return the issuer identifier 
>>>>>>>>>>> for the
>>>>>>>>>>> AS as the “WebFinger “rel†value, rather than returning the
>>>>>>>>>>> metadata values by value as the “properties†value.
>>>>>>>>>>> 2.Reference the metadata definitions from Section 2 of
>>>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in 
>>>>>>>>>>> your
>>>>>>>>>>> Section 3.
>>>>>>>>>>> That would have the advantage of paring your draft down to only
>>>>>>>>>>> the new things that it proposes, enabling them to be more 
>>>>>>>>>>> clearly
>>>>>>>>>>> understood and evaluated on their own merits.  I look 
>>>>>>>>>>> forward to
>>>>>>>>>>> the discussions of ways of performing additional kinds of OAuth
>>>>>>>>>>> discovery, and consider your draft a valuable input to those
>>>>>>>>>>> discussions.
>>>>>>>>>>> Best wishes,
>>>>>>>>>>> -- Mike
>>>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf 
>>>>>>>>>>> Of*John Bradley
>>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>>>> *To:*Phil Hunt >>>>>>>>>> >
>>>>>>>>>>> *Cc:*oauth >
>>>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>> As I have told Phil off list.
>>>>>>>>>>> Discovery is the wrong place to try and provide security 
>>>>>>>>>>> against
>>>>>>>>>>> man in the middle attacks on the RS.
>>>>>>>>>>> This requires the client to know what the RS URI is before
>>>>>>>>>>> retrieving the information on the AS Configuration.
>>>>>>>>>>> The proposal Mike and I have been working on requires the 
>>>>>>>>>>> client
>>>>>>>>>>> to have a notion of what API it is looking for and retrieve the
>>>>>>>>>>> .well-known file for that API from the issuer.   That allows a
>>>>>>>>>>> protocol like Connect to register its own config file that can
>>>>>>>>>>> point to the RS.
>>>>>>>>>>> If the API specific well known is not available the client 
>>>>>>>>>>> can try
>>>>>>>>>>> the default oauth-server one.
>>>>>>>>>>> That then allows us to deal with restricting where AT are
>>>>>>>>>>> presented as part of the protocol rather then dragging 
>>>>>>>>>>> discovery
>>>>>>>>>>> in as a requirement.
>>>>>>>>>>> In my opinion the resource the token is targeted to should be
>>>>>>>>>>> separated from the scope and returned as part of the meta-data
>>>>>>>>>>> about the AT along with scopes granted and expiry time.   We
>>>>>>>>>>> should also have a input parameter for resources so that a 
>>>>>>>>>>> client
>>>>>>>>>>> can restrict tokens issued to a subset of the ones granted 
>>>>>>>>>>> by the
>>>>>>>>>>> refresh token.   It would then also be possible to ask a AS 
>>>>>>>>>>> for a
>>>>>>>>>>> token for a unregistered RS and have the AS produce a JWT 
>>>>>>>>>>> access
>>>>>>>>>>> token with the resource as an audience if policy allows.
>>>>>>>>>>> That however was supposed to be dealt with as part of the 
>>>>>>>>>>> mixed up
>>>>>>>>>>> client set of mitigations.
>>>>>>>>>>> In that the goal was to mitigate the attacks by returning
>>>>>>>>>>> meta-data about the tokens, and not to require discovery.
>>>>>>>>>>> We intend to return “iss†and “cleint_id†for the code, and I
>>>>>>>>>>> intend to discuss at the F2F returning resource for AT as well.
>>>>>>>>>>> Those mitigate the attack.
>>>>>>>>>>> I will continue to resist mixing up discovery of configuration
>>>>>>>>>>> meta-data with mitigation of the attacks.
>>>>>>>>>>> We return meta-data about the tokens now, because AT are 
>>>>>>>>>>> opaque to
>>>>>>>>>>> the client, we neglected to include some of the information for
>>>>>>>>>>> the client needs to be secure.   We just need to add that in to
>>>>>>>>>>> the existing flows.
>>>>>>>>>>> While Phil’s proposal is easier for the AS to implement as 
>>>>>>>>>>> an add
>>>>>>>>>>> on, it puts more of a burden on the client needing to 
>>>>>>>>>>> potentially
>>>>>>>>>>> change how it stores the relationships between AS and RS to
>>>>>>>>>>> prevent compromise, I think the solution should be biased 
>>>>>>>>>>> towards
>>>>>>>>>>> simplicity on the client side.
>>>>>>>>>>> If we return the resources as part of the existing meta data 
>>>>>>>>>>> the
>>>>>>>>>>> client checks that against the resource it intends to send the
>>>>>>>>>>> token to and if it is not in the list then it can’t send the
>>>>>>>>>>> token.  Simple check every time it gets a new AT, no 
>>>>>>>>>>> optionality.
>>>>>>>>>>> I am not saying anything new Nat has been advocating basically
>>>>>>>>>>> this for some time, and dis submit a draft.   I prefer to 
>>>>>>>>>>> return
>>>>>>>>>>> the info in the existing format rather than as link 
>>>>>>>>>>> headers,  but
>>>>>>>>>>> that is the largest difference between what Nat and I are 
>>>>>>>>>>> saying
>>>>>>>>>>> with respect to resource.
>>>>>>>>>>> That is the core of my problem with Phil’s draft.
>>>>>>>>>>> I guess we will need to have a long conversation in BA.
>>>>>>>>>>> Regards
>>>>>>>>>>> John B.
>>>>>>>>>>>
>>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt 
>>>>>>>>>>> >>>>>>>>>> > wrote:
>>>>>>>>>>>     This draft is a proposed alternate proposal for
>>>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same
>>>>>>>>>>>     registry for OAuth Config Metadata as the authors 
>>>>>>>>>>> believe that
>>>>>>>>>>>     both solutions are not required, or depending on WG 
>>>>>>>>>>> discussion
>>>>>>>>>>>     they will be merged. The intent is to provide a simple
>>>>>>>>>>>     complete draft for consideration.
>>>>>>>>>>>     How it works...
>>>>>>>>>>>     Given that a client has previously discovered an OAuth
>>>>>>>>>>>     protected resource, the bound configuration method allows a
>>>>>>>>>>>     client to return the configuration for an oauth 
>>>>>>>>>>> authorization
>>>>>>>>>>>     server that can issue tokens for the resource URI 
>>>>>>>>>>> specified by
>>>>>>>>>>>     the client.  The AS is not required to be in the same 
>>>>>>>>>>> domain.
>>>>>>>>>>>      The AS is however required to know if it can issue 
>>>>>>>>>>> tokens for
>>>>>>>>>>>     a resource service (which presumes some agreement exists on
>>>>>>>>>>>     tokens etc).
>>>>>>>>>>>     The draft does not require that the resource exist (e.g. 
>>>>>>>>>>> for
>>>>>>>>>>>     unconfigured or new user based resources). It only requires
>>>>>>>>>>>     that the AS service provider agrees it can issue tokens.
>>>>>>>>>>>     From a security perspective, returning the OAuth service
>>>>>>>>>>>     configuration for a specified resource URI serves to 
>>>>>>>>>>> confirm
>>>>>>>>>>>     the client is in possession of a valid resource URI 
>>>>>>>>>>> ensuring
>>>>>>>>>>>     the client has received a valid set of endpoints for the
>>>>>>>>>>>     resource and the associated oauth services.
>>>>>>>>>>>     I propose that the WG consider the alternate draft 
>>>>>>>>>>> carefully
>>>>>>>>>>>     as well as other submissions and evaluate the broader
>>>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth 
>>>>>>>>>>> Discovery.
>>>>>>>>>>>     Thanks!
>>>>>>>>>>>     Phil
>>>>>>>>>>>     @independentid
>>>>>>>>>>> www.independentid.com 
>>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Begin forwarded message:
>>>>>>>>>>>         *From:*internet-drafts@ietf.org 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>         *Subject: New Version Notification for
>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt*
>>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>>>> >, "Anthony Nadalin"
>>>>>>>>>>>         >,
>>>>>>>>>>>         "Tony Nadalin" >>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         A new version of I-D, 
>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>         has been successfully submitted by Phil Hunt and 
>>>>>>>>>>> posted to the
>>>>>>>>>>>         IETF repository.
>>>>>>>>>>>
>>>>>>>>>>> Name:draft-hunt-oauth-bound-config
>>>>>>>>>>>         Revision:00
>>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>>>>>         Document date:2016-03-13
>>>>>>>>>>>         Group:Individual Submission
>>>>>>>>>>>         Pages:22
>>>>>>>>>>>         URL:
>>>>>>>>>>> https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>         Status:
>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>>>>>         Htmlized:
>>>>>>>>>>> https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Abstract:
>>>>>>>>>>>           This specification defines a mechanism for the 
>>>>>>>>>>> client of
>>>>>>>>>>>         an OAuth 2.0
>>>>>>>>>>>           protected resource service to obtain the 
>>>>>>>>>>> configuration
>>>>>>>>>>>         details of an
>>>>>>>>>>>           OAuth 2.0 authorization server that is capable of
>>>>>>>>>>>         authorizing access
>>>>>>>>>>>           to a specific resource service.  The information
>>>>>>>>>>>         includes the OAuth
>>>>>>>>>>>           2.0 component endpoint location URIs and as well as
>>>>>>>>>>>         authorization
>>>>>>>>>>>           server capabilities.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Please note that it may take a couple of minutes 
>>>>>>>>>>> from the
>>>>>>>>>>>         time of submission
>>>>>>>>>>>         until the htmlized version and diff are available
>>>>>>>>>>> attools.ietf.org  
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>>         The IETF Secretariat
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>     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
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>


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


  
    
  
  
    I'm less concerned about
      making the mitigation choice the AS's because to prevent the
      leaking of tokens you need a "good" client in both cases. An evil
      client can still request a token correctly and then send it to an
      evil RS.
    
      
    
      If a client that "does the right thing" is required, then I don't
      see a huge advantage to either the client or the AS for performing
      this check.
    
    
    
    
    On 3/15/16 12:42 PM, Phil Hunt (IDM)
      wrote:
    
    
    
    
    
      
      
    Thanks George
    
      

    
      
    
      
    I think we have to discuss cases
        where mitigstion is not needed such as oidc. 
    
      

    
      
    
      
    My concern is to make the mitigation
        choice the AS's and not the client. 
    
        
    
        Phil
    
      

    
        On Mar 15, 2016, at 09:01, George Fletcher <gffletch@aol.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
          I understand the
            benefit of having the client specify where it wants to
            present the token. However, in general, the client knows
            which kind of resource it's going to connect to (even if it
            doesn't know the exact endpoint). For example, if the client
            speaks PortableContacts, then it can potentially discover
            any PortableContact RS and attempt to get authorization to
            access the endpoints, but the client can't connect to the
            mail RS because it's not coded to work with those endpoints.
    
            
    
            Therefore, the client has an understanding of the protocol
            of the RS and can possibly discover related endpoints (what
            webfinger was really designed for) but it can't support some
            random new protocol. As I wrote in my response to John
            Bradley, I believe audience binding should use an abstract
            identifier not an API endpoint.
    
            
    
            Thanks,
    
            George
    
          
    
          
    On 3/15/16 11:40 AM, Phil Hunt
            wrote:
    
          
    
          
    
            
            Regarding 2.
            

    
            
    
            
    The bound config spec makes no such
              requirement of knowing the and its path structure.  
    
            

    
            
    
            
    If you feel that you have other security
              measures and that clients will always have the proper AS,
              then you can wildcard the whole resource parameter.  It
              still might be advisable to at least check that your
              clients are using a URL of the form https://*.aol.com/* or https://*.partner.com/*.
    
            

    
            
    
            
    The benefit is that at least you know the
              client is intending to wield the token somewhere in your
              domain or your partner’s domain. as opposed to something
              like news.aol.myevildomain.com.
    
            

    
            
    
            
    The difference here is that security remains
              the responsibility of the service provider in all cases.
               The check is up to the service provider rather than the
              client. This means that we don’t have to rely on trusting
              that the client developer bothered to check the
              configuration (as in other proposals that modify OAuth
              protocol itself) — we know well they won’t because they
              won’t have to. The server side validation is trivial.  I’m
              not sure how much easier this can be.  
    
            

    
            
    
            
    
              
              
    
              
    
                
    
                  
    On Mar 15, 2016, at 8:09 AM, George
                    Fletcher <gffletch@aol.com>

                    wrote:
    
                  
    
                  
    
                    
                    
     I
                        worry about two directions I see in this
                        thread...
    
                        
    
                        1. Client's accessing resources dynamically so
                        that discovery is required to know the correct
                        AS, etc. This is pretty much the classic use
                        case for UMA and I'd rather not re-invent the
                        wheel.
    
                        
    
                        2. Creating a tight coupling between RS and AS
                        such that RS endpoint changes must be
                        continually communicated to the AS. If an RS
                        supports multiple AS's then the RS has to deal
                        with "guaranteed" delivery. The AS needs an
                        endpoint to receive such communications. If not
                        dynamic via APIs, then deployment of the new RS
                        is bound by the associated AS's getting and
                        deploying the new endpoints. Can both endpoints
                        of the RS be supported within the AS for some
                        period of time, etc. This is an operation
                        nightmare and almost assuredly going to go wrong
                        in production.
    
                        
    
                        Maybe an OAuth2 "audience binding" spec is
                        what's needed for those deployments that require
                        this. I believe that is what John Bradley is
                        suggesting.
    
                        
    
                        Thanks,
    
                        George
    
                      
    
                      
    On 3/14/16 7:29 PM,
                        Hans Zandbelt wrote:
    
                      
    
                      
    +1, I've found the very
                        same in OAuth deployments that I was involved
                        in; the hard part is to give names and
                        descriptions to these concepts so that they
                        cover all use cases and can be applied
                        unambiguously 
    
                        
    
                        Hans. 
    
                        
    
                        On 3/14/16 10:44 PM, Justin Richer wrote: 
    
                        
    I agree that
                          this is valuable, and not just for PoP. In all
                          honesty, 
    
                          it’s not even really required for PoP to
                          function in many cases — it’s 
    
                          just an optimization for one particular kind
                          of key distribution 
    
                          mechanism in that case. 
    
                          
    
                          In the years of deployment experience with
                          OAuth 2, I think we’ve really 
    
                          got three different kinds of things that
                          currently get folded into 
    
                          “scope†that we might want to try separating
                          out better: 
    
                          
    
                          
    
                            - What things do I want to access? (photos,
                          profile) 
    
                            - What actions do I want to take on these
                          things? (read, write, delete) 
    
                            - How long do I want these tokens to work? 
    
                          (offline_access/refresh_token, one time use,
                          next hour, etc) 
    
                          
    
                          
    
                          I think the first one is close to the
                          audience/resource parameters that 
    
                          have been bandied about a few times, including
                          in the current token 
    
                          exchange document. We should be consistent
                          across drafts in that regard. 
    
                          The second is more traditional scope-ish. The
                          third has been patched in 
    
                          with things like “offline_access†in certain
                          APIs. 
    
                          
    
                          Just another vector to think about if we’re
                          going to be adding things 
    
                          like “audience†or “resource†or both to the
                          token requests. 
    
                          
    
                            — Justin 
    
                          
    
                          
    
                          
    On Mar 14,
                            2016, at 6:26 PM, John Bradley <ve7jtb@ve7jtb.com
                            
    
                            <mailto:ve7jtb@ve7jtb.com>>

                            wrote: 
    
                            
    
                            Yes I will work on another proposal for
                            allowing clients to specify 
    
                            what resource they want a token for and
                            providing the meta-data to the 
    
                            client about the resources that a token is
                            valid for. 
    
                            
    
                            We have part of it in the POP key
                            distribution spec and talked about 
    
                            separating it, as it is used more places
                            than just for assigning keys. 
    
                            I know some AS use different token formats
                            for different RS so are 
    
                            all-ready needing to pass the resource in
                            the request to avoid making 
    
                            a mess of scopes. 
    
                            
    
                            John B. 
    
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    On Mar 14,
                              2016, at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com
                              
    
                              <mailto:phil.hunt@oracle.com>>

                              wrote: 
    
                              
    
                              Inline 
    
                              
    
                              Phil 
    
                              
    
                              On Mar 14, 2016, at 14:13, John Bradley
                              <ve7jtb@ve7jtb.com
                              
    
                              <mailto:ve7jtb@ve7jtb.com>>

                              wrote: 
    
                              
    
                              
    We had
                                two mandates.  One was to provide a spec
                                for AS metadata. 
    
                                The other was to mitigate the client
                                mixup attack.  The request was 
    
                                to do the latter without requiring the
                                former for clients that don’t 
    
                                otherwise need discovery. 
    
                              
    
                              There is no mandate for any of this. See 
    
                              http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
                              
    
                              
     
    
                                Returning the issuer and client_id from
                                the authorization endpoint 
    
                                and the client checking them can be done
                                by the client without 
    
                                discovery. 
    
                              
    
                              
    
                              How does this address the issue of whether
                              the client is talking to 
    
                              the wrong endpoint? 
    
                              
     
    
                                Any client that has the resource and
                                issuer hard coded probably 
    
                                doesn’t need discovery. 
    
                              
    
                              We agree 
    
                              
    
                              
    
                              
    One of
                                the things that a client will need
                                discovery for is to find 
    
                                the RS, so requiring the client to know
                                the RS URI before getting 
    
                                the AS config seems backwards to me. 
    
                              
    
                              How can you make an assumption on order?
                              You seem to be conflating 
    
                              authentication with authorization by
                              assuming the identity drives 
    
                              what the resource is. 
    
                              
    
                              There are lots of applications that
                              require user rights but are not 
    
                              identify centric. For example a document
                              service. 
    
                              
     
    
                                Unless the client tells the AS where it
                                intends to use the token we 
    
                                will be leaving a security hole because
                                the bearer tokens will have 
    
                                too loose an audience if they have one
                                at all. 
    
                              
    
                              This is the biggest risk we have IMHO. 
    
                              
     
    
                                True you are telling the AS (Webfinger
                                service) what the RS is but 
    
                                that is not at a place that is useful in
                                the token production process. 
    
                              
    
                              
    
                              This has nothing to do with token
                              production. 
    
                              
    
                              What we want to ensure is whether an
                              honest client is correctly 
    
                              configured and has not been mislead - eg
                              by a phishing page. 
    
                              
     
    
                                I also think there are use cases where
                                the AS doesn’t know all the 
    
                                possible RS.   That is not something
                                that a out of band check can 
    
                                address. 
    
                              
    
                              
    
                              May be. Lets identify them. 
    
                              
    
                              
    There are
                                also cases where a token might be good
                                at multiple RS 
    
                                endpoints intentionally. 
    
                              
    
                              
    
                              
     In your
                                solution the client would need to make a
                                discovery request 
    
                                for each endpoint. 
    
                              
    
                              Sure. Otherwise how would it know if there
                              is one AS or a pool of AS 
    
                              servers assigned to each instance? 
    
                              
    Those
                                requests lack the context of who the
                                client and resource owner 
    
                                are.  I think that will be a problem in
                                some use cases. 
    
                              
    
                              
    
                              Not sure I agree. This is about
                              discovering a valid set of endpoints. 
    
                              For mitm, we mainly want to check the
                              hostname is correct. If a 
    
                              client chooses evil.com
                              <http://evil.com/>
                              the cert can be valid and 
    
                              TLS will pass. How does it otherwise know
                              it is supposed to talk to 
    
                              res.example.com
                              <http://res.example.com/>?
                              
    
                              
     
    
                                If this is added to the token endpoint
                                it would be checked when code 
    
                                or refresh are exchanged, not every time
                                the token is used. 
    
                              
    
                              Your proposal requires rhe client to
                              check. I am not clear how the AS 
    
                              can know the exact uri. It is far easier
                              to validate than to lookup 
    
                              since as you say the client may be
                              authorized to use multiple ASs. 
    
                              
    With a
                                out of band check the client would never
                                know if a RS was 
    
                                removed/revoked. 
    
                              
    
                              
    
                              Not sure that is in scope. 
    
                              
    
                              None of the current proposals address this
                              issue. 
    
                              
     
    
                                I don’t see checking when refreshing a
                                token as something that is a 
    
                                huge burden. 
    
                              
    
                              
    
                              Still its a lot more than once. 
    
                              
    
                              Why don't you draft another alternative? 
    
                              
     
    
                                If the server wants to do the check on
                                it’s side then we could 
    
                                require the client to send the RS URI in
                                the token request. that way 
    
                                you really know the client is not going
                                to get a token for the wrong 
    
                                RS endpoint. 
    
                                If you check out of band in discovery
                                you really have no idea if the 
    
                                client is checking. 
    
                              
    
                              
    
                              In the new webfinger draft, the client
                              isn't checking. The service 
    
                              provider simply does not disclose oauth
                              information to misconfigured 
    
                              clients. 
    
                              
     
    
                                John B. 
    
                                
    
                                
    
                                
    On Mar
                                  14, 2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com
                                  
    
                                  <mailto:phil.hunt@oracle.com>>

                                  wrote: 
    
                                  
    
                                  Thanks to Mike and John for their
                                  feedback.  I’ll take each in turn: 
    
                                  
    
                                  Mike, 
    
                                  
    
                                  Regarding your suggested amendments 
    
                                  
    
                                  Item 1: Returning the config URL would
                                  create two problems. One,it 
    
                                  makes bound discovery a two-step
                                  process - that adds complexity. 
    
                                   It seems far simpler to mandate TLS
                                  (which I think it already does 
    
                                  in the security considerations). 
    
                                  
    
                                  The two-step process allows the
                                  current discovery process to 
    
                                  continue. I disagree with this. This
                                  is why I put forward an 
    
                                  “alternate" draft that is almost the
                                  same but simply adds the check 
    
                                  before returning the configuration
                                  data.  I worry that  developers 
    
                                  would have no incentive to do the
                                  two-step approach. They would 
    
                                  just start at step 2 which in turn
                                  puts AS’s at risk of exposing 
    
                                  tokens because it works. This makes
                                  OAuth promiscuous. 
    
                                  
    
                                  Regarding existing implementations.
                                  Most of those implementations 
    
                                  are for OIDC.  I think it makes sense
                                  for OIDF to continue use of 
    
                                  OIDC's discovery spec because the
                                  UserInfo endpoint is well defined 
    
                                  and the likelihood of a client
                                  mis-informed about the resource 
    
                                  endpoint is not there.  IMO This does
                                  not apply to the broader 
    
                                  OAuth community. 
    
                                  
    
                                  Item 2:  It may be appropriate to have
                                  a separate configuration 
    
                                  registry specification, but I think we
                                  should hold off until we 
    
                                  have a complete solution and then make
                                  the decision what drafts 
    
                                  should exist and how many pieces.  A
                                  big concern is the perceived 
    
                                  complexity of multiple solutions and
                                  multiple drafts. 
    
                                  
    
                                  As to John Bradley’s comments: 
    
                                  
    
                                  Re: Discovery is the wrong place to
                                  mitigate threats. 
    
                                  I’m confused by this.  Our mandate was
                                  to solve a security threat 
    
                                  by having a discovery specification to
                                  prevent clients being 
    
                                  mis-lead about endpoints (of which
                                  resource service is one) in an 
    
                                  oauth protected exchange.  Maybe what
                                  you mean is we should not use 
    
                                  .well-known of any kind and we should
                                  just create a “/Config†
    
                                  endpoint to OAuth? 
    
                                  
    
                                  Re: Your proposal for MITM mitigation
                                  
    
                                  You propose that instead the resource
                                  endpoint check should be in 
    
                                  the oauth protocol itself.  The
                                  difference is that validation is 
    
                                  transferred back to the client to get
                                  it right. As well, without 
    
                                  the client informing the AS, I can’t
                                  see a way for the AS to know 
    
                                  what endpoint the client is using. 
                                  The webfinger approach does 
    
                                  this once and only requires that the
                                  host name be checked in many 
    
                                  cases. 
    
                                  
    
                                  As a principle, the members have
                                  discussed many times that the AS 
    
                                  service should do validation when
                                  possible — this was particularly 
    
                                  true at the Germany meeting when this
                                  came up. This is why I prefer 
    
                                  the client tell the service provider
                                  what it intends to do and the 
    
                                  service provider can fail that request
                                  immediately if necessary. We 
    
                                  don’t have to depend on the developer
                                  getting the spec correct to 
    
                                  fail the correct way. 
    
                                  
    
                                  I worry that adding more parameters to
                                  the authz and token protocol 
    
                                  flows increases complexity and attack
                                  surface. It also means per 
    
                                  authorization validation has to take
                                  place vs. a one-time 
    
                                  validation at config time.  Placing it
                                  in the configuration lookup 
    
                                  phase (whether via web finger or just
                                  a special OAuth endpoint) 
    
                                  seems more appropriate and far less
                                  complex - as the request itself 
    
                                  is simple and has only one parameter.
                                  Here we are not considered 
    
                                  about legitimacy of the client. we’re
                                  just concerned with the issue 
    
                                  "has the client been correctly
                                  informed?†
    
                                  
    
                                  That said, it may be that when we
                                  consider all the use cases, some 
    
                                  combination of AS protocol and
                                  discovery may be both needed. I’m 
    
                                  not ready to make conclusions about
                                  this.  The current 
    
                                  oauth-discovery spec seems to put
                                  future generic clients at risk 
    
                                  and that is my primary concern. 
    
                                  
    
                                  Best Regards, 
    
                                  
    
                                  Phil 
    
                                  
    
                                  @independentid 
    
                                  www.independentid.com
                                  <http://www.independentid.com/>
                                  
    
                                  phil.hunt@oracle.com
                                  <mailto:phil.hunt@oracle.com>
                                  
    
                                  
    
                                  
    
                                  
    
                                  
    
                                  
    
                                  
    On
                                    Mar 13, 2016, at 10:28 PM, Mike
                                    Jones 
    
                                    <Michael.Jones@microsoft.com
                                    <mailto:Michael.Jones@microsoft.com>>


                                    
    
                                    wrote: 
    
                                    
    
                                    Thanks for posting this, Phil.  It
                                    provides a concrete example of 
    
                                    a way that protected resource
                                    discovery could be added to 
    
                                    authorization server metadata
                                    discovery, and as such, should 
    
                                    provide useful input for working
                                    group discussions on this topic. 
    
                                    It’s always great when someone takes
                                    the time to write an actual 
    
                                    draft that can be examined and
                                    implemented, and I appreciate you 
    
                                    doing that. 
    
                                    The content of your draft points out
                                    that there appears to be 
    
                                    complete agreement on what the
                                    authorization server metadata 
    
                                    format should be, which is great! 
                                    I’ll note that Section 3 of 
    
                                    draft-hunt-oauth-bound-config-00
                                    titled “Authorization Server 
    
                                    Metadata†is an exact copy of
                                    Section 2 of 
    
                                    draft-ietf-oauth-discovery-01 (with
                                    the same title), modulo 
    
                                    applying a correction suggested by
                                    the working group.  To me this 
    
                                    suggests that the authorization
                                    server metadata definitions in 
    
                                    draft-ietf-oauth-discovery (which is
                                    now the whole normative 
    
                                    content of the draft) are clearly
                                    ready for standardization, since 
    
                                    even your alternative proposal
                                    includes them verbatim. 
    
                                    Reading your draft, the problem I
                                    have with it is that you are 
    
                                    returning the AS metadata only as a
                                    WebFinger response, rather 
    
                                    than as an https-protected resource
                                    published by the authorization 
    
                                    server.  The choice to only return
                                    this via WebFinger makes your 
    
                                    draft incompatible with most
                                    deployed implementations of OAuth 
    
                                    metadata, including the 22
                                    implementations using it listed 
    
                                    athttp://openid.net/certification/(see

                                    the “OP Config†column in 
    
                                    the table) andOAuth 2.0 libraries
                                    such as Microsoft’s “ADAL†
    
                                    library, which uses the metadata
                                    path for client configuration. 
    
                                    Without having ASs provide the
                                    metadata as an https-protected 
    
                                    resource, implementations such as
                                    ADAL can’t use it for client 
    
                                    configuration as the currently do. 
    
                                    Therefore, I would request that you
                                    make these minor revisions to 
    
                                    your draft and republish, so as to
                                    provide a unified way forward 
    
                                    that is compatible with all known
                                    existing OAuth Discovery 
    
                                    deployments: 
    
                                    1.Modify your section 2
                                    “Authorization Server WebFinger
                                    Discovery†
    
                                    to have the WebFinger request return
                                    the issuer identifier for the 
    
                                    AS as the “WebFinger “rel†value,
                                    rather than returning the 
    
                                    metadata values by value as the
                                    “properties†value. 
    
                                    2.Reference the metadata definitions
                                    from Section 2 of 
    
                                    draft-ietf-oauth-discovery, rather
                                    than duplicating them in your 
    
                                    Section 3. 
    
                                    That would have the advantage of
                                    paring your draft down to only 
    
                                    the new things that it proposes,
                                    enabling them to be more clearly 
    
                                    understood and evaluated on their
                                    own merits.  I look forward to 
    
                                    the discussions of ways of
                                    performing additional kinds of OAuth
                                    
    
                                    discovery, and consider your draft a
                                    valuable input to those 
    
                                    discussions. 
    
                                                                                             


                                    Best wishes, 
    
                                                                                             


                                    -- Mike 
    
                                    *From:*OAuth [mailto:oauth-bounces@ietf.org]*On

                                    Behalf Of*John Bradley 
    
                                    *Sent:*Sunday, March 13, 2016 6:45
                                    PM 
    
                                    *To:*Phil Hunt <phil.hunt@oracle.com
                                    <mailto:phil.hunt@oracle.com>>


                                    
    
                                    *Cc:*oauth <oauth@ietf.org
                                    <mailto:oauth@ietf.org>>


                                    
    
                                    *Subject:*Re: [OAUTH-WG] New Version
                                    Notification for 
    
                                    draft-hunt-oauth-bound-config-00.txt
                                    
    
                                    As I have told Phil off list. 
    
                                    Discovery is the wrong place to try
                                    and provide security against 
    
                                    man in the middle attacks on the RS.
                                    
    
                                    This requires the client to know
                                    what the RS URI is before 
    
                                    retrieving the information on the AS
                                    Configuration. 
    
                                    The proposal Mike and I have been
                                    working on requires the client 
    
                                    to have a notion of what API it is
                                    looking for and retrieve the 
    
                                    .well-known file for that API from
                                    the issuer.   That allows a 
    
                                    protocol like Connect to register
                                    its own config file that can 
    
                                    point to the RS. 
    
                                    If the API specific well known is
                                    not available the client can try 
    
                                    the default oauth-server one. 
    
                                    That then allows us to deal with
                                    restricting where AT are 
    
                                    presented as part of the protocol
                                    rather then dragging discovery 
    
                                    in as a requirement. 
    
                                    In my opinion the resource the token
                                    is targeted to should be 
    
                                    separated from the scope and
                                    returned as part of the meta-data 
    
                                    about the AT along with scopes
                                    granted and expiry time.   We 
    
                                    should also have a input parameter
                                    for resources so that a client 
    
                                    can restrict tokens issued to a
                                    subset of the ones granted by the 
    
                                    refresh token.   It would then also
                                    be possible to ask a AS for a 
    
                                    token for a unregistered RS and have
                                    the AS produce a JWT access 
    
                                    token with the resource as an
                                    audience if policy allows. 
    
                                    That however was supposed to be
                                    dealt with as part of the mixed up 
    
                                    client set of mitigations. 
    
                                    In that the goal was to mitigate the
                                    attacks by returning 
    
                                    meta-data about the tokens, and not
                                    to require discovery. 
    
                                    We intend to return “iss†and
                                    “cleint_id†for the code, and I 
    
                                    intend to discuss at the F2F
                                    returning resource for AT as well. 
    
                                    Those mitigate the attack. 
    
                                    I will continue to resist mixing up
                                    discovery of configuration 
    
                                    meta-data with mitigation of the
                                    attacks. 
    
                                    We return meta-data about the tokens
                                    now, because AT are opaque to 
    
                                    the client, we neglected to include
                                    some of the information for 
    
                                    the client needs to be secure.   We
                                    just need to add that in to 
    
                                    the existing flows. 
    
                                    While Phil’s proposal is easier for
                                    the AS to implement as an add 
    
                                    on, it puts more of a burden on the
                                    client needing to potentially 
    
                                    change how it stores the
                                    relationships between AS and RS to 
    
                                    prevent compromise, I think the
                                    solution should be biased towards 
    
                                    simplicity on the client side. 
    
                                    If we return the resources as part
                                    of the existing meta data the 
    
                                    client checks that against the
                                    resource it intends to send the 
    
                                    token to and if it is not in the
                                    list then it can’t send the 
    
                                    token.  Simple check every time it
                                    gets a new AT, no optionality. 
    
                                    I am not saying anything new Nat has
                                    been advocating basically 
    
                                    this for some time, and dis submit a
                                    draft.   I prefer to return 
    
                                    the info in the existing format
                                    rather than as link headers,  but 
    
                                    that is the largest difference
                                    between what Nat and I are saying 
    
                                    with respect to resource. 
    
                                    That is the core of my problem with
                                    Phil’s draft. 
    
                                    I guess we will need to have a long
                                    conversation in BA. 
    
                                    Regards 
    
                                    John B. 
    
                                    
    
                                        On Mar 13, 2016, at 8:12 PM,
                                    Phil Hunt <phil.hunt@oracle.com
                                    
    
                                        <mailto:phil.hunt@oracle.com>>

                                    wrote: 
    
                                        This draft is a proposed
                                    alternate proposal for 
    
                                        draft-ietf-oauth-discovery.  As
                                    such, it contains the same 
    
                                        registry for OAuth Config
                                    Metadata as the authors believe that
                                    
    
                                        both solutions are not required,
                                    or depending on WG discussion 
    
                                        they will be merged. The intent
                                    is to provide a simple 
    
                                        complete draft for
                                    consideration. 
    
                                        How it works... 
    
                                        Given that a client has
                                    previously discovered an OAuth 
    
                                        protected resource, the bound
                                    configuration method allows a 
    
                                        client to return the
                                    configuration for an oauth
                                    authorization 
    
                                        server that can issue tokens for
                                    the resource URI specified by 
    
                                        the client.  The AS is not
                                    required to be in the same domain. 
    
                                         The AS is however required to
                                    know if it can issue tokens for 
    
                                        a resource service (which
                                    presumes some agreement exists on 
    
                                        tokens etc). 
    
                                        The draft does not require that
                                    the resource exist (e.g. for 
    
                                        unconfigured or new user based
                                    resources). It only requires 
    
                                        that the AS service provider
                                    agrees it can issue tokens. 
    
                                        From a security perspective,
                                    returning the OAuth service 
    
                                        configuration for a specified
                                    resource URI serves to confirm 
    
                                        the client is in possession of a
                                    valid resource URI ensuring 
    
                                        the client has received a valid
                                    set of endpoints for the 
    
                                        resource and the associated
                                    oauth services. 
    
                                        I propose that the WG consider
                                    the alternate draft carefully 
    
                                        as well as other submissions and
                                    evaluate the broader 
    
                                        discovery problem before
                                    proceeding with WGLC on OAuth
                                    Discovery. 
    
                                        Thanks! 
    
                                        Phil 
    
                                        @independentid 
    
                                        www.independentid.com
                                    <http://www.independentid.com/>
                                    
    
                                        phil.hunt@oracle.com
                                    <mailto:phil.hunt@oracle.com>
                                    
    
                                    
    
                                    
    
                                            Begin forwarded message: 
    
                                            *From:*internet-drafts@ietf.org
                                    
    
                                            <mailto:internet-drafts@ietf.org>
                                    
    
                                            *Subject: New Version
                                    Notification for 
    
                                           
                                    draft-hunt-oauth-bound-config-00.txt*
                                    
    
                                            *Date:*March 13, 2016 at
                                    3:53:37 PM PDT 
    
                                            *To:*"Phil Hunt" <phil.hunt@yahoo.com
                                    
    
                                            <mailto:phil.hunt@yahoo.com>>,


                                    "Anthony Nadalin" 
    
                                            <tonynad@microsoft.com
                                    <mailto:tonynad@microsoft.com>>,


                                    
    
                                            "Tony Nadalin" <tonynad@microsoft.com
                                    
    
                                            <mailto:tonynad@microsoft.com>>


                                    
    
                                    
    
                                    
    
                                            A new version of I-D,
                                    draft-hunt-oauth-bound-config-00.txt
                                    
    
                                            has been successfully
                                    submitted by Phil Hunt and posted to
                                    the 
    
                                            IETF repository. 
    
                                    
    
                                           
                                    Name:draft-hunt-oauth-bound-config 
    
                                            Revision:00 
    
                                            Title:OAuth 2.0 Bound
                                    Configuration Lookup 
    
                                            Document date:2016-03-13 
    
                                            Group:Individual Submission
                                    
    
                                            Pages:22 
    
                                            URL: 
    
                                            https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                                            Status: 
    
                                            https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                                    
    
                                            Htmlized: 
    
                                            https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                                    
    
                                    
    
                                    
    
                                            Abstract: 
    
                                              This specification defines
                                    a mechanism for the client of 
    
                                            an OAuth 2.0 
    
                                              protected resource service
                                    to obtain the configuration 
    
                                            details of an 
    
                                              OAuth 2.0 authorization
                                    server that is capable of 
    
                                            authorizing access 
    
                                              to a specific resource
                                    service.  The information 
    
                                            includes the OAuth 
    
                                              2.0 component endpoint
                                    location URIs and as well as 
    
                                            authorization 
    
                                              server capabilities. 
    
                                    
    
                                    
    
                                    
    
                                    
    
                                            Please note that it may take
                                    a couple of minutes from the 
    
                                            time of submission 
    
                                            until the htmlized version
                                    and diff are available 
    
                                            attools.ietf.org <http://tools.ietf.org/>.
                                    
    
                                    
    
                                            The IETF Secretariat 
    
                                    
    
                                       
                                    _______________________________________________
                                    
    
                                        OAuth mailing list 
    
                                        OAuth@ietf.org
                                    <mailto:OAuth@ietf.org>
                                    
    
                                        https://www.ietf.org/mailman/listinfo/oauth
                                    
    
                                  
    
                                  
    
                                
    
                                
    
                              
    
                            
    
                            
    
                            _______________________________________________
                            
    
                            OAuth mailing list 
    
                            OAuth@ietf.org
                            <mailto:OAuth@ietf.org>
                            
    
                            https://www.ietf.org/mailman/listinfo/oauth
                            
    
                          
    
                          
    
                          
    
                          
    
                          _______________________________________________
                          
    
                          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
    
                  
    
                
    
              
    
              
    
            
    
          
    
        
    
      
    
    
    
    
    
  


--------------020308070707030405080302--


From nobody Tue Mar 15 10:23:24 2016
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 0EF1E12DA35 for ; Tue, 15 Mar 2016 10:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 5Rz-_COQC3X2 for ; Tue, 15 Mar 2016 10:23:20 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 0644012D5D3 for ; Tue, 15 Mar 2016 10:23:19 -0700 (PDT)
X-AuditID: 12074423-4bfff700000061cf-41-56e84506d46b
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 55.3F.25039.60548E65; Tue, 15 Mar 2016 13:23:18 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u2FHNHt4012742; Tue, 15 Mar 2016 13:23:18 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2FHNG6T001337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Mar 2016 13:23:17 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_DCD625E5-9C42-4830-861E-ED41B65FF8CB"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: 
Date: Tue, 15 Mar 2016 13:23:15 -0400
Message-Id: <7EF652C2-B3DA-4806-BB81-CFDCE2FB951A@mit.edu>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> 
To: Thomas Broyer 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hTV1mVzfRFm8O+UusXJt6/YLP4ttbc4 /u8iswOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV8eD7JLaCQyEV06c/YWtg3OHWxcjJ ISFgInHr8AnmLkYuDiGBNiaJNxMXMoIkhAQ2MkpM3hECkXjIJPG5q4sZJMEskCCxoHU1C4jN K6An8erWZVYQW1jATWLJ4X1gzWwCqhLT17QwdTFycHAKBEr8/FINEmYBCU+4xQQxJlJi7uN1 zBBjrCTObl/LBLFrIavEvZ0XwWaKCKhJ3Hy3kRHiUlmJ3b8fMU1g5J+F5IxZSM6AiGtLLFv4 mhnC1pTY372cBVNcQ6Lz20TWBYxsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3 MYICnN1FeQfjyz7vQ4wCHIxKPLwzpJ6HCbEmlhVX5h5ilORgUhLl/W3/IkyILyk/pTIjsTgj vqg0J7X4EKMEB7OSCK+oC1CONyWxsiq1KB8mJc3BoiTOy8jAwCAkkJ5YkpqdmlqQWgSTleHg UJLg5QdpFCxKTU+tSMvMKUFIM3FwggznARp+2BlkeHFBYm5xZjpE/hSjopQ4byxIQgAkkVGa B9cLSkAJbw+bvmIUB3pFmPceSBUPMHnBdb8CGswENLgn/BnI4JJEhJRUA6PmIqZiHZHmt/Fl W+8vXBH5bafrlmsXJaat6NjBfIWDrUFSI77x2zeR4Ny/Z53yFne8TajetCT5Z6z/pvR79nMO 3hPl6Zqx2GjJdyOhG31TLnOuLPp9W27VTC0mrm3XVKXW2T+wU89ZK6448VSssPHc76/n3pB6 vn9O3cmHvXYTOY8qX7Y4H7NGiaU4I9FQi7moOBEAOilBiBsDAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:23:23 -0000

--Apple-Mail=_DCD625E5-9C42-4830-861E-ED41B65FF8CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1 to all of this.

Our reasoning for the JWT+introspection was to allow for an RS to take =
in tokens from multiple AS, by looking up the issuer in the JWT itself.

 =E2=80=94 Justin

> On Mar 15, 2016, at 12:34 PM, Thomas Broyer  =
wrote:
>=20
>=20
>=20
> On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin > wrote:
> Hi
>=20
> After following the recent thread on multiple authorization servers, =
but
> also reading some other related threads, I have a question related to
> when the token introspection can be avoided.
>=20
> My understanding has been that given that access tokens are opaque the
> RS does not know anything about its content, hence that was the =
purpose
> of the token introspection spec: provide an interoperable way for RS =
to
> submit a token to AS and get the token data for RS to make a final
> decision about this token.
>=20
> I think if the access tokens are really opaque, i.e, they are =
sequences
> RS can not look into, then having the introspection option is the only
> way to check what the token is really about.
>=20
> But the recent replies with respect to using JWS or JWE tokens have
> confused me.
>=20
> 1. AccessToken as JWS JWT Token:
>=20
> RS can easily look into it, but Justin mentioned that in one case they
> first validate this JWS token and then forward it for some further
> introspection. Why start introspecting if the token has been validated
> and its content is visible ?
>=20
> Because you want to know whether it's been revoked before its =
expiration. Introspection is the only way (unless AS and RS are =
colocated), as only the AS knows.
> =20
> Perhaps because some token data which are sensitive are only visible =
in
> the introspection response ? If yes then why use a self-contained =
token
> if some more external data are associated with it.
>=20
> If the token is not valid (bad issuer, bad signature, expired; or if =
the scopes are included: insufficient scopes), it saves you a request to =
the introspection endpoint ;-)
> Only if the token passes the first checks would you introspect it to =
see if it's still active (not revoked) and possibly retrieve more data =
about it.
> =20
> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of
> times recently, Jonh B. suggested in the other thread the =
introspection
> may not be needed (sorry if I misread it).
> The question here, how can RS deal with a JWE token, it would need to
> share the decrypting key with AS.
>=20
> I think that was the idea yes (didn't someone commented on the thread =
that they deployed JWT tokens with shared secrets or symmetric keys?)
> =20
> So, is introspection needed only for the completely opaque tokens or =
it
> is also needed for JWS and JWE tokens. I'd say it might be reasonable =
to
> skip it in case of JWS, depending on the specific requirements (as the
> expiry, issuer, will be typically set in JWS JWT), while with JWE I =
can
> not see how RS can avoid introspecting unless it shares the
> secret/private key with AS.
>=20
> As Justin mentioned in the other thread: introspection is useful =
(required?) for checking the "liveness" of the token.
>=20
> Side-note: given the size of a JWT compared to some "simpler", opaque =
tokens (mere identifiers), and the fact introspection response are =
likely to be cached for a few minutes by the RS, I wonder if using a JWT =
so you can possibly avoid an introspection request outweights (sic!) the =
bloat of a JWT sent repeatedly over the network (possibly a network with =
high latency, low bandwidth, and sometimes paid based on exchanged =
volumes).
> This is rhetoric actually: I side on the "small token that require =
introspection" until someone comes with a compelling argument to go the =
other way.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_DCD625E5-9C42-4830-861E-ED41B65FF8CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 to all of this.

    Our reasoning for the JWT+introspection was to allow for an =
RS to take in tokens from multiple AS, by looking up the issuer in the =
JWT itself.

     =E2=80=94 Justin

    On =
Mar 15, 2016, at 12:34 PM, Thomas Broyer <t.broyer@gmail.com> =
wrote:



    On Tue, Mar 15, 2016 =
at 2:02 PM Sergey Beryozkin <sberyozkin@gmail.com> wrote:
    Hi
    

    
After following the recent thread on multiple authorization servers, =
but
    
also reading some other related threads, I have a question related to
    
when the token introspection can be avoided.
    

    
My understanding has been that given that access tokens are opaque =
the
    
RS does not know anything about its content, hence that was the =
purpose
    
of the token introspection spec: provide an interoperable way for RS =
to
    
submit a token to AS and get the token data for RS to make a final
    
decision about this token.
    

    
I think if the access tokens are really opaque, i.e, they are =
sequences
    
RS can not look into, then having the introspection option is the =
only
    
way to check what the token is really about.
    

    
But the recent replies with respect to using JWS or JWE tokens have
    
confused me.
    

    
1. AccessToken as JWS JWT Token:
    

    
RS can easily look into it, but Justin mentioned that in one case =
they
    
first validate this JWS token and then forward it for some further
    
introspection. Why start introspecting if the token has been =
validated
    
and its content is visible ?

    Because you want to know =
whether it's been revoked before its expiration. Introspection is the =
only way (unless AS and RS are colocated), as only the AS =
knows.
     
    
Perhaps because some token data which are sensitive are only visible =
in
    
the introspection response ? If yes then why use a self-contained =
token
    
if some more external data are associated with it.

    If the token is not valid (bad issuer, bad signature, =
expired; or if the scopes are included: insufficient scopes), it saves =
you a request to the introspection endpoint ;-)
    Only =
if the token passes the first checks would you introspect it to see if =
it's still active (not revoked) and possibly retrieve more data about =
it.
     
    
2. AccessToken as JWE JWT Token: this option was mentioned a couple =
of
    
times recently, Jonh B. suggested in the other thread the =
introspection
    
may not be needed (sorry if I misread it).
    
The question here, how can RS deal with a JWE token, it would need to
    
share the decrypting key with AS.

    I think that was the =
idea yes (didn't someone commented on the thread that they deployed JWT =
tokens with shared secrets or symmetric keys?)
     
    
So, is introspection needed only for the completely opaque tokens or =
it
    
is also needed for JWS and JWE tokens. I'd say it might be reasonable =
to
    
skip it in case of JWS, depending on the specific requirements (as =
the
    
expiry, issuer, will be typically set in JWS JWT), while with JWE I =
can
    
not see how RS can avoid introspecting unless it shares the
    =

secret/private key with AS.
    As Justin mentioned in the other =
thread: introspection is useful (required?) for checking the "liveness" =
of the token.

    Side-note: given the size of a JWT compared to some =
"simpler", opaque tokens (mere identifiers), and the fact introspection =
response are likely to be cached for a few minutes by the RS, I wonder =
if using a JWT so you can possibly avoid an introspection request =
outweights (sic!) the bloat of a JWT sent repeatedly over the network =
(possibly a network with high latency, low bandwidth, and sometimes paid =
based on exchanged volumes).
    This is rhetoric =
actually: I side on the "small token that require introspection" until =
someone comes with a compelling argument to go the other =
way.
    
_______________________________________________
    OAuth =
mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    =

--Apple-Mail=_DCD625E5-9C42-4830-861E-ED41B65FF8CB--


From nobody Tue Mar 15 10:37:57 2016
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 4EBD312DCB8 for ; Tue, 15 Mar 2016 10:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 1c59DAjiHMDl for ; Tue, 15 Mar 2016 10:37:36 -0700 (PDT)
Received: from omr-m019e.mx.aol.com (omr-m019e.mx.aol.com [204.29.186.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CFC12DC7C for ; Tue, 15 Mar 2016 10:37:36 -0700 (PDT)
Received: from mtaout-aaa02.mx.aol.com (mtaout-aaa02.mx.aol.com [172.27.1.226]) by omr-m019e.mx.aol.com (Outbound Mail Relay) with ESMTP id 653F038000C0; Tue, 15 Mar 2016 13:37:35 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaa02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E5C9C38000087; Tue, 15 Mar 2016 13:37:34 -0400 (EDT)
To: Thomas Broyer , Sergey Beryozkin , oauth@ietf.org
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E8485E.60704@aol.com>
Date: Tue, 15 Mar 2016 13:37:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080602070206070704090303"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458063455; bh=7yqjEq4uDEMQ3DclL+RdRvf8GYtNGIx1L4MYS/K0rQU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=a1M7B+9Mm9XGpE787nS+bzlREc7fvTx7Vcw68aTUNJs7kaFLdhCUN9vnNFoJouS7b tciJSV6ScZ+MQQs55RlEkQ3mUU55LqanXw2toBZrQPax7aWz6ZzwLiIsjRnSPG3Ba2 BSTEpxwobcm8IwcMNRRwquqa6axH6Yymugr0zbcY=
x-aol-sid: 3039ac1b01e256e8485e094f
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:37:38 -0000

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

While I understand the desire for small tokens, we chose JWT as a 
wrapper for the external AS opaque token so that we would have a generic 
implementation that can be expanded to additional partners without 
affecting our implementation.

You could assign each AS in a multiple AS closed environment a unique 
value and then pre/post-fix it to the opaque token so that the RS could 
know where to introspect it. This is still a structured token, just a 
binary representation to save size. There are probably better binary 
ways to do this:)

Thanks,
George

On 3/15/16 12:34 PM, Thomas Broyer wrote:
>
>
> On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin  > wrote:
>
>     Hi
>
>     After following the recent thread on multiple authorization
>     servers, but
>     also reading some other related threads, I have a question related to
>     when the token introspection can be avoided.
>
>     My understanding has been that given that access tokens are opaque the
>     RS does not know anything about its content, hence that was the
>     purpose
>     of the token introspection spec: provide an interoperable way for
>     RS to
>     submit a token to AS and get the token data for RS to make a final
>     decision about this token.
>
>     I think if the access tokens are really opaque, i.e, they are
>     sequences
>     RS can not look into, then having the introspection option is the only
>     way to check what the token is really about.
>
>     But the recent replies with respect to using JWS or JWE tokens have
>     confused me.
>
>     1. AccessToken as JWS JWT Token:
>
>     RS can easily look into it, but Justin mentioned that in one case they
>     first validate this JWS token and then forward it for some further
>     introspection. Why start introspecting if the token has been validated
>     and its content is visible ?
>
>
> Because you want to know whether it's been revoked before its 
> expiration. Introspection is the only way (unless AS and RS are 
> colocated), as only the AS knows.
>
>     Perhaps because some token data which are sensitive are only
>     visible in
>     the introspection response ? If yes then why use a self-contained
>     token
>     if some more external data are associated with it.
>
>
> If the token is not valid (bad issuer, bad signature, expired; or if 
> the scopes are included: insufficient scopes), it saves you a request 
> to the introspection endpoint ;-)
> Only if the token passes the first checks would you introspect it to 
> see if it's still active (not revoked) and possibly retrieve more data 
> about it.
>
>     2. AccessToken as JWE JWT Token: this option was mentioned a couple of
>     times recently, Jonh B. suggested in the other thread the
>     introspection
>     may not be needed (sorry if I misread it).
>     The question here, how can RS deal with a JWE token, it would need to
>     share the decrypting key with AS.
>
>
> I think that was the idea yes (didn't someone commented on the thread 
> that they deployed JWT tokens with shared secrets or symmetric keys?)
>
>     So, is introspection needed only for the completely opaque tokens
>     or it
>     is also needed for JWS and JWE tokens. I'd say it might be
>     reasonable to
>     skip it in case of JWS, depending on the specific requirements (as the
>     expiry, issuer, will be typically set in JWS JWT), while with JWE
>     I can
>     not see how RS can avoid introspecting unless it shares the
>     secret/private key with AS.
>
>
> As Justin mentioned in the other thread: introspection is useful 
> (required?) for checking the "liveness" of the token.
>
> Side-note: given the size of a JWT compared to some "simpler", opaque 
> tokens (mere identifiers), and the fact introspection response are 
> likely to be cached for a few minutes by the RS, I wonder if using a 
> JWT so you can possibly avoid an introspection request outweights 
> (sic!) the bloat of a JWT sent repeatedly over the network (possibly a 
> network with high latency, low bandwidth, and sometimes paid based on 
> exchanged volumes).
> This is rhetoric actually: I side on the "small token that require 
> introspection" until someone comes with a compelling argument to go 
> the other way.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    While I understand the
      desire for small tokens, we chose JWT as a wrapper for the
      external AS opaque token so that we would have a generic
      implementation that can be expanded to additional partners without
      affecting our implementation.
    
      
    
      You could assign each AS in a multiple AS closed environment a
      unique value and then pre/post-fix it to the opaque token so that
      the RS could know where to introspect it. This is still a
      structured token, just a binary representation to save size. There
      are probably better binary ways to do this:)
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/15/16 12:34 PM, Thomas Broyer
      wrote:
    
    
    
    
    
      

    
        
    
        
    
          
    On Tue, Mar 15, 2016 at 2:02 PM Sergey
            Beryozkin <sberyozkin@gmail.com>
            wrote:
    
          
    
          
    Hi
    
            
    
            After following the recent thread on multiple authorization
            servers, but
    
            also reading some other related threads, I have a question
            related to
    
            when the token introspection can be avoided.
    
            
    
            My understanding has been that given that access tokens are
            opaque the
    
            RS does not know anything about its content, hence that was
            the purpose
    
            of the token introspection spec: provide an interoperable
            way for RS to
    
            submit a token to AS and get the token data for RS to make a
            final
    
            decision about this token.
    
            
    
            I think if the access tokens are really opaque, i.e, they
            are sequences
    
            RS can not look into, then having the introspection option
            is the only
    
            way to check what the token is really about.
    
            
    
            But the recent replies with respect to using JWS or JWE
            tokens have
    
            confused me.
    
            
    
            1. AccessToken as JWS JWT Token:
    
            
    
            RS can easily look into it, but Justin mentioned that in one
            case they
    
            first validate this JWS token and then forward it for some
            further
    
            introspection. Why start introspecting if the token has been
            validated
    
            and its content is visible ?
    
          
    
          

    
          
    
          
    Because you want to know whether it's been revoked before
            its expiration. Introspection is the only way (unless AS and
            RS are colocated), as only the AS knows.
    
          
     
    
          
    
            Perhaps because some token data which are sensitive are only
            visible in
    
            the introspection response ? If yes then why use a
            self-contained token
    
            if some more external data are associated with it.
    
          
    
          

    
          
    
          
    If the token is not valid (bad issuer, bad signature,
            expired; or if the scopes are included: insufficient
            scopes), it saves you a request to the introspection
            endpoint ;-)
    
          
    Only if the token passes the first checks would you
            introspect it to see if it's still active (not revoked) and
            possibly retrieve more data about it.
    
          
     
    
          
    
            2. AccessToken as JWE JWT Token: this option was mentioned a
            couple of
    
            times recently, Jonh B. suggested in the other thread the
            introspection
    
            may not be needed (sorry if I misread it).
    
            The question here, how can RS deal with a JWE token, it
            would need to
    
            share the decrypting key with AS.
    
          
    
          

    
          
    
          
    I think that was the idea yes (didn't someone commented
            on the thread that they deployed JWT tokens with shared
            secrets or symmetric keys?)
    
          
     
    
          
    
            So, is introspection needed only for the completely opaque
            tokens or it
    
            is also needed for JWS and JWE tokens. I'd say it might be
            reasonable to
    
            skip it in case of JWS, depending on the specific
            requirements (as the
    
            expiry, issuer, will be typically set in JWS JWT), while
            with JWE I can
    
            not see how RS can avoid introspecting unless it shares the
    
            secret/private key with AS.
    
          
    
          

    
          
    
          
    As Justin mentioned in the other thread: introspection is
            useful (required?) for checking the "liveness" of the token.
    
          

    
          
    
          
    Side-note: given the size of a JWT compared to some
            "simpler", opaque tokens (mere identifiers), and the fact
            introspection response are likely to be cached for a few
            minutes by the RS, I wonder if using a JWT so you can
            possibly avoid an introspection request outweights (sic!)
            the bloat of a JWT sent repeatedly over the network
            (possibly a network with high latency, low bandwidth, and
            sometimes paid based on exchanged volumes).
    
          
    This is rhetoric actually: I side on the "small token
            that require introspection" until someone comes with a
            compelling argument to go the other way.
    
        
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  


--------------080602070206070704090303--


From nobody Tue Mar 15 10:38:28 2016
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 4149312DCB5 for ; Tue, 15 Mar 2016 10:38:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 AyRrKOaIZMds for ; Tue, 15 Mar 2016 10:37:57 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 6EF1712DBE4 for ; Tue, 15 Mar 2016 10:37:48 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id s68so10049058qkh.3 for ; Tue, 15 Mar 2016 10:37:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=6Cq6JLmrKIJqrvBknqMxGY69EtVwOsevBheKuKt9TSQ=; b=yt7ePkfgIJdEAhxPmZHx27zlZVwMppQHOgkNeKg2eTmIjICRORnAIdU5eziKxeLP1z kPcF1L5ONUukdvKhNbGtVdt7lCFNAFFCoyzN1IPtayH6IOu4O7FQVPEaa0ejyqkzE6dM tawWcLTPykKKjix3Yo4TW49xAi9CB66Gdjr28R5Ijo+9ERwvnt6j4wivb+OYPXBB/1dy Ge7kNchlj3WVBJvGGpxGqd6EWMsUap3WC97NOroqpWAuq8zkOm7MuTFsddeJl++0KUcG N0To0mj0RMtcSdwdSw6+bfgbn0n0VFLy9M5TQWNfhnFYWfsQS3EMACmclz6ii+/ydnpJ LTlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6Cq6JLmrKIJqrvBknqMxGY69EtVwOsevBheKuKt9TSQ=; b=RgroNhyw2TaDVJxVFSaNpWBHAd+dkvfFnsiLGXfg82kIUo2UALne8m/kamTqYLEhf1 /JljlA1wshNu3sIbaZUs3TCilJhb+ccRqPpr8iFXnIkV/Bqx0U0QxaLsL/cIJS9107Qo AKUHU0nHZWnttC5zZE4Qn0oYr/w8+BgfLpPSbRVUfUheTAEgXg8TGz6AidQ6K7kplT0Y UKgABLXCVnYsenPDUkHCwaaFP5b6VCf3pA+n070IoUAucFJxEYkhOZnMKV3ju7ZfFwYS iJ8GFxz1jlt/dvOw/TJYfnb8NdH+XXA3FR9JhITgLY4f4pYTajgkzHHMmV7DF9GBIgdV NRnw==
X-Gm-Message-State: AD7BkJIn/9A5qGEXTCdXtwyX+nURQnZzeHRCAgw6vBHEOVHQM7wsj/BuLqweGifRqhJXMA==
X-Received: by 10.55.73.85 with SMTP id w82mr40199817qka.52.1458063467382; Tue, 15 Mar 2016 10:37:47 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.31.112]) by smtp.gmail.com with ESMTPSA id x136sm13183049qka.0.2016.03.15.10.37.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 10:37:45 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_DD69A19F-1184-4A59-9B86-04DCF8E8C38B"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 15 Mar 2016 14:37:41 -0300
Message-Id: <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com> 
To: Brian Campbell 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:38:26 -0000

--Apple-Mail=_DD69A19F-1184-4A59-9B86-04DCF8E8C38B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_682EF410-A1A2-4829-A8FB-0B6FDFBFBEF8"


--Apple-Mail=_682EF410-A1A2-4829-A8FB-0B6FDFBFBEF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If the client specifies the resource it wants the token for, then the =
meta-data would not be required unless the resources the token is good =
at are different from the request. =20
Lat is the same logic as scopes.

For backwards compatibility if the client is happy with the default =
resources based on scopes then I think it is a good idea to tell the =
client what the resources are in the response.

I suspect that it is simpler with less optionality and always return the =
resources, even if they are not required.

John B.

> On Mar 15, 2016, at 12:46 PM, Brian Campbell =
 wrote:
>=20
> If the client specifies the desired audience(s)/resource(s), is that =
metadata to the client needed? The AS can audience restrict the token as =
needed or respond with an error if it can't or wont issue a token for =
the resource the client asked for.=20
>=20
> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley > wrote:
> Yes,  I think bearer tokens with no audience are a bad idea.
>=20
> The AS needs to infer an audience from the scopes snd/or have the =
client specify the desired audience.
>=20
> If the AT has a audience or audiences then as long as the endpoint URI =
are provided as meta-data with the token, the client can determine if it =
is sending the token to the correct place.
>=20
> I think Phil would prefer the server rather than the client do the =
check, but the client always needs to take some responsibility to not =
leak tokens giving them to the wrong RS or the code to the wrong token =
endpoint is leaking.
>=20
> I imagine that claims based access tokens are going to become more =
popular and the static relationship between one RS and one AS will not =
be the majority of deployments over time.=20
>=20
> In any case where the client is configured up front to know the RS and =
the AS it seems like that would not require Phil=E2=80=99s Solution, but =
that is the only case supported by that discovery.
>  =20
> If the client itself is bad there is not much you can do to stop it =
from passing on the AT in way way it wants.  That however is a different =
problem and needs claimed URI or attestations to prevent client =
spoofing.
> William and I are working on that in the mobile best practices draft.
>=20
> John B.
>=20
>=20
>> On Mar 15, 2016, at 12:09 PM, George Fletcher > wrote:
>>=20
>> I worry about two directions I see in this thread...
>>=20
>> 1. Client's accessing resources dynamically so that discovery is =
required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>>=20
>> 2. Creating a tight coupling between RS and AS such that RS endpoint =
changes must be continually communicated to the AS. If an RS supports =
multiple AS's then the RS has to deal with "guaranteed" delivery. The AS =
needs an endpoint to receive such communications. If not dynamic via =
APIs, then deployment of the new RS is bound by the associated AS's =
getting and deploying the new endpoints. Can both endpoints of the RS be =
supported within the AS for some period of time, etc. This is an =
operation nightmare and almost assuredly going to go wrong in =
production.
>>=20
>> Maybe an OAuth2 "audience binding" spec is what's needed for those =
deployments that require this. I believe that is what John Bradley is =
suggesting.
>>=20
>> Thanks,
>> George
>>=20
>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>> +1, I've found the very same in OAuth deployments that I was =
involved in; the hard part is to give names and descriptions to these =
concepts so that they cover all use cases and can be applied =
unambiguously=20
>>>=20
>>> Hans.=20
>>>=20
>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>> I agree that this is valuable, and not just for PoP. In all =
honesty,=20
>>>> it=E2=80=99s not even really required for PoP to function in many =
cases =E2=80=94 it=E2=80=99s=20
>>>> just an optimization for one particular kind of key distribution=20
>>>> mechanism in that case.=20
>>>>=20
>>>> In the years of deployment experience with OAuth 2, I think we=E2=80=99=
ve really=20
>>>> got three different kinds of things that currently get folded into=20=

>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:=20
>>>>=20
>>>>=20
>>>>   - What things do I want to access? (photos, profile)=20
>>>>   - What actions do I want to take on these things? (read, write, =
delete)=20
>>>>   - How long do I want these tokens to work?=20
>>>> (offline_access/refresh_token, one time use, next hour, etc)=20
>>>>=20
>>>>=20
>>>> I think the first one is close to the audience/resource parameters =
that=20
>>>> have been bandied about a few times, including in the current token=20=

>>>> exchange document. We should be consistent across drafts in that =
regard.=20
>>>> The second is more traditional scope-ish. The third has been =
patched in=20
>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.=20=

>>>>=20
>>>> Just another vector to think about if we=E2=80=99re going to be =
adding things=20
>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.=20
>>>>=20
>>>>   =E2=80=94 Justin=20
>>>>=20
>>>>=20
>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley =20
>>>>>  > wrote:=20
>>>>>=20
>>>>> Yes I will work on another proposal for allowing clients to =
specify=20
>>>>> what resource they want a token for and providing the meta-data to =
the=20
>>>>> client about the resources that a token is valid for.=20
>>>>>=20
>>>>> We have part of it in the POP key distribution spec and talked =
about=20
>>>>> separating it, as it is used more places than just for assigning =
keys.=20
>>>>> I know some AS use different token formats for different RS so are=20=

>>>>> all-ready needing to pass the resource in the request to avoid =
making=20
>>>>> a mess of scopes.=20
>>>>>=20
>>>>> John B.=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) =
=20
>>>>>>  > =
wrote:=20
>>>>>>=20
>>>>>> Inline=20
>>>>>>=20
>>>>>> Phil=20
>>>>>>=20
>>>>>> On Mar 14, 2016, at 14:13, John Bradley =20
>>>>>>  > wrote:=20
>>>>>>=20
>>>>>>> We had two mandates.  One was to provide a spec for AS metadata.=20=

>>>>>>> The other was to mitigate the client mixup attack.  The request =
was=20
>>>>>>> to do the latter without requiring the former for clients that =
don=E2=80=99t=20
>>>>>>> otherwise need discovery.=20
>>>>>> There is no mandate for any of this. See=20
>>>>>> =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =
=20
>>>>>>>=20
>>>>>>> Returning the issuer and client_id from the authorization =
endpoint=20
>>>>>>> and the client checking them can be done by the client without=20=

>>>>>>> discovery.=20
>>>>>>=20
>>>>>> How does this address the issue of whether the client is talking =
to=20
>>>>>> the wrong endpoint?=20
>>>>>>>=20
>>>>>>> Any client that has the resource and issuer hard coded probably=20=

>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>> We agree=20
>>>>>>=20
>>>>>>=20
>>>>>>> One of the things that a client will need discovery for is to =
find=20
>>>>>>> the RS, so requiring the client to know the RS URI before =
getting=20
>>>>>>> the AS config seems backwards to me.=20
>>>>>> How can you make an assumption on order? You seem to be =
conflating=20
>>>>>> authentication with authorization by assuming the identity drives=20=

>>>>>> what the resource is.=20
>>>>>>=20
>>>>>> There are lots of applications that require user rights but are =
not=20
>>>>>> identify centric. For example a document service.=20
>>>>>>>=20
>>>>>>> Unless the client tells the AS where it intends to use the token =
we=20
>>>>>>> will be leaving a security hole because the bearer tokens will =
have=20
>>>>>>> too loose an audience if they have one at all.=20
>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>=20
>>>>>>> True you are telling the AS (Webfinger service) what the RS is =
but=20
>>>>>>> that is not at a place that is useful in the token production =
process.=20
>>>>>>=20
>>>>>> This has nothing to do with token production.=20
>>>>>>=20
>>>>>> What we want to ensure is whether an honest client is correctly=20=

>>>>>> configured and has not been mislead - eg by a phishing page.=20
>>>>>>>=20
>>>>>>> I also think there are use cases where the AS doesn=E2=80=99t =
know all the=20
>>>>>>> possible RS.   That is not something that a out of band check =
can=20
>>>>>>> address.=20
>>>>>>=20
>>>>>> May be. Lets identify them.=20
>>>>>>=20
>>>>>>> There are also cases where a token might be good at multiple RS=20=

>>>>>>> endpoints intentionally.=20
>>>>>>=20
>>>>>>>  In your solution the client would need to make a discovery =
request=20
>>>>>>> for each endpoint.=20
>>>>>> Sure. Otherwise how would it know if there is one AS or a pool of =
AS=20
>>>>>> servers assigned to each instance?=20
>>>>>>> Those requests lack the context of who the client and resource =
owner=20
>>>>>>> are.  I think that will be a problem in some use cases.=20
>>>>>>=20
>>>>>> Not sure I agree. This is about discovering a valid set of =
endpoints.=20
>>>>>> For mitm, we mainly want to check the hostname is correct. If a=20=

>>>>>> client chooses evil.com   =
 the cert can be valid and=20
>>>>>> TLS will pass. How does it otherwise know it is supposed to talk =
to=20
>>>>>> res.example.com  =
 ?=20
>>>>>>>=20
>>>>>>> If this is added to the token endpoint it would be checked when =
code=20
>>>>>>> or refresh are exchanged, not every time the token is used.=20
>>>>>> Your proposal requires rhe client to check. I am not clear how =
the AS=20
>>>>>> can know the exact uri. It is far easier to validate than to =
lookup=20
>>>>>> since as you say the client may be authorized to use multiple =
ASs.=20
>>>>>>> With a out of band check the client would never know if a RS was=20=

>>>>>>> removed/revoked.=20
>>>>>>=20
>>>>>> Not sure that is in scope.=20
>>>>>>=20
>>>>>> None of the current proposals address this issue.=20
>>>>>>>=20
>>>>>>> I don=E2=80=99t see checking when refreshing a token as =
something that is a=20
>>>>>>> huge burden.=20
>>>>>>=20
>>>>>> Still its a lot more than once.=20
>>>>>>=20
>>>>>> Why don't you draft another alternative?=20
>>>>>>>=20
>>>>>>> If the server wants to do the check on it=E2=80=99s side then we =
could=20
>>>>>>> require the client to send the RS URI in the token request. that =
way=20
>>>>>>> you really know the client is not going to get a token for the =
wrong=20
>>>>>>> RS endpoint.=20
>>>>>>> If you check out of band in discovery you really have no idea if =
the=20
>>>>>>> client is checking.=20
>>>>>>=20
>>>>>> In the new webfinger draft, the client isn't checking. The =
service=20
>>>>>> provider simply does not disclose oauth information to =
misconfigured=20
>>>>>> clients.=20
>>>>>>>=20
>>>>>>> John B.=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt =20
>>>>>>>>  > =
wrote:=20
>>>>>>>>=20
>>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take =
each in turn:=20
>>>>>>>>=20
>>>>>>>> Mike,=20
>>>>>>>>=20
>>>>>>>> Regarding your suggested amendments=20
>>>>>>>>=20
>>>>>>>> Item 1: Returning the config URL would create two problems. =
One,it=20
>>>>>>>> makes bound discovery a two-step process - that adds =
complexity.=20
>>>>>>>>  It seems far simpler to mandate TLS (which I think it already =
does=20
>>>>>>>> in the security considerations).=20
>>>>>>>>=20
>>>>>>>> The two-step process allows the current discovery process to=20
>>>>>>>> continue. I disagree with this. This is why I put forward an=20
>>>>>>>> =E2=80=9Calternate" draft that is almost the same but simply =
adds the check=20
>>>>>>>> before returning the configuration data.  I worry that  =
developers=20
>>>>>>>> would have no incentive to do the two-step approach. They would=20=

>>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at risk of =
exposing=20
>>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>>=20
>>>>>>>> Regarding existing implementations. Most of those =
implementations=20
>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use =
of=20
>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well =
defined=20
>>>>>>>> and the likelihood of a client mis-informed about the resource=20=

>>>>>>>> endpoint is not there.  IMO This does not apply to the broader=20=

>>>>>>>> OAuth community.=20
>>>>>>>>=20
>>>>>>>> Item 2:  It may be appropriate to have a separate configuration=20=

>>>>>>>> registry specification, but I think we should hold off until we=20=

>>>>>>>> have a complete solution and then make the decision what drafts=20=

>>>>>>>> should exist and how many pieces.  A big concern is the =
perceived=20
>>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>>=20
>>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>>=20
>>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a =
security threat=20
>>>>>>>> by having a discovery specification to prevent clients being=20
>>>>>>>> mis-lead about endpoints (of which resource service is one) in =
an=20
>>>>>>>> oauth protected exchange.  Maybe what you mean is we should not =
use=20
>>>>>>>> .well-known of any kind and we should just create a =
=E2=80=9C/Config=E2=80=9D=20
>>>>>>>> endpoint to OAuth?=20
>>>>>>>>=20
>>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>>> You propose that instead the resource endpoint check should be =
in=20
>>>>>>>> the oauth protocol itself.  The difference is that validation =
is=20
>>>>>>>> transferred back to the client to get it right. As well, =
without=20
>>>>>>>> the client informing the AS, I can=E2=80=99t see a way for the =
AS to know=20
>>>>>>>> what endpoint the client is using.  The webfinger approach does=20=

>>>>>>>> this once and only requires that the host name be checked in =
many=20
>>>>>>>> cases.=20
>>>>>>>>=20
>>>>>>>> As a principle, the members have discussed many times that the =
AS=20
>>>>>>>> service should do validation when possible =E2=80=94 this was =
particularly=20
>>>>>>>> true at the Germany meeting when this came up. This is why I =
prefer=20
>>>>>>>> the client tell the service provider what it intends to do and =
the=20
>>>>>>>> service provider can fail that request immediately if =
necessary. We=20
>>>>>>>> don=E2=80=99t have to depend on the developer getting the spec =
correct to=20
>>>>>>>> fail the correct way.=20
>>>>>>>>=20
>>>>>>>> I worry that adding more parameters to the authz and token =
protocol=20
>>>>>>>> flows increases complexity and attack surface. It also means =
per=20
>>>>>>>> authorization validation has to take place vs. a one-time=20
>>>>>>>> validation at config time.  Placing it in the configuration =
lookup=20
>>>>>>>> phase (whether via web finger or just a special OAuth endpoint)=20=

>>>>>>>> seems more appropriate and far less complex - as the request =
itself=20
>>>>>>>> is simple and has only one parameter. Here we are not =
considered=20
>>>>>>>> about legitimacy of the client. we=E2=80=99re just concerned =
with the issue=20
>>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>>=20
>>>>>>>> That said, it may be that when we consider all the use cases, =
some=20
>>>>>>>> combination of AS protocol and discovery may be both needed. =
I=E2=80=99m=20
>>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>>> oauth-discovery spec seems to put future generic clients at =
risk=20
>>>>>>>> and that is my primary concern.=20
>>>>>>>>=20
>>>>>>>> Best Regards,=20
>>>>>>>>=20
>>>>>>>> Phil=20
>>>>>>>>=20
>>>>>>>> @independentid=20
>>>>>>>> www.independentid.com  =
 =20
>>>>>>>> phil.hunt@oracle.com  =
 =20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>>  =
 =
>=20
>>>>>>>>> wrote:=20
>>>>>>>>>=20
>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete example =
of=20
>>>>>>>>> a way that protected resource discovery could be added to=20
>>>>>>>>> authorization server metadata discovery, and as such, should=20=

>>>>>>>>> provide useful input for working group discussions on this =
topic.=20
>>>>>>>>> It=E2=80=99s always great when someone takes the time to write =
an actual=20
>>>>>>>>> draft that can be examined and implemented, and I appreciate =
you=20
>>>>>>>>> doing that.=20
>>>>>>>>> The content of your draft points out that there appears to be=20=

>>>>>>>>> complete agreement on what the authorization server metadata=20=

>>>>>>>>> format should be, which is great!  I=E2=80=99ll note that =
Section 3 of=20
>>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization =
Server=20
>>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo=20
>>>>>>>>> applying a correction suggested by the working group.  To me =
this=20
>>>>>>>>> suggests that the authorization server metadata definitions in=20=

>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative=20=

>>>>>>>>> content of the draft) are clearly ready for standardization, =
since=20
>>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>>> Reading your draft, the problem I have with it is that you are=20=

>>>>>>>>> returning the AS metadata only as a WebFinger response, rather=20=

>>>>>>>>> than as an https-protected resource published by the =
authorization=20
>>>>>>>>> server.  The choice to only return this via WebFinger makes =
your=20
>>>>>>>>> draft incompatible with most deployed implementations of OAuth=20=

>>>>>>>>> metadata, including the 22 implementations using it listed=20
>>>>>>>>> athttp://openid.net/certification/ <>(see the =E2=80=9COP =
Config=E2=80=9D column in=20
>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D=20
>>>>>>>>> library, which uses the metadata path for client =
configuration.=20
>>>>>>>>> Without having ASs provide the metadata as an https-protected=20=

>>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use it =
for client=20
>>>>>>>>> configuration as the currently do.=20
>>>>>>>>> Therefore, I would request that you make these minor revisions =
to=20
>>>>>>>>> your draft and republish, so as to provide a unified way =
forward=20
>>>>>>>>> that is compatible with all known existing OAuth Discovery=20
>>>>>>>>> deployments:=20
>>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D=20
>>>>>>>>> to have the WebFinger request return the issuer identifier for =
the=20
>>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, =
rather than returning the=20
>>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D =
value.=20
>>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in =
your=20
>>>>>>>>> Section 3.=20
>>>>>>>>> That would have the advantage of paring your draft down to =
only=20
>>>>>>>>> the new things that it proposes, enabling them to be more =
clearly=20
>>>>>>>>> understood and evaluated on their own merits.  I look forward =
to=20
>>>>>>>>> the discussions of ways of performing additional kinds of =
OAuth=20
>>>>>>>>> discovery, and consider your draft a valuable input to those=20=

>>>>>>>>> discussions.=20
>>>>>>>>>                                                           Best =
wishes,=20
>>>>>>>>>                                                           -- =
Mike=20
>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org =
]*On Behalf Of*John Bradley=20
>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>>> *To:*Phil Hunt   =
>=20
>>>>>>>>> *Cc:*oauth  =
 >=20
>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>> As I have told Phil off list.=20
>>>>>>>>> Discovery is the wrong place to try and provide security =
against=20
>>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>>> This requires the client to know what the RS URI is before=20
>>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>>> The proposal Mike and I have been working on requires the =
client=20
>>>>>>>>> to have a notion of what API it is looking for and retrieve =
the=20
>>>>>>>>> .well-known file for that API from the issuer.   That allows a=20=

>>>>>>>>> protocol like Connect to register its own config file that can=20=

>>>>>>>>> point to the RS.=20
>>>>>>>>> If the API specific well known is not available the client can =
try=20
>>>>>>>>> the default oauth-server one.=20
>>>>>>>>> That then allows us to deal with restricting where AT are=20
>>>>>>>>> presented as part of the protocol rather then dragging =
discovery=20
>>>>>>>>> in as a requirement.=20
>>>>>>>>> In my opinion the resource the token is targeted to should be=20=

>>>>>>>>> separated from the scope and returned as part of the meta-data=20=

>>>>>>>>> about the AT along with scopes granted and expiry time.   We=20=

>>>>>>>>> should also have a input parameter for resources so that a =
client=20
>>>>>>>>> can restrict tokens issued to a subset of the ones granted by =
the=20
>>>>>>>>> refresh token.   It would then also be possible to ask a AS =
for a=20
>>>>>>>>> token for a unregistered RS and have the AS produce a JWT =
access=20
>>>>>>>>> token with the resource as an audience if policy allows.=20
>>>>>>>>> That however was supposed to be dealt with as part of the =
mixed up=20
>>>>>>>>> client set of mitigations.=20
>>>>>>>>> In that the goal was to mitigate the attacks by returning=20
>>>>>>>>> meta-data about the tokens, and not to require discovery.=20
>>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=
=E2=80=9D for the code, and I=20
>>>>>>>>> intend to discuss at the F2F returning resource for AT as =
well.=20
>>>>>>>>> Those mitigate the attack.=20
>>>>>>>>> I will continue to resist mixing up discovery of configuration=20=

>>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>>> We return meta-data about the tokens now, because AT are =
opaque to=20
>>>>>>>>> the client, we neglected to include some of the information =
for=20
>>>>>>>>> the client needs to be secure.   We just need to add that in =
to=20
>>>>>>>>> the existing flows.=20
>>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add=20
>>>>>>>>> on, it puts more of a burden on the client needing to =
potentially=20
>>>>>>>>> change how it stores the relationships between AS and RS to=20
>>>>>>>>> prevent compromise, I think the solution should be biased =
towards=20
>>>>>>>>> simplicity on the client side.=20
>>>>>>>>> If we return the resources as part of the existing meta data =
the=20
>>>>>>>>> client checks that against the resource it intends to send the=20=

>>>>>>>>> token to and if it is not in the list then it can=E2=80=99t =
send the=20
>>>>>>>>> token.  Simple check every time it gets a new AT, no =
optionality.=20
>>>>>>>>> I am not saying anything new Nat has been advocating basically=20=

>>>>>>>>> this for some time, and dis submit a draft.   I prefer to =
return=20
>>>>>>>>> the info in the existing format rather than as link headers,  =
but=20
>>>>>>>>> that is the largest difference between what Nat and I are =
saying=20
>>>>>>>>> with respect to resource.=20
>>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20
>>>>>>>>> I guess we will need to have a long conversation in BA.=20
>>>>>>>>> Regards=20
>>>>>>>>> John B.=20
>>>>>>>>>=20
>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt =
=20
>>>>>>>>>      =
> wrote:=20
>>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same=20=

>>>>>>>>>     registry for OAuth Config Metadata as the authors believe =
that=20
>>>>>>>>>     both solutions are not required, or depending on WG =
discussion=20
>>>>>>>>>     they will be merged. The intent is to provide a simple=20
>>>>>>>>>     complete draft for consideration.=20
>>>>>>>>>     How it works...=20
>>>>>>>>>     Given that a client has previously discovered an OAuth=20
>>>>>>>>>     protected resource, the bound configuration method allows =
a=20
>>>>>>>>>     client to return the configuration for an oauth =
authorization=20
>>>>>>>>>     server that can issue tokens for the resource URI =
specified by=20
>>>>>>>>>     the client.  The AS is not required to be in the same =
domain.=20
>>>>>>>>>      The AS is however required to know if it can issue tokens =
for=20
>>>>>>>>>     a resource service (which presumes some agreement exists =
on=20
>>>>>>>>>     tokens etc).=20
>>>>>>>>>     The draft does not require that the resource exist (e.g. =
for=20
>>>>>>>>>     unconfigured or new user based resources). It only =
requires=20
>>>>>>>>>     that the AS service provider agrees it can issue tokens.=20=

>>>>>>>>>     =46rom a security perspective, returning the OAuth service=20=

>>>>>>>>>     configuration for a specified resource URI serves to =
confirm=20
>>>>>>>>>     the client is in possession of a valid resource URI =
ensuring=20
>>>>>>>>>     the client has received a valid set of endpoints for the=20=

>>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>>     I propose that the WG consider the alternate draft =
carefully=20
>>>>>>>>>     as well as other submissions and evaluate the broader=20
>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth =
Discovery.=20
>>>>>>>>>     Thanks!=20
>>>>>>>>>     Phil=20
>>>>>>>>>     @independentid=20
>>>>>>>>>     www.independentid.com  =
 =20
>>>>>>>>>     phil.hunt@oracle.com  =
 =20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>         Begin forwarded message:=20
>>>>>>>>>         *From:*internet-drafts@ietf.org =
=20
>>>>>>>>>          =
=20
>>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>>         *To:*"Phil Hunt" =20
>>>>>>>>>          =
>, "Anthony Nadalin"=20
>>>>>>>>>          =
 >,=20
>>>>>>>>>         "Tony Nadalin" =20
>>>>>>>>>          =
>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>         A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>         has been successfully submitted by Phil Hunt and =
posted to the=20
>>>>>>>>>         IETF repository.=20
>>>>>>>>>=20
>>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>>         Revision:00=20
>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>>         Group:Individual Submission=20
>>>>>>>>>         Pages:22=20
>>>>>>>>>         URL:=20
>>>>>>>>>         =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>>>>>>>         Status:=20
>>>>>>>>>         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =
=20
>>>>>>>>>         Htmlized:=20
>>>>>>>>>         =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =
=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>         Abstract:=20
>>>>>>>>>           This specification defines a mechanism for the =
client of=20
>>>>>>>>>         an OAuth 2.0=20
>>>>>>>>>           protected resource service to obtain the =
configuration=20
>>>>>>>>>         details of an=20
>>>>>>>>>           OAuth 2.0 authorization server that is capable of=20
>>>>>>>>>         authorizing access=20
>>>>>>>>>           to a specific resource service.  The information=20
>>>>>>>>>         includes the OAuth=20
>>>>>>>>>           2.0 component endpoint location URIs and as well as=20=

>>>>>>>>>         authorization=20
>>>>>>>>>           server capabilities.=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>         Please note that it may take a couple of minutes from =
the=20
>>>>>>>>>         time of submission=20
>>>>>>>>>         until the htmlized version and diff are available=20
>>>>>>>>>         attools.ietf.org  =
 .=20
>>>>>>>>>=20
>>>>>>>>>         The IETF Secretariat=20
>>>>>>>>>=20
>>>>>>>>>     _______________________________________________=20
>>>>>>>>>     OAuth mailing list=20
>>>>>>>>>     OAuth@ietf.org  =
 =20
>>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>>>>=20
>>>>>>>=20
>>>>>=20
>>>>> _______________________________________________=20
>>>>> OAuth mailing list=20
>>>>> OAuth@ietf.org   =
=20
>>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________=20
>>>> OAuth mailing list=20
>>>> OAuth@ietf.org =20
>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>=20
>>>=20
>>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

>=20
>=20


--Apple-Mail=_682EF410-A1A2-4829-A8FB-0B6FDFBFBEF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

If the client specifies the resource it wants the token for, =
then the meta-data would not be required unless the resources the token =
is good at are different from the request.  
    Lat is =
the same logic as scopes.

    For backwards compatibility if the client is happy with the =
default resources based on scopes then I think it is a good idea to tell =
the client what the resources are in the response.

    I suspect that it is =
simpler with less optionality and always return the resources, even if =
they are not required.

    John B.

    On =
Mar 15, 2016, at 12:46 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

    If the client specifies the desired audience(s)/resource(s), =
is that metadata to the client needed? The AS can audience restrict the =
token as needed or respond with an error if it can't or wont issue a =
token for the resource the client asked for. 

    On Tue, Mar 15, 2016 at 9:37 AM, John Bradley =
<ve7jtb@ve7jtb.com> wrote:
    Yes,  I think bearer =
tokens with no audience are a bad idea.

    The AS needs to infer an audience from =
the scopes snd/or have the client specify the desired =
audience.

    If =
the AT has a audience or audiences then as long as the endpoint URI are =
provided as meta-data with the token, the client can determine if it is =
sending the token to the correct place.

    I think Phil would prefer the server =
rather than the client do the check, but the client always needs to take =
some responsibility to not leak tokens giving them to the wrong RS or =
the code to the wrong token endpoint is leaking.

    I imagine that claims based access =
tokens are going to become more popular and the static relationship =
between one RS and one AS will not be the majority of deployments over =
time. 

    In =
any case where the client is configured up front to know the RS and the =
AS it seems like that would not require Phil=E2=80=99s Solution, but =
that is the only case supported by that discovery.
      
    If the client itself is bad =
there is not much you can do to stop it from passing on the AT in way =
way it wants.  That however is a different problem and needs =
claimed URI or attestations to prevent client spoofing.
    William and I are working on that in the mobile best =
practices draft.

    John B.


    On Mar 15, 2016, at 12:09 PM, George Fletcher =
<gffletch@aol.com> wrote:

    
 =20
   =20
 =20
  
    
    I worry about =
two
      directions I see in this thread...
    
      
    
      1. Client's accessing resources dynamically so that discovery is
      required to know the correct AS, etc. This is pretty much the
      classic use case for UMA and I'd rather not re-invent the =
wheel.
    
      
    
      2. Creating a tight coupling between RS and AS such that RS
      endpoint changes must be continually communicated to the AS. If an
      RS supports multiple AS's then the RS has to deal with
      "guaranteed" delivery. The AS needs an endpoint to receive such
      communications. If not dynamic via APIs, then deployment of the
      new RS is bound by the associated AS's getting and deploying the
      new endpoints. Can both endpoints of the RS be supported within
      the AS for some period of time, etc. This is an operation
      nightmare and almost assuredly going to go wrong in production.
    
      
    
      Maybe an OAuth2 "audience binding" spec is what's needed for those
      deployments that require this. I believe that is what John Bradley
      is suggesting.
    
      
    
      Thanks,
    
      George
    
    

    
    
    On 3/14/16 7:29 PM, Hans Zandbelt
      wrote:
    
    
    
    
    +1,
      I've found the very same in OAuth deployments that I was involved
      in; the hard part is to give names and descriptions to these
      concepts so that they cover all use cases and can be applied
      unambiguously
      
    
      
    
      Hans.
      
    
      
    
      On 3/14/16 10:44 PM, Justin Richer wrote:
      
    
      
    I agree that this is =
valuable, and not
        just for PoP. In all honesty,
        
    
        it=E2=80=99s not even really required for PoP to function in =
many cases
        =E2=80=94 it=E2=80=99s
        
    
        just an optimization for one particular kind of key distribution
        
    
        mechanism in that case.
        
    
        
    
        In the years of deployment experience with OAuth 2, I think
        we=E2=80=99ve really
        
    
        got three different kinds of things that currently get folded
        into
        
    
        =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:
        
    
        
    
        
    
          - What things do I want to access? (photos, profile)
        
    
          - What actions do I want to take on these things? (read,
        write, delete)
        
    
          - How long do I want these tokens to work?
        
    
        (offline_access/refresh_token, one time use, next hour, etc)
        
    
        
    
        
    
        I think the first one is close to the audience/resource
        parameters that
        
    
        have been bandied about a few times, including in the current
        token
        
    
        exchange document. We should be consistent across drafts in that
        regard.
        
    
        The second is more traditional scope-ish. The third has been
        patched in
        
    
        with things like =E2=80=9Coffline_access=E2=80=9D in certain =
APIs.
        
    
        
    
        Just another vector to think about if we=E2=80=99re going to be =
adding
        things
        
    
        like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.
        
    
        
    
          =E2=80=94 Justin
        
    
        
    
        
    
        
    On Mar 14, 2016, at 6:26 =
PM, John
          Bradley <ve7jtb@ve7jtb.com
          
    
          <mailto:ve7jtb@ve7jtb.com>> wrote:
          
    
          
    
          Yes I will work on another proposal for allowing clients to
          specify
          
    
          what resource they want a token for and providing the
          meta-data to the
          
    
          client about the resources that a token is valid for.
          
    
          
    
          We have part of it in the POP key distribution spec and talked
          about
          
    
          separating it, as it is used more places than just for
          assigning keys.
          
    
          I know some AS use different token formats for different RS so
          are
          
    
          all-ready needing to pass the resource in the request to avoid
          making
          
    
          a mess of scopes.
          
    
          
    
          John B.
          
    
          
    
          
    
          
    
          
    
          
    
          
    On Mar 14, 2016, at 7:17 =
PM, Phil Hunt
            (IDM) <phil.hunt@oracle.com
            
    
            <mailto:phil.hunt@oracle.com>> wrote:
            
    
            
    
            Inline
            
    
            
    
            Phil
            
    
            
    
            On Mar 14, 2016, at 14:13, John Bradley
            <ve7jtb@ve7jtb.com
            
    
            <mailto:ve7jtb@ve7jtb.com>> wrote:
            
    
            
    
            
    We had two =
mandates.  One was to
              provide a spec for AS metadata.
              
    
              The other was to mitigate the client mixup attack.  =
The
              request was
              
    
              to do the latter without requiring the former for clients
              that don=E2=80=99t
              
    
              otherwise need discovery.
              
    
            
    
            There is no mandate for any of this. See
            
    
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt
            
    
            
    
              
    
              Returning the issuer and client_id from the authorization
              endpoint
              
    
              and the client checking them can be done by the client
              without
              
    
              discovery.
              
    
            
    
            
    
            How does this address the issue of whether the client is
            talking to
            
    
            the wrong endpoint?
            
    
            
    
              
    
              Any client that has the resource and issuer hard coded
              probably
              
    
              doesn=E2=80=99t need discovery.
              
    
            
    
            We agree
            
    
            
    
            
    
            
    One of the things that =
a client will
              need discovery for is to find
              
    
              the RS, so requiring the client to know the RS URI before
              getting
              
    
              the AS config seems backwards to me.
              
    
            
    
            How can you make an assumption on order? You seem to be
            conflating
            
    
            authentication with authorization by assuming the identity
            drives
            
    
            what the resource is.
            
    
            
    
            There are lots of applications that require user rights but
            are not
            
    
            identify centric. For example a document service.
            
    
            
    
              
    
              Unless the client tells the AS where it intends to use the
              token we
              
    
              will be leaving a security hole because the bearer tokens
              will have
              
    
              too loose an audience if they have one at all.
              
    
            
    
            This is the biggest risk we have IMHO.
            
    
            
    
              
    
              True you are telling the AS (Webfinger service) what the
              RS is but
              
    
              that is not at a place that is useful in the token
              production process.
              
    
            
    
            
    
            This has nothing to do with token production.
            
    
            
    
            What we want to ensure is whether an honest client is
            correctly
            
    
            configured and has not been mislead - eg by a phishing page.
            
    
            
    
              
    
              I also think there are use cases where the AS doesn=E2=80=99=
t know
              all the
              
    
              possible RS.   That is not something that a out =
of band
              check can
              
    
              address.
              
    
            
    
            
    
            May be. Lets identify them.
            
    
            
    
            
    There are also cases =
where a token
              might be good at multiple RS
              
    
              endpoints intentionally.
              
    
            
    
            
    
            
     In your solution =
the client would
              need to make a discovery request
              
    
              for each endpoint.
              
    
            
    
            Sure. Otherwise how would it know if there is one AS or a
            pool of AS
            
    
            servers assigned to each instance?
            
    
            
    Those requests lack the =
context of
              who the client and resource owner
              
    
              are.  I think that will be a problem in some use =
cases.
              
    
            
    
            
    
            Not sure I agree. This is about discovering a valid set of
            endpoints.
            
    
            For mitm, we mainly want to check the hostname is correct.
            If a
            
    
            client chooses evil.com <http://evil.com/> the cert
            can be valid and
            
    
            TLS will pass. How does it otherwise know it is supposed to
            talk to
            
    
            res.example.com <http://res.example.com/>?
            
    
            
    
              
    
              If this is added to the token endpoint it would be checked
              when code
              
    
              or refresh are exchanged, not every time the token is
              used.
              
    
            
    
            Your proposal requires rhe client to check. I am not clear
            how the AS
            
    
            can know the exact uri. It is far easier to validate than to
            lookup
            
    
            since as you say the client may be authorized to use
            multiple ASs.
            
    
            
    With a out of band =
check the client
              would never know if a RS was
              
    
              removed/revoked.
              
    
            
    
            
    
            Not sure that is in scope.
            
    
            
    
            None of the current proposals address this issue.
            
    
            
    
              
    
              I don=E2=80=99t see checking when refreshing a token as =
something
              that is a
              
    
              huge burden.
              
    
            
    
            
    
            Still its a lot more than once.
            
    
            
    
            Why don't you draft another alternative?
            
    
            
    
              
    
              If the server wants to do the check on it=E2=80=99s side =
then we
              could
              
    
              require the client to send the RS URI in the token
              request. that way
              
    
              you really know the client is not going to get a token for
              the wrong
              
    
              RS endpoint.
              
    
              If you check out of band in discovery you really have no
              idea if the
              
    
              client is checking.
              
    
            
    
            
    
            In the new webfinger draft, the client isn't checking. The
            service
            
    
            provider simply does not disclose oauth information to
            misconfigured
            
    
            clients.
            
    
            
    
              
    
              John B.
              
    
              
    
              
    
              
    On Mar 14, 2016, at =
3:56 PM, Phil
                Hunt <phil.hunt@oracle.com
                
    
                <mailto:phil.hunt@oracle.com>> wrote:
                
    
                
    
                Thanks to Mike and John for their feedback.  I=E2=80=99=
ll take
                each in turn:
                
    
                
    
                Mike,
                
    
                
    
                Regarding your suggested amendments
                
    
                
    
                Item 1: Returning the config URL would create two
                problems. One,it
                
    
                makes bound discovery a two-step process - that adds
                complexity.
                
    
                 It seems far simpler to mandate TLS (which I think =
it
                already does
                
    
                in the security considerations).
                
    
                
    
                The two-step process allows the current discovery
                process to
                
    
                continue. I disagree with this. This is why I put
                forward an
                
    
                =E2=80=9Calternate" draft that is almost the same but =
simply
                adds the check
                
    
                before returning the configuration data.  I worry =
that 
                developers
                
    
                would have no incentive to do the two-step approach.
                They would
                
    
                just start at step 2 which in turn puts AS=E2=80=99s at =
risk of
                exposing
                
    
                tokens because it works. This makes OAuth promiscuous.
                
    
                
    
                Regarding existing implementations. Most of those
                implementations
                
    
                are for OIDC.  I think it makes sense for OIDF to
                continue use of
                
    
                OIDC's discovery spec because the UserInfo endpoint is
                well defined
                
    
                and the likelihood of a client mis-informed about the
                resource
                
    
                endpoint is not there.  IMO This does not apply to =
the
                broader
                
    
                OAuth community.
                
    
                
    
                Item 2:  It may be appropriate to have a separate
                configuration
                
    
                registry specification, but I think we should hold off
                until we
                
    
                have a complete solution and then make the decision what
                drafts
                
    
                should exist and how many pieces.  A big concern is =
the
                perceived
                
    
                complexity of multiple solutions and multiple drafts.
                
    
                
    
                As to John Bradley=E2=80=99s comments:
                
    
                
    
                Re: Discovery is the wrong place to mitigate threats.
                
    
                I=E2=80=99m confused by this.  Our mandate was to =
solve a
                security threat
                
    
                by having a discovery specification to prevent clients
                being
                
    
                mis-lead about endpoints (of which resource service is
                one) in an
                
    
                oauth protected exchange.  Maybe what you mean is =
we
                should not use
                
    
                .well-known of any kind and we should just create a
                =E2=80=9C/Config=E2=80=9D
                
    
                endpoint to OAuth?
                
    
                
    
                Re: Your proposal for MITM mitigation
                
    
                You propose that instead the resource endpoint check
                should be in
                
    
                the oauth protocol itself.  The difference is that
                validation is
                
    
                transferred back to the client to get it right. As well,
                without
                
    
                the client informing the AS, I can=E2=80=99t see a way =
for the
                AS to know
                
    
                what endpoint the client is using.  The webfinger
                approach does
                
    
                this once and only requires that the host name be
                checked in many
                
    
                cases.
                
    
                
    
                As a principle, the members have discussed many times
                that the AS
                
    
                service should do validation when possible =E2=80=94 =
this was
                particularly
                
    
                true at the Germany meeting when this came up. This is
                why I prefer
                
    
                the client tell the service provider what it intends to
                do and the
                
    
                service provider can fail that request immediately if
                necessary. We
                
    
                don=E2=80=99t have to depend on the developer getting =
the spec
                correct to
                
    
                fail the correct way.
                
    
                
    
                I worry that adding more parameters to the authz and
                token protocol
                
    
                flows increases complexity and attack surface. It also
                means per
                
    
                authorization validation has to take place vs. a
                one-time
                
    
                validation at config time.  Placing it in the
                configuration lookup
                
    
                phase (whether via web finger or just a special OAuth
                endpoint)
                
    
                seems more appropriate and far less complex - as the
                request itself
                
    
                is simple and has only one parameter. Here we are not
                considered
                
    
                about legitimacy of the client. we=E2=80=99re just =
concerned
                with the issue
                
    
                "has the client been correctly informed?=E2=80=9D
                
    
                
    
                That said, it may be that when we consider all the use
                cases, some
                
    
                combination of AS protocol and discovery may be both
                needed. I=E2=80=99m
                
    
                not ready to make conclusions about this.  The =
current
                
    
                oauth-discovery spec seems to put future generic clients
                at risk
                
    
                and that is my primary concern.
                
    
                
    
                Best Regards,
                
    
                
    
                Phil
                
    
                
    
                @independentid
                
    
                www.independentid.com
                <http://www.independentid.com/>
                
    
                phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 13, 2016, at =
10:28 PM,
                  Mike Jones
                  
    
                  <Michael.Jones@microsoft.com
                  <mailto:Michael.Jones@microsoft.com>>
                  
    
                  wrote:
                  
    
                  
    
                  Thanks for posting this, Phil.  It provides a =
concrete
                  example of
                  
    
                  a way that protected resource discovery could be added
                  to
                  
    
                  authorization server metadata discovery, and as such,
                  should
                  
    
                  provide useful input for working group discussions on
                  this topic.
                  
    
                  It=E2=80=99s always great when someone takes the time =
to write
                  an actual
                  
    
                  draft that can be examined and implemented, and I
                  appreciate you
                  
    
                  doing that.
                  
    
                  The content of your draft points out that there
                  appears to be
                  
    
                  complete agreement on what the authorization server
                  metadata
                  
    
                  format should be, which is great!  I=E2=80=99ll =
note that
                  Section 3 of
                  
    
                  draft-hunt-oauth-bound-config-00 titled =
=E2=80=9CAuthorization
                  Server
                  
    
                  Metadata=E2=80=9D is an exact copy of Section 2 of
                  
    
                  draft-ietf-oauth-discovery-01 (with the same title),
                  modulo
                  
    
                  applying a correction suggested by the working =
group. 
                  To me this
                  
    
                  suggests that the authorization server metadata
                  definitions in
                  
    
                  draft-ietf-oauth-discovery (which is now the whole
                  normative
                  
    
                  content of the draft) are clearly ready for
                  standardization, since
                  
    
                  even your alternative proposal includes them verbatim.
                  
    
                  Reading your draft, the problem I have with it is that
                  you are
                  
    
                  returning the AS metadata only as a WebFinger
                  response, rather
                  
    
                  than as an https-protected resource published by the
                  authorization
                  
    
                  server.  The choice to only return this via =
WebFinger
                  makes your
                  
    
                  draft incompatible with most deployed implementations
                  of OAuth
                  
    
                  metadata, including the 22 implementations using it
                  listed
                  
    
                  athttp://openid.net/certification/(see=
 the =E2=80=9COP Config=E2=80=9D
                  column in
                  
    
                  the table) andOAuth 2.0 libraries such as =
Microsoft=E2=80=99s
                  =E2=80=9CADAL=E2=80=9D
                  
    
                  library, which uses the metadata path for client
                  configuration.
                  
    
                  Without having ASs provide the metadata as an
                  https-protected
                  
    
                  resource, implementations such as ADAL can=E2=80=99t =
use it
                  for client
                  
    
                  configuration as the currently do.
                  
    
                  Therefore, I would request that you make these minor
                  revisions to
                  
    
                  your draft and republish, so as to provide a unified
                  way forward
                  
    
                  that is compatible with all known existing OAuth
                  Discovery
                  
    
                  deployments:
                  
    
                  1.Modify your section 2 =E2=80=9CAuthorization Server
                  WebFinger Discovery=E2=80=9D
                  
    
                  to have the WebFinger request return the issuer
                  identifier for the
                  
    
                  AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D =
value, rather than
                  returning the
                  
    
                  metadata values by value as the =E2=80=9Cproperties=E2=80=
=9D value.
                  
    
                  2.Reference the metadata definitions from Section 2 of
                  
    
                  draft-ietf-oauth-discovery, rather than duplicating
                  them in your
                  
    
                  Section 3.
                  
    
                  That would have the advantage of paring your draft
                  down to only
                  
    
                  the new things that it proposes, enabling them to be
                  more clearly
                  
    
                  understood and evaluated on their own merits.  I =
look
                  forward to
                  
    
                  the discussions of ways of performing additional kinds
                  of OAuth
                  
    
                  discovery, and consider your draft a valuable input to
                  those
                  
    
                  discussions.
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  Best wishes,
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  -- Mike
                  
    
                  *From:*OAuth [mailto:oauth-bounces@ietf.org]*On =
Behalf
                  Of*John Bradley
                  
    
                  *Sent:*Sunday, March 13, 2016 6:45 PM
                  
    
                  *To:*Phil Hunt <phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>>
                  
    
                  *Cc:*oauth <oauth@ietf.org
                  <mailto:oauth@ietf.org>>
                  
    
                  *Subject:*Re: [OAUTH-WG] New Version Notification for
                  
    
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  As I have told Phil off list.
                  
    
                  Discovery is the wrong place to try and provide
                  security against
                  
    
                  man in the middle attacks on the RS.
                  
    
                  This requires the client to know what the RS URI is
                  before
                  
    
                  retrieving the information on the AS Configuration.
                  
    
                  The proposal Mike and I have been working on requires
                  the client
                  
    
                  to have a notion of what API it is looking for and
                  retrieve the
                  
    
                  .well-known file for that API from the =
issuer.   That
                  allows a
                  
    
                  protocol like Connect to register its own config file
                  that can
                  
    
                  point to the RS.
                  
    
                  If the API specific well known is not available the
                  client can try
                  
    
                  the default oauth-server one.
                  
    
                  That then allows us to deal with restricting where AT
                  are
                  
    
                  presented as part of the protocol rather then dragging
                  discovery
                  
    
                  in as a requirement.
                  
    
                  In my opinion the resource the token is targeted to
                  should be
                  
    
                  separated from the scope and returned as part of the
                  meta-data
                  
    
                  about the AT along with scopes granted and expiry
                  time.   We
                  
    
                  should also have a input parameter for resources so
                  that a client
                  
    
                  can restrict tokens issued to a subset of the ones
                  granted by the
                  
    
                  refresh token.   It would then also be =
possible to ask
                  a AS for a
                  
    
                  token for a unregistered RS and have the AS produce a
                  JWT access
                  
    
                  token with the resource as an audience if policy
                  allows.
                  
    
                  That however was supposed to be dealt with as part of
                  the mixed up
                  
    
                  client set of mitigations.
                  
    
                  In that the goal was to mitigate the attacks by
                  returning
                  
    
                  meta-data about the tokens, and not to require
                  discovery.
                  
    
                  We intend to return =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Ccleint_id=E2=80=9D for the
                  code, and I
                  
    
                  intend to discuss at the F2F returning resource for AT
                  as well.
                  
    
                  Those mitigate the attack.
                  
    
                  I will continue to resist mixing up discovery of
                  configuration
                  
    
                  meta-data with mitigation of the attacks.
                  
    
                  We return meta-data about the tokens now, because AT
                  are opaque to
                  
    
                  the client, we neglected to include some of the
                  information for
                  
    
                  the client needs to be secure.   We just =
need to add
                  that in to
                  
    
                  the existing flows.
                  
    
                  While Phil=E2=80=99s proposal is easier for the AS to
                  implement as an add
                  
    
                  on, it puts more of a burden on the client needing to
                  potentially
                  
    
                  change how it stores the relationships between AS and
                  RS to
                  
    
                  prevent compromise, I think the solution should be
                  biased towards
                  
    
                  simplicity on the client side.
                  
    
                  If we return the resources as part of the existing
                  meta data the
                  
    
                  client checks that against the resource it intends to
                  send the
                  
    
                  token to and if it is not in the list then it can=E2=80=99=
t
                  send the
                  
    
                  token.  Simple check every time it gets a new AT, =
no
                  optionality.
                  
    
                  I am not saying anything new Nat has been advocating
                  basically
                  
    
                  this for some time, and dis submit a =
draft.   I prefer
                  to return
                  
    
                  the info in the existing format rather than as link
                  headers,  but
                  
    
                  that is the largest difference between what Nat and I
                  are saying
                  
    
                  with respect to resource.
                  
    
                  That is the core of my problem with Phil=E2=80=99s =
draft.
                  
    
                  I guess we will need to have a long conversation in
                  BA.
                  
    
                  Regards
                  
    
                  John B.
                  
    
                  
    
                      On Mar 13, 2016, at 8:12 PM, Phil =
Hunt
                  <phil.hunt@oracle.com
                  
    
                      <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                      This draft is a proposed alternate =
proposal for
                  
    
                      draft-ietf-oauth-discovery.  =
As such, it contains
                  the same
                  
    
                      registry for OAuth Config Metadata =
as the authors
                  believe that
                  
    
                      both solutions are not required, or =
depending on
                  WG discussion
                  
    
                      they will be merged. The intent is =
to provide a
                  simple
                  
    
                      complete draft for consideration.
                  
    
                      How it works...
                  
    
                      Given that a client has previously =
discovered an
                  OAuth
                  
    
                      protected resource, the bound =
configuration method
                  allows a
                  
    
                      client to return the configuration =
for an oauth
                  authorization
                  
    
                      server that can issue tokens for =
the resource URI
                  specified by
                  
    
                      the client.  The AS is not =
required to be in the
                  same domain.
                  
    
                       The AS is however required to =
know if it can
                  issue tokens for
                  
    
                      a resource service (which presumes =
some agreement
                  exists on
                  
    
                      tokens etc).
                  
    
                      The draft does not require that the =
resource exist
                  (e.g. for
                  
    
                      unconfigured or new user based =
resources). It only
                  requires
                  
    
                      that the AS service provider agrees =
it can issue
                  tokens.
                  
    
                      =46rom a security perspective, =
returning the OAuth
                  service
                  
    
                      configuration for a specified =
resource URI serves
                  to confirm
                  
    
                      the client is in possession of a =
valid resource
                  URI ensuring
                  
    
                      the client has received a valid set =
of endpoints
                  for the
                  
    
                      resource and the associated oauth =
services.
                  
    
                      I propose that the WG consider the =
alternate draft
                  carefully
                  
    
                      as well as other submissions and =
evaluate the
                  broader
                  
    
                      discovery problem before proceeding =
with WGLC on
                  OAuth Discovery.
                  
    
                      Thanks!
                  
    
                      Phil
                  
    
                      @independentid
                  
    
                      www.independentid.com
                  <http://www.independentid.com/>
                  
    
                      phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                          Begin =
forwarded message:
                  
    
                          *From:*internet-drafts@ietf.org
                  
    
                          <mailto:internet-drafts@ietf.org>
                  
    
                          *Subject: =
New Version Notification for
                  
    
                          =
draft-hunt-oauth-bound-config-00.txt*
                  
    
                          =
*Date:*March 13, 2016 at 3:53:37 PM PDT
                  
    
                          *To:*"Phil =
Hunt" <phil.hunt@yahoo.com
                  
    
                          <mailto:phil.hunt@yahoo.com>>,
                  "Anthony Nadalin"
                  
    
                          <tonynad@microsoft.com
                  <mailto:tonynad@microsoft.com>>,=

                  
    
                          "Tony =
Nadalin" <tonynad@microsoft.com
                  
    
                          <mailto:tonynad@microsoft.com>>
                  
    
                  
    
                  
    
                          A new =
version of I-D,
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                          has been =
successfully submitted by Phil Hunt
                  and posted to the
                  
    
                          IETF =
repository.
                  
    
                  
    
                          =
Name:draft-hunt-oauth-bound-config
                  
    
                          Revision:00
                  
    
                          Title:OAuth =
2.0 Bound Configuration Lookup
                  
    
                          Document =
date:2016-03-13
                  
    
                          =
Group:Individual Submission
                  
    
                          Pages:22
                  
    
                          URL:
                  
    
                         
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    
                          Status:
                  
    
                         
                  https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

                  
    
                          Htmlized:
                  
    
                         
                  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                  
    
                  
    
                  
    
                          Abstract:
                  
    
                            =
This specification defines a mechanism for
                  the client of
                  
    
                          an OAuth =
2.0
                  
    
                            =
protected resource service to obtain the
                  configuration
                  
    
                          details of =
an
                  
    
                            =
OAuth 2.0 authorization server that is
                  capable of
                  
    
                          authorizing =
access
                  
    
                            =
to a specific resource service.  The
                  information
                  
    
                          includes =
the OAuth
                  
    
                            =
2.0 component endpoint location URIs and as
                  well as
                  
    
                          =
authorization
                  
    
                            =
server capabilities.
                  
    
                  
    
                  
    
                  
    
                  
    
                          Please note =
that it may take a couple of
                  minutes from the
                  
    
                          time of =
submission
                  
    
                          until the =
htmlized version and diff are
                  available
                  
    
                              attools.ietf.org
                  <http://tools.ietf.org/>.
                  
    
                  
    
                          The IETF =
Secretariat
                  
    
                  
    
                      =
_______________________________________________
                  
    
                      OAuth mailing list
                  
    
                      OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                      https://www.ietf.org/mailman/listinfo/oauth
                  
    
                
    
                
    
              
    
              
    
            
    
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.org <mailto:OAuth@ietf.org>
          
    
          https://www.ietf.org/mailman/listinfo/oauth
          
    
        
    
        
    
        
    
        
    
        _______________________________________________
        
    
        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
    


    


    =

--Apple-Mail=_682EF410-A1A2-4829-A8FB-0B6FDFBFBEF8--

--Apple-Mail=_DD69A19F-1184-4A59-9B86-04DCF8E8C38B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxNzM3NDFaMCMGCSqGSIb3DQEJBDEWBBSRTABcjLe1MF7XSO/acnnI
0wPn6zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCQpNvT+Iq8POiPLNgqc19RcHDeBjLJ03oEoAw97pRN0cnlHb6iOMHz
s8kjyy3H6zsbWdQ+138GPYY6Rx/WHx6u99Nc5qI1UX0PMNo7QesioSQyTHeRw8bnHJ78/HUYsbjo
NQ2uVE75emT3qI25C3F0vTMdYc257mJIsCqEDIXZujj5nUneRc8wHeYArNVI0JQEkWSmSDeLw5Xm
Fg1JPIM/9okgRwC58pLicrXAohvOEZfV+Hnl/Wi6hFnQwmjdDRo++HdzQi0ihKLgXKKtOC1d8i1S
NE0RYmipJYuZ2zANaXiNMthFzSZM9UF6w+Cm7FAd6gE+4CO5jYIa0YJApcJzAAAAAAAA
--Apple-Mail=_DD69A19F-1184-4A59-9B86-04DCF8E8C38B--


From nobody Tue Mar 15 10:40:26 2016
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 52EB012D586 for ; Tue, 15 Mar 2016 10:40:24 -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, FREEMAIL_FROM=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 (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 e820WF0USxTZ for ; Tue, 15 Mar 2016 10:40:22 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 100EE12DC91 for ; Tue, 15 Mar 2016 10:39:49 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id l68so37456752wml.1 for ; Tue, 15 Mar 2016 10:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=7KUSOx75tWXiqP2lw5/thzQivgYhDHVK/gNh08A8ixE=; b=f5Wzr4eOU8GeJPjCl70RwWl+Uk3o7wej2RsBzMnljmc/tyzvgCqoqD8DEnrYwiQBSq zy+Zg0qnESs8+SW0P8Zn1ppBMmPVL8TGaXTRLactNPWdOp4bl960zaWqyaUGyVMYwVcw swiRUzHdK2bSu+cj2x0yxbofQrifCclTZp69DfkZb5jdhNYdjUv6FTD1uSBWvUGEY2BP o10SpcP58v1QLd3EdEY2Kq+ofh+V7d5EdMxWTSTPjrST6zm4s49rrSfqLRLDLjJESQ0N 7osf8czSdnW9NHivErshyNJmmofaUFXG8xKiQOUvcogVFk4Iyfke8o9lq18wePO05/QB B/JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7KUSOx75tWXiqP2lw5/thzQivgYhDHVK/gNh08A8ixE=; b=TvHpZSvt1w+q9zhQdpM0LNHgtMVXyOQ1Q+g7yyEDPJfX/RNUMy+k0r79BPuiDvXhKn 8GtcNJqfKwCOQ+udMPy4aSdl4wsAOqSfxb1v20Sb7AsYMJJxKIsFK1hbkKaWocv5Kv2N u+0CGCZSlV/cDyz93a7MTghA/CPgcs/hdqH9vab9Mqb2HTucf7RS6JgyQt/o29bg96JE 2qdRdSRYBpWKC5LCLOhsU31rZ//SMJH8puQATejOmScqy33CthX7zFI/FYYIN2Yrjx2n xxoFLEqILynzcd+YwmgqOZVXvvVOBK2IGwOVr2jgJpfnw75eY0kRM1VOfKT9liiBQNyE 7GiQ==
X-Gm-Message-State: AD7BkJItlhoONi8dadFneKuKTxNydVgk7ax3QTKyqvOaPL1k2J3E1//9Yeujn/G8ztVOVw==
X-Received: by 10.194.95.40 with SMTP id dh8mr34470204wjb.146.1458063587585; Tue, 15 Mar 2016 10:39:47 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id a10sm27847937wjb.38.2016.03.15.10.39.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 10:39:46 -0700 (PDT)
To: Thomas Broyer , oauth@ietf.org
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com> 
From: Sergey Beryozkin 
Message-ID: <56E848E2.7080403@gmail.com>
Date: Tue, 15 Mar 2016 17:39:46 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:40:24 -0000

Hi Thomas

Yes, we currently only support 'small' tokens with the introspection and 
the local caching (though not time but size based which is not ideal if 
we talk about the revocations, though in a high end servers that should 
still invalidate the cache fast enough).
But that does not support multiple AS (I haven't had such a requirement 
but it is an important thing to know about), so a 'light-weight' hybrid 
JWS as it was suggested by several experts seems like a neat compromise.

Sergey
On 15/03/16 16:34, Thomas Broyer wrote:
>
>
> On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin  > wrote:
>
>     Hi
>
>     After following the recent thread on multiple authorization servers, but
>     also reading some other related threads, I have a question related to
>     when the token introspection can be avoided.
>
>     My understanding has been that given that access tokens are opaque the
>     RS does not know anything about its content, hence that was the purpose
>     of the token introspection spec: provide an interoperable way for RS to
>     submit a token to AS and get the token data for RS to make a final
>     decision about this token.
>
>     I think if the access tokens are really opaque, i.e, they are sequences
>     RS can not look into, then having the introspection option is the only
>     way to check what the token is really about.
>
>     But the recent replies with respect to using JWS or JWE tokens have
>     confused me.
>
>     1. AccessToken as JWS JWT Token:
>
>     RS can easily look into it, but Justin mentioned that in one case they
>     first validate this JWS token and then forward it for some further
>     introspection. Why start introspecting if the token has been validated
>     and its content is visible ?
>
>
> Because you want to know whether it's been revoked before its
> expiration. Introspection is the only way (unless AS and RS are
> colocated), as only the AS knows.
>
>     Perhaps because some token data which are sensitive are only visible in
>     the introspection response ? If yes then why use a self-contained token
>     if some more external data are associated with it.
>
>
> If the token is not valid (bad issuer, bad signature, expired; or if the
> scopes are included: insufficient scopes), it saves you a request to the
> introspection endpoint ;-)
> Only if the token passes the first checks would you introspect it to see
> if it's still active (not revoked) and possibly retrieve more data about it.
>
>     2. AccessToken as JWE JWT Token: this option was mentioned a couple of
>     times recently, Jonh B. suggested in the other thread the introspection
>     may not be needed (sorry if I misread it).
>     The question here, how can RS deal with a JWE token, it would need to
>     share the decrypting key with AS.
>
>
> I think that was the idea yes (didn't someone commented on the thread
> that they deployed JWT tokens with shared secrets or symmetric keys?)
>
>     So, is introspection needed only for the completely opaque tokens or it
>     is also needed for JWS and JWE tokens. I'd say it might be reasonable to
>     skip it in case of JWS, depending on the specific requirements (as the
>     expiry, issuer, will be typically set in JWS JWT), while with JWE I can
>     not see how RS can avoid introspecting unless it shares the
>     secret/private key with AS.
>
>
> As Justin mentioned in the other thread: introspection is useful
> (required?) for checking the "liveness" of the token.
>
> Side-note: given the size of a JWT compared to some "simpler", opaque
> tokens (mere identifiers), and the fact introspection response are
> likely to be cached for a few minutes by the RS, I wonder if using a JWT
> so you can possibly avoid an introspection request outweights (sic!) the
> bloat of a JWT sent repeatedly over the network (possibly a network with
> high latency, low bandwidth, and sometimes paid based on exchanged volumes).
> This is rhetoric actually: I side on the "small token that require
> introspection" until someone comes with a compelling argument to go the
> other way.


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/


From nobody Tue Mar 15 10:43:23 2016
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 8724212DC28 for ; Tue, 15 Mar 2016 10:43:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 0QJULamRRp3j for ; Tue, 15 Mar 2016 10:43:12 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 5502B12DBEE for ; Tue, 15 Mar 2016 10:43:12 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id s5so10179089qkd.0 for ; Tue, 15 Mar 2016 10:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=XwEGd4VoyqBTTIGJchFNV/8Djp5HkJxDXTx8nmyBsJ0=; b=pMOqZ07IquC/M0R6VnCr3J7etjgk2ReVrs08CFw8DNgFojyJMeH0RoiRRMOwavAmcp qmXUfTXNMJ24rLPihQAP52zKxfp8sIob55YmOlUebwkA6LtIGvavB4FBFmsJ4n0yckEe 2V2PY5a3gQh7yZlhkU7Jjbnc8blD4crzcY1dPOolIQcb/KkQ3eVo/I4bU+9pwbZtSJu5 ldKGwGWXu0M2aSiKmPWGaxPg51TUCLvEwKAulFb+0hww/QGwZuXnbNALAlrh6v8tsQbf 1xcZqcJfu5qwFo3XLBk/yXQ4jpr5y9Vj8wliLJz990YK1qUWbqVSIrH2XWVb9v0jJpME IEOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XwEGd4VoyqBTTIGJchFNV/8Djp5HkJxDXTx8nmyBsJ0=; b=FOMEiRchNut62EX6xyiO+iDM1hlDN1DQGa67UsdzbFyNay03FH8wkpAmf9XyLYrssp JruC+fVmyiLr7wRGrgAseJmshHIVog/gLVJiiV4urFxaohO9ZJHSx+c6K4FWLOX1xlXe ebPZ+2mCtIfixZ/K+4s7XsA7SfRkZUjMyRy2f9W/OnU45SnjourM2SLGurS8cP/Ok1vK fITuGtWYygWh0Dq5ilM5jhq7sfkyE4qsw4z7efBHLkDmtxQCiW3W9jsfq0qJmt3cEk3g marckbHZKTlXoiQC7D7sJbTMFrWpLZG7D/uOcUOTQSMWw+c9WKtMe8F+sZl7nZQNcYDB Jnsg==
X-Gm-Message-State: AD7BkJJkezo+vwFr3ZFZIG2pzDLTWfVeamsou7jIPS1CZTHx/Ac/9jt5uojdi9NwYxVqDQ==
X-Received: by 10.55.72.86 with SMTP id v83mr39761253qka.72.1458063791304; Tue, 15 Mar 2016 10:43:11 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.31.112]) by smtp.gmail.com with ESMTPSA id e79sm13234075qkj.2.2016.03.15.10.43.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 10:43:10 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_4F9A4862-8D2D-43D2-99E5-55975C455FAB"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56E83047.8090908@aol.com>
Date: Tue, 15 Mar 2016 14:43:07 -0300
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com> <56E83047.8090908@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:43:19 -0000

--Apple-Mail=_4F9A4862-8D2D-43D2-99E5-55975C455FAB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E0173164-BCFE-486D-8BEC-B51574758E38"


--Apple-Mail=_E0173164-BCFE-486D-8BEC-B51574758E38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I am trying to support multiple audiences in a token.   We are agreed on =
that.

The problem with having a abstract audience is how a client would verify =
the RS URI is correct. =20

If we wanted abstract Audience could be a HTTPS URI with only host =
component,  or a Fully qualified URI that can be retrieved by the client =
to get the concrete resource endpoints. =20
That however starts down the road to resource discovery.

John B.
> On Mar 15, 2016, at 12:54 PM, George Fletcher  =
wrote:
>=20
> I'm not against binding audiences to a token. (Note that in many =
deployments today, a single access token can be used at many endpoints =
representing different services. It's not uncommon for a client to =
request a token to access the mail endpoints, messaging endpoints, =
contacts endpoints, etc. This requires the ability to associate multiple =
audiences to a single token.)
>=20
> The issue is whether it's possible to represent the RS with an =
abstract audience identifier (e.g. URN?) rather than a specific =
endpoint. Taking this approach provides a level of indirection that is =
much easier to configure. The AS likely knows (or can be configured) =
that it supports a Instant-Messaging RS. The client can then use some =
other mechanism to determine the exact endpoint of that abstract =
audience identifier. This keeps the relationships defined without the =
tight-coupling of registering endpoints (even with wild cards).
>=20
> Now if the direction is to move to a token can only have one audience, =
to me that isn't OAuth2. It's a perfectly fine model, but we should be =
addressing that as the next gen spec, not trying to layer it on the =
existing one that has different deployment semantics.
>=20
> Thanks,
> George
>=20
> On 3/15/16 11:37 AM, John Bradley wrote:
>> Yes,  I think bearer tokens with no audience are a bad idea.
>>=20
>> The AS needs to infer an audience from the scopes snd/or have the =
client specify the desired audience.
>>=20
>> If the AT has a audience or audiences then as long as the endpoint =
URI are provided as meta-data with the token, the client can determine =
if it is sending the token to the correct place.
>>=20
>> I think Phil would prefer the server rather than the client do the =
check, but the client always needs to take some responsibility to not =
leak tokens giving them to the wrong RS or the code to the wrong token =
endpoint is leaking.
>>=20
>> I imagine that claims based access tokens are going to become more =
popular and the static relationship between one RS and one AS will not =
be the majority of deployments over time.=20
>>=20
>> In any case where the client is configured up front to know the RS =
and the AS it seems like that would not require Phil=E2=80=99s Solution, =
but that is the only case supported by that discovery.
>>  =20
>> If the client itself is bad there is not much you can do to stop it =
from passing on the AT in way way it wants.  That however is a different =
problem and needs claimed URI or attestations to prevent client =
spoofing.
>> William and I are working on that in the mobile best practices draft.
>>=20
>> John B.
>>=20
>>=20
>>> On Mar 15, 2016, at 12:09 PM, George Fletcher > wrote:
>>>=20
>>> I worry about two directions I see in this thread...
>>>=20
>>> 1. Client's accessing resources dynamically so that discovery is =
required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>>>=20
>>> 2. Creating a tight coupling between RS and AS such that RS endpoint =
changes must be continually communicated to the AS. If an RS supports =
multiple AS's then the RS has to deal with "guaranteed" delivery. The AS =
needs an endpoint to receive such communications. If not dynamic via =
APIs, then deployment of the new RS is bound by the associated AS's =
getting and deploying the new endpoints. Can both endpoints of the RS be =
supported within the AS for some period of time, etc. This is an =
operation nightmare and almost assuredly going to go wrong in =
production.
>>>=20
>>> Maybe an OAuth2 "audience binding" spec is what's needed for those =
deployments that require this. I believe that is what John Bradley is =
suggesting.
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>> +1, I've found the very same in OAuth deployments that I was =
involved in; the hard part is to give names and descriptions to these =
concepts so that they cover all use cases and can be applied =
unambiguously=20
>>>>=20
>>>> Hans.=20
>>>>=20
>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>> I agree that this is valuable, and not just for PoP. In all =
honesty,=20
>>>>> it=E2=80=99s not even really required for PoP to function in many =
cases =E2=80=94 it=E2=80=99s=20
>>>>> just an optimization for one particular kind of key distribution=20=

>>>>> mechanism in that case.=20
>>>>>=20
>>>>> In the years of deployment experience with OAuth 2, I think =
we=E2=80=99ve really=20
>>>>> got three different kinds of things that currently get folded into=20=

>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:=20
>>>>>=20
>>>>>=20
>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>   - What actions do I want to take on these things? (read, write, =
delete)=20
>>>>>   - How long do I want these tokens to work?=20
>>>>> (offline_access/refresh_token, one time use, next hour, etc)=20
>>>>>=20
>>>>>=20
>>>>> I think the first one is close to the audience/resource parameters =
that=20
>>>>> have been bandied about a few times, including in the current =
token=20
>>>>> exchange document. We should be consistent across drafts in that =
regard.=20
>>>>> The second is more traditional scope-ish. The third has been =
patched in=20
>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.=20=

>>>>>=20
>>>>> Just another vector to think about if we=E2=80=99re going to be =
adding things=20
>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.=20
>>>>>=20
>>>>>   =E2=80=94 Justin=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>  > wrote:=20
>>>>>>=20
>>>>>> Yes I will work on another proposal for allowing clients to =
specify=20
>>>>>> what resource they want a token for and providing the meta-data =
to the=20
>>>>>> client about the resources that a token is valid for.=20
>>>>>>=20
>>>>>> We have part of it in the POP key distribution spec and talked =
about=20
>>>>>> separating it, as it is used more places than just for assigning =
keys.=20
>>>>>> I know some AS use different token formats for different RS so =
are=20
>>>>>> all-ready needing to pass the resource in the request to avoid =
making=20
>>>>>> a mess of scopes.=20
>>>>>>=20
>>>>>> John B.=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) < =
phil.hunt@oracle.com =
=20
>>>>>>>  > =
wrote:=20
>>>>>>>=20
>>>>>>> Inline=20
>>>>>>>=20
>>>>>>> Phil=20
>>>>>>>=20
>>>>>>> On Mar 14, 2016, at 14:13, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>>  > wrote:=20
>>>>>>>=20
>>>>>>>> We had two mandates.  One was to provide a spec for AS =
metadata.=20
>>>>>>>> The other was to mitigate the client mixup attack.  The request =
was=20
>>>>>>>> to do the latter without requiring the former for clients that =
don=E2=80=99t=20
>>>>>>>> otherwise need discovery.=20
>>>>>>> There is no mandate for any of this. See=20
>>>>>>> =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =
=20
>>>>>>>>=20
>>>>>>>> Returning the issuer and client_id from the authorization =
endpoint=20
>>>>>>>> and the client checking them can be done by the client without=20=

>>>>>>>> discovery.=20
>>>>>>>=20
>>>>>>> How does this address the issue of whether the client is talking =
to=20
>>>>>>> the wrong endpoint?=20
>>>>>>>>=20
>>>>>>>> Any client that has the resource and issuer hard coded probably=20=

>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>> We agree=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> One of the things that a client will need discovery for is to =
find=20
>>>>>>>> the RS, so requiring the client to know the RS URI before =
getting=20
>>>>>>>> the AS config seems backwards to me.=20
>>>>>>> How can you make an assumption on order? You seem to be =
conflating=20
>>>>>>> authentication with authorization by assuming the identity =
drives=20
>>>>>>> what the resource is.=20
>>>>>>>=20
>>>>>>> There are lots of applications that require user rights but are =
not=20
>>>>>>> identify centric. For example a document service.=20
>>>>>>>>=20
>>>>>>>> Unless the client tells the AS where it intends to use the =
token we=20
>>>>>>>> will be leaving a security hole because the bearer tokens will =
have=20
>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>=20
>>>>>>>> True you are telling the AS (Webfinger service) what the RS is =
but=20
>>>>>>>> that is not at a place that is useful in the token production =
process.=20
>>>>>>>=20
>>>>>>> This has nothing to do with token production.=20
>>>>>>>=20
>>>>>>> What we want to ensure is whether an honest client is correctly=20=

>>>>>>> configured and has not been mislead - eg by a phishing page.=20
>>>>>>>>=20
>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99t =
know all the=20
>>>>>>>> possible RS.   That is not something that a out of band check =
can=20
>>>>>>>> address.=20
>>>>>>>=20
>>>>>>> May be. Lets identify them.=20
>>>>>>>=20
>>>>>>>> There are also cases where a token might be good at multiple RS=20=

>>>>>>>> endpoints intentionally.=20
>>>>>>>=20
>>>>>>>>  In your solution the client would need to make a discovery =
request=20
>>>>>>>> for each endpoint.=20
>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool =
of AS=20
>>>>>>> servers assigned to each instance?=20
>>>>>>>> Those requests lack the context of who the client and resource =
owner=20
>>>>>>>> are.  I think that will be a problem in some use cases.=20
>>>>>>>=20
>>>>>>> Not sure I agree. This is about discovering a valid set of =
endpoints.=20
>>>>>>> For mitm, we mainly want to check the hostname is correct. If a=20=

>>>>>>> client chooses evil.com   =
  the cert can be =
valid and=20
>>>>>>> TLS will pass. How does it otherwise know it is supposed to talk =
to=20
>>>>>>> res.example.com  =
 ?=20
>>>>>>>>=20
>>>>>>>> If this is added to the token endpoint it would be checked when =
code=20
>>>>>>>> or refresh are exchanged, not every time the token is used.=20
>>>>>>> Your proposal requires rhe client to check. I am not clear how =
the AS=20
>>>>>>> can know the exact uri. It is far easier to validate than to =
lookup=20
>>>>>>> since as you say the client may be authorized to use multiple =
ASs.=20
>>>>>>>> With a out of band check the client would never know if a RS =
was=20
>>>>>>>> removed/revoked.=20
>>>>>>>=20
>>>>>>> Not sure that is in scope.=20
>>>>>>>=20
>>>>>>> None of the current proposals address this issue.=20
>>>>>>>>=20
>>>>>>>> I don=E2=80=99t see checking when refreshing a token as =
something that is a=20
>>>>>>>> huge burden.=20
>>>>>>>=20
>>>>>>> Still its a lot more than once.=20
>>>>>>>=20
>>>>>>> Why don't you draft another alternative?=20
>>>>>>>>=20
>>>>>>>> If the server wants to do the check on it=E2=80=99s side then =
we could=20
>>>>>>>> require the client to send the RS URI in the token request. =
that way=20
>>>>>>>> you really know the client is not going to get a token for the =
wrong=20
>>>>>>>> RS endpoint.=20
>>>>>>>> If you check out of band in discovery you really have no idea =
if the=20
>>>>>>>> client is checking.=20
>>>>>>>=20
>>>>>>> In the new webfinger draft, the client isn't checking. The =
service=20
>>>>>>> provider simply does not disclose oauth information to =
misconfigured=20
>>>>>>> clients.=20
>>>>>>>>=20
>>>>>>>> John B.=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt < =
phil.hunt@oracle.com =
=20
>>>>>>>>>  > =
wrote:=20
>>>>>>>>>=20
>>>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take =
each in turn:=20
>>>>>>>>>=20
>>>>>>>>> Mike,=20
>>>>>>>>>=20
>>>>>>>>> Regarding your suggested amendments=20
>>>>>>>>>=20
>>>>>>>>> Item 1: Returning the config URL would create two problems. =
One,it=20
>>>>>>>>> makes bound discovery a two-step process - that adds =
complexity.=20
>>>>>>>>>  It seems far simpler to mandate TLS (which I think it already =
does=20
>>>>>>>>> in the security considerations).=20
>>>>>>>>>=20
>>>>>>>>> The two-step process allows the current discovery process to=20=

>>>>>>>>> continue. I disagree with this. This is why I put forward an=20=

>>>>>>>>> =E2=80=9Calternate" draft that is almost the same but simply =
adds the check=20
>>>>>>>>> before returning the configuration data.  I worry that  =
developers=20
>>>>>>>>> would have no incentive to do the two-step approach. They =
would=20
>>>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at risk =
of exposing=20
>>>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>>>=20
>>>>>>>>> Regarding existing implementations. Most of those =
implementations=20
>>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use =
of=20
>>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well =
defined=20
>>>>>>>>> and the likelihood of a client mis-informed about the resource=20=

>>>>>>>>> endpoint is not there.  IMO This does not apply to the broader=20=

>>>>>>>>> OAuth community.=20
>>>>>>>>>=20
>>>>>>>>> Item 2:  It may be appropriate to have a separate =
configuration=20
>>>>>>>>> registry specification, but I think we should hold off until =
we=20
>>>>>>>>> have a complete solution and then make the decision what =
drafts=20
>>>>>>>>> should exist and how many pieces.  A big concern is the =
perceived=20
>>>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>>>=20
>>>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>>>=20
>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a =
security threat=20
>>>>>>>>> by having a discovery specification to prevent clients being=20=

>>>>>>>>> mis-lead about endpoints (of which resource service is one) in =
an=20
>>>>>>>>> oauth protected exchange.  Maybe what you mean is we should =
not use=20
>>>>>>>>> .well-known of any kind and we should just create a =
=E2=80=9C/Config=E2=80=9D=20
>>>>>>>>> endpoint to OAuth?=20
>>>>>>>>>=20
>>>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>>>> You propose that instead the resource endpoint check should be =
in=20
>>>>>>>>> the oauth protocol itself.  The difference is that validation =
is=20
>>>>>>>>> transferred back to the client to get it right. As well, =
without=20
>>>>>>>>> the client informing the AS, I can=E2=80=99t see a way for the =
AS to know=20
>>>>>>>>> what endpoint the client is using.  The webfinger approach =
does=20
>>>>>>>>> this once and only requires that the host name be checked in =
many=20
>>>>>>>>> cases.=20
>>>>>>>>>=20
>>>>>>>>> As a principle, the members have discussed many times that the =
AS=20
>>>>>>>>> service should do validation when possible =E2=80=94 this was =
particularly=20
>>>>>>>>> true at the Germany meeting when this came up. This is why I =
prefer=20
>>>>>>>>> the client tell the service provider what it intends to do and =
the=20
>>>>>>>>> service provider can fail that request immediately if =
necessary. We=20
>>>>>>>>> don=E2=80=99t have to depend on the developer getting the spec =
correct to=20
>>>>>>>>> fail the correct way.=20
>>>>>>>>>=20
>>>>>>>>> I worry that adding more parameters to the authz and token =
protocol=20
>>>>>>>>> flows increases complexity and attack surface. It also means =
per=20
>>>>>>>>> authorization validation has to take place vs. a one-time=20
>>>>>>>>> validation at config time.  Placing it in the configuration =
lookup=20
>>>>>>>>> phase (whether via web finger or just a special OAuth =
endpoint)=20
>>>>>>>>> seems more appropriate and far less complex - as the request =
itself=20
>>>>>>>>> is simple and has only one parameter. Here we are not =
considered=20
>>>>>>>>> about legitimacy of the client. we=E2=80=99re just concerned =
with the issue=20
>>>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>>>=20
>>>>>>>>> That said, it may be that when we consider all the use cases, =
some=20
>>>>>>>>> combination of AS protocol and discovery may be both needed. =
I=E2=80=99m=20
>>>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>>>> oauth-discovery spec seems to put future generic clients at =
risk=20
>>>>>>>>> and that is my primary concern.=20
>>>>>>>>>=20
>>>>>>>>> Best Regards,=20
>>>>>>>>>=20
>>>>>>>>> Phil=20
>>>>>>>>>=20
>>>>>>>>> @independentid=20
>>>>>>>>> www.independentid.com  =
 =20
>>>>>>>>> phil.hunt@oracle.com  =
 =20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>>>  =
 =
>=20
>>>>>>>>>> wrote:=20
>>>>>>>>>>=20
>>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete =
example of=20
>>>>>>>>>> a way that protected resource discovery could be added to=20
>>>>>>>>>> authorization server metadata discovery, and as such, should=20=

>>>>>>>>>> provide useful input for working group discussions on this =
topic.=20
>>>>>>>>>> It=E2=80=99s always great when someone takes the time to =
write an actual=20
>>>>>>>>>> draft that can be examined and implemented, and I appreciate =
you=20
>>>>>>>>>> doing that.=20
>>>>>>>>>> The content of your draft points out that there appears to be=20=

>>>>>>>>>> complete agreement on what the authorization server metadata=20=

>>>>>>>>>> format should be, which is great!  I=E2=80=99ll note that =
Section 3 of=20
>>>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization =
Server=20
>>>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo=20=

>>>>>>>>>> applying a correction suggested by the working group.  To me =
this=20
>>>>>>>>>> suggests that the authorization server metadata definitions =
in=20
>>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative=20=

>>>>>>>>>> content of the draft) are clearly ready for standardization, =
since=20
>>>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>>>> Reading your draft, the problem I have with it is that you =
are=20
>>>>>>>>>> returning the AS metadata only as a WebFinger response, =
rather=20
>>>>>>>>>> than as an https-protected resource published by the =
authorization=20
>>>>>>>>>> server.  The choice to only return this via WebFinger makes =
your=20
>>>>>>>>>> draft incompatible with most deployed implementations of =
OAuth=20
>>>>>>>>>> metadata, including the 22 implementations using it listed=20
>>>>>>>>>> athttp://openid.net/certification/ =
(see the =E2=80=9COP Config=E2=80=9D =
column in=20
>>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D=20
>>>>>>>>>> library, which uses the metadata path for client =
configuration.=20
>>>>>>>>>> Without having ASs provide the metadata as an https-protected=20=

>>>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use it =
for client=20
>>>>>>>>>> configuration as the currently do.=20
>>>>>>>>>> Therefore, I would request that you make these minor =
revisions to=20
>>>>>>>>>> your draft and republish, so as to provide a unified way =
forward=20
>>>>>>>>>> that is compatible with all known existing OAuth Discovery=20
>>>>>>>>>> deployments:=20
>>>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D=20
>>>>>>>>>> to have the WebFinger request return the issuer identifier =
for the=20
>>>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, =
rather than returning the=20
>>>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D =
value.=20
>>>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in =
your=20
>>>>>>>>>> Section 3.=20
>>>>>>>>>> That would have the advantage of paring your draft down to =
only=20
>>>>>>>>>> the new things that it proposes, enabling them to be more =
clearly=20
>>>>>>>>>> understood and evaluated on their own merits.  I look forward =
to=20
>>>>>>>>>> the discussions of ways of performing additional kinds of =
OAuth=20
>>>>>>>>>> discovery, and consider your draft a valuable input to those=20=

>>>>>>>>>> discussions.=20
>>>>>>>>>>                                                           =
Best wishes,=20
>>>>>>>>>>                                                           -- =
Mike=20
>>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org =
]*On Behalf Of*John Bradley=20
>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>>>> *To:*Phil Hunt < =
phil.hunt@oracle.com =
  =
>=20
>>>>>>>>>> *Cc:*oauth  =
 >=20
>>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>> As I have told Phil off list.=20
>>>>>>>>>> Discovery is the wrong place to try and provide security =
against=20
>>>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>>>> This requires the client to know what the RS URI is before=20
>>>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>>>> The proposal Mike and I have been working on requires the =
client=20
>>>>>>>>>> to have a notion of what API it is looking for and retrieve =
the=20
>>>>>>>>>> .well-known file for that API from the issuer.   That allows =
a=20
>>>>>>>>>> protocol like Connect to register its own config file that =
can=20
>>>>>>>>>> point to the RS.=20
>>>>>>>>>> If the API specific well known is not available the client =
can try=20
>>>>>>>>>> the default oauth-server one.=20
>>>>>>>>>> That then allows us to deal with restricting where AT are=20
>>>>>>>>>> presented as part of the protocol rather then dragging =
discovery=20
>>>>>>>>>> in as a requirement.=20
>>>>>>>>>> In my opinion the resource the token is targeted to should be=20=

>>>>>>>>>> separated from the scope and returned as part of the =
meta-data=20
>>>>>>>>>> about the AT along with scopes granted and expiry time.   We=20=

>>>>>>>>>> should also have a input parameter for resources so that a =
client=20
>>>>>>>>>> can restrict tokens issued to a subset of the ones granted by =
the=20
>>>>>>>>>> refresh token.   It would then also be possible to ask a AS =
for a=20
>>>>>>>>>> token for a unregistered RS and have the AS produce a JWT =
access=20
>>>>>>>>>> token with the resource as an audience if policy allows.=20
>>>>>>>>>> That however was supposed to be dealt with as part of the =
mixed up=20
>>>>>>>>>> client set of mitigations.=20
>>>>>>>>>> In that the goal was to mitigate the attacks by returning=20
>>>>>>>>>> meta-data about the tokens, and not to require discovery.=20
>>>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_i=
d=E2=80=9D for the code, and I=20
>>>>>>>>>> intend to discuss at the F2F returning resource for AT as =
well.=20
>>>>>>>>>> Those mitigate the attack.=20
>>>>>>>>>> I will continue to resist mixing up discovery of =
configuration=20
>>>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>>>> We return meta-data about the tokens now, because AT are =
opaque to=20
>>>>>>>>>> the client, we neglected to include some of the information =
for=20
>>>>>>>>>> the client needs to be secure.   We just need to add that in =
to=20
>>>>>>>>>> the existing flows.=20
>>>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add=20
>>>>>>>>>> on, it puts more of a burden on the client needing to =
potentially=20
>>>>>>>>>> change how it stores the relationships between AS and RS to=20=

>>>>>>>>>> prevent compromise, I think the solution should be biased =
towards=20
>>>>>>>>>> simplicity on the client side.=20
>>>>>>>>>> If we return the resources as part of the existing meta data =
the=20
>>>>>>>>>> client checks that against the resource it intends to send =
the=20
>>>>>>>>>> token to and if it is not in the list then it can=E2=80=99t =
send the=20
>>>>>>>>>> token.  Simple check every time it gets a new AT, no =
optionality.=20
>>>>>>>>>> I am not saying anything new Nat has been advocating =
basically=20
>>>>>>>>>> this for some time, and dis submit a draft.   I prefer to =
return=20
>>>>>>>>>> the info in the existing format rather than as link headers,  =
but=20
>>>>>>>>>> that is the largest difference between what Nat and I are =
saying=20
>>>>>>>>>> with respect to resource.=20
>>>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20
>>>>>>>>>> I guess we will need to have a long conversation in BA.=20
>>>>>>>>>> Regards=20
>>>>>>>>>> John B.=20
>>>>>>>>>>=20
>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt =
=20
>>>>>>>>>>      =
> wrote:=20
>>>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the =
same=20
>>>>>>>>>>     registry for OAuth Config Metadata as the authors believe =
that=20
>>>>>>>>>>     both solutions are not required, or depending on WG =
discussion=20
>>>>>>>>>>     they will be merged. The intent is to provide a simple=20
>>>>>>>>>>     complete draft for consideration.=20
>>>>>>>>>>     How it works...=20
>>>>>>>>>>     Given that a client has previously discovered an OAuth=20
>>>>>>>>>>     protected resource, the bound configuration method allows =
a=20
>>>>>>>>>>     client to return the configuration for an oauth =
authorization=20
>>>>>>>>>>     server that can issue tokens for the resource URI =
specified by=20
>>>>>>>>>>     the client.  The AS is not required to be in the same =
domain.=20
>>>>>>>>>>      The AS is however required to know if it can issue =
tokens for=20
>>>>>>>>>>     a resource service (which presumes some agreement exists =
on=20
>>>>>>>>>>     tokens etc).=20
>>>>>>>>>>     The draft does not require that the resource exist (e.g. =
for=20
>>>>>>>>>>     unconfigured or new user based resources). It only =
requires=20
>>>>>>>>>>     that the AS service provider agrees it can issue tokens.=20=

>>>>>>>>>>     =46rom a security perspective, returning the OAuth =
service=20
>>>>>>>>>>     configuration for a specified resource URI serves to =
confirm=20
>>>>>>>>>>     the client is in possession of a valid resource URI =
ensuring=20
>>>>>>>>>>     the client has received a valid set of endpoints for the=20=

>>>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>>>     I propose that the WG consider the alternate draft =
carefully=20
>>>>>>>>>>     as well as other submissions and evaluate the broader=20
>>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth =
Discovery.=20
>>>>>>>>>>     Thanks!=20
>>>>>>>>>>     Phil=20
>>>>>>>>>>     @independentid=20
>>>>>>>>>>     www.independentid.com  =
 =20
>>>>>>>>>>     phil.hunt@oracle.com  =
 =20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Begin forwarded message:=20
>>>>>>>>>>         *From:*internet-drafts@ietf.org =
=20
>>>>>>>>>>          =
=20
>>>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>>>         *To:*"Phil Hunt" < =
phil.hunt@yahoo.com =
=20
>>>>>>>>>>          =
>, "Anthony Nadalin"=20
>>>>>>>>>>          =
 >,=20
>>>>>>>>>>         "Tony Nadalin" < =
tonynad@microsoft.com =
=20
>>>>>>>>>>          =
>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>>         has been successfully submitted by Phil Hunt and =
posted to the=20
>>>>>>>>>>         IETF repository.=20
>>>>>>>>>>=20
>>>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>>>         Revision:00=20
>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>>>         Group:Individual Submission=20
>>>>>>>>>>         Pages:22=20
>>>>>>>>>>         URL:=20
>>>>>>>>>>         =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>>>>>>>>         Status:=20
>>>>>>>>>>         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =
=20
>>>>>>>>>>         Htmlized:=20
>>>>>>>>>>         =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =
=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Abstract:=20
>>>>>>>>>>           This specification defines a mechanism for the =
client of=20
>>>>>>>>>>         an OAuth 2.0=20
>>>>>>>>>>           protected resource service to obtain the =
configuration=20
>>>>>>>>>>         details of an=20
>>>>>>>>>>           OAuth 2.0 authorization server that is capable of=20=

>>>>>>>>>>         authorizing access=20
>>>>>>>>>>           to a specific resource service.  The information=20
>>>>>>>>>>         includes the OAuth=20
>>>>>>>>>>           2.0 component endpoint location URIs and as well as=20=

>>>>>>>>>>         authorization=20
>>>>>>>>>>           server capabilities.=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Please note that it may take a couple of minutes from =
the=20
>>>>>>>>>>         time of submission=20
>>>>>>>>>>         until the htmlized version and diff are available=20
>>>>>>>>>>         attools.ietf.org  =
 .=20
>>>>>>>>>>=20
>>>>>>>>>>         The IETF Secretariat=20
>>>>>>>>>>=20
>>>>>>>>>>     _______________________________________________=20
>>>>>>>>>>     OAuth mailing list=20
>>>>>>>>>>     OAuth@ietf.org  =
 =20
>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________=20
>>>>>> OAuth mailing list=20
>>>>>> OAuth@ietf.org   =
=20
>>>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________=20
>>>>> OAuth mailing list=20
>>>>> OAuth@ietf.org =20
>>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_E0173164-BCFE-486D-8BEC-B51574758E38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I am trying to support multiple audiences in a token.   =
We are agreed on that.

    The problem with having a abstract audience is how a client =
would verify the RS URI is correct.  

    If we wanted abstract Audience could be =
a HTTPS URI with only host component,  or a Fully qualified URI =
that can be retrieved by the client to get the concrete resource =
endpoints.  
    That however starts down the road =
to resource discovery.

    John B.
    On Mar 15, 2016, at 12:54 PM, George Fletcher =
<gffletch@aol.com> wrote:

    
 =20
    
 =20
  
    
    I'm not =
against binding
      audiences to a token. (Note that in many deployments today, a
      single access token can be used at many endpoints representing
      different services. It's not uncommon for a client to request a
      token to access the mail endpoints, messaging endpoints, contacts
      endpoints, etc. This requires the ability to associate multiple
      audiences to a single token.)
    
      
    
      The issue is whether it's possible to represent the RS with an
      abstract audience identifier (e.g. URN?) rather than a specific
      endpoint. Taking this approach provides a level of indirection
      that is much easier to configure. The AS likely knows (or can be
      configured) that it supports a Instant-Messaging RS. The client
      can then use some other mechanism to determine the exact endpoint
      of that abstract audience identifier. This keeps the relationships
      defined without the tight-coupling of registering endpoints (even
      with wild cards).
    
      
    
      Now if the direction is to move to a token can only have one
      audience, to me that isn't OAuth2. It's a perfectly fine model,
      but we should be addressing that as the next gen spec, not trying
      to layer it on the existing one that has different deployment
      semantics.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/15/16 11:37 AM, John Bradley
      wrote:
    
    
    
    
    
      
      Yes,  I think bearer tokens with no audience are a bad idea.
      

    
      
    
      
    The AS needs to infer an audience from the scopes
        snd/or have the client specify the desired audience.
    
      

    
      
    
      
    If the AT has a audience or audiences then as long
        as the endpoint URI are provided as meta-data with the token,
        the client can determine if it is sending the token to the
        correct place.
    
      

    
      
    
      
    I think Phil would prefer the server rather than =
the
        client do the check, but the client always needs to take some
        responsibility to not leak tokens giving them to the wrong RS or
        the code to the wrong token endpoint is leaking.
    
      

    
      
    
      
    I imagine that claims based access tokens are =
going
        to become more popular and the static relationship between one
        RS and one AS will not be the majority of deployments over
        time. 
    
      

    
      
    
      
    In any case where the client is configured up =
front
        to know the RS and the AS it seems like that would not require
        Phil=E2=80=99s Solution, but that is the only case supported by =
that
        discovery.
    
      
      
    
      
    If the client itself is bad there is not much you
        can do to stop it from passing on the AT in way way it wants.
         That however is a different problem and needs claimed URI =
or
        attestations to prevent client spoofing.
    
      
    William and I are working on that in the mobile =
best
        practices draft.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 12:09 PM, George =
Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
              
              
     =
I worry
                  about two directions I see in this thread...
    
                  
    
                  1. Client's accessing resources dynamically so that
                  discovery is required to know the correct AS, etc.
                  This is pretty much the classic use case for UMA and
                  I'd rather not re-invent the wheel.
    
                  
    
                  2. Creating a tight coupling between RS and AS such
                  that RS endpoint changes must be continually
                  communicated to the AS. If an RS supports multiple
                  AS's then the RS has to deal with "guaranteed"
                  delivery. The AS needs an endpoint to receive such
                  communications. If not dynamic via APIs, then
                  deployment of the new RS is bound by the associated
                  AS's getting and deploying the new endpoints. Can both
                  endpoints of the RS be supported within the AS for
                  some period of time, etc. This is an operation
                  nightmare and almost assuredly going to go wrong in
                  production.
    
                  
    
                  Maybe an OAuth2 "audience binding" spec is what's
                  needed for those deployments that require this. I
                  believe that is what John Bradley is suggesting.
    
                  
    
                  Thanks,
    
                  George
    
                
    
                
    On 3/14/16 7:29 PM, Hans
                  Zandbelt wrote:
    
                
    
                
    +1, I've found the very same in
                  OAuth deployments that I was involved in; the hard
                  part is to give names and descriptions to these
                  concepts so that they cover all use cases and can be
                  applied unambiguously 
    
                  
    
                  Hans. 
    
                  
    
                  On 3/14/16 10:44 PM, Justin Richer wrote: 
    
                  
    I agree that this =
is
                    valuable, and not just for PoP. In all honesty, 
    
                    it=E2=80=99s not even really required for PoP to =
function in
                    many cases =E2=80=94 it=E2=80=99s 
    
                    just an optimization for one particular kind of key
                    distribution 
    
                    mechanism in that case. 
    
                    
    
                    In the years of deployment experience with OAuth 2,
                    I think we=E2=80=99ve really 
    
                    got three different kinds of things that currently
                    get folded into 
    
                    =E2=80=9Cscope=E2=80=9D that we might want to try =
separating out
                    better: 
    
                    
    
                    
    
                      - What things do I want to access? (photos,
                    profile) 
    
                      - What actions do I want to take on these =
things?
                    (read, write, delete) 
    
                      - How long do I want these tokens to work? =

    
                    (offline_access/refresh_token, one time use, next
                    hour, etc) 
    
                    
    
                    
    
                    I think the first one is close to the
                    audience/resource parameters that 
    
                    have been bandied about a few times, including in
                    the current token 
    
                    exchange document. We should be consistent across
                    drafts in that regard. 
    
                    The second is more traditional scope-ish. The third
                    has been patched in 
    
                    with things like =E2=80=9Coffline_access=E2=80=9D in =
certain APIs. 
    
                    
    
                    Just another vector to think about if we=E2=80=99re =
going to
                    be adding things 
    
                    like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=
=80=9D or both to the token
                    requests. 
    
                    
    
                      =E2=80=94 Justin 
    
                    
    
                    
    
                    
    On Mar 14, =
2016, at
                      6:26 PM, John Bradley <ve7jtb@ve7jtb.com
                      
    
                      <mailto:ve7jtb@ve7jtb.com>>=

                      wrote: 
    
                      
    
                      Yes I will work on another proposal for allowing
                      clients to specify 
    
                      what resource they want a token for and providing
                      the meta-data to the 
    
                      client about the resources that a token is valid
                      for. 
    
                      
    
                      We have part of it in the POP key distribution
                      spec and talked about 
    
                      separating it, as it is used more places than just
                      for assigning keys. 
    
                      I know some AS use different token formats for
                      different RS so are 
    
                      all-ready needing to pass the resource in the
                      request to avoid making 
    
                      a mess of scopes. 
    
                      
    
                      John B. 
    
                      
    
                      
    
                      
    
                      
    
                      
    
                      
    On Mar 14, =
2016,
                        at 7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com
                        
    
                        <mailto:phil.hunt@oracle.com>>
                        wrote: 
    
                        
    
                        Inline 
    
                        
    
                        Phil 
    
                        
    
                        On Mar 14, 2016, at 14:13, John Bradley <    ve7jtb@ve7jtb.com
                        
    
                        <mailto:ve7jtb@ve7jtb.com>>=

                        wrote: 
    
                        
    
                        
    We had two
                          mandates.  One was to provide a spec for =
AS
                          metadata. 
    
                          The other was to mitigate the client mixup
                          attack.  The request was 
    
                          to do the latter without requiring the former
                          for clients that don=E2=80=99t 
    
                          otherwise need discovery. 
    
                        
    
                        There is no mandate for any of this. See 
    
                        http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt
                        
    
                        
     
    
                          Returning the issuer and client_id from the
                          authorization endpoint 
    
                          and the client checking them can be done by
                          the client without 
    
                          discovery. 
    
                        
    
                        
    
                        How does this address the issue of whether the
                        client is talking to 
    
                        the wrong endpoint? 
    
                        
     
    
                          Any client that has the resource and issuer
                          hard coded probably 
    
                          doesn=E2=80=99t need discovery. 
    
                        
    
                        We agree 
    
                        
    
                        
    
                        
    One of the
                          things that a client will need discovery for
                          is to find 
    
                          the RS, so requiring the client to know the RS
                          URI before getting 
    
                          the AS config seems backwards to me. 
    
                        
    
                        How can you make an assumption on order? You
                        seem to be conflating 
    
                        authentication with authorization by assuming
                        the identity drives 
    
                        what the resource is. 
    
                        
    
                        There are lots of applications that require user
                        rights but are not 
    
                        identify centric. For example a document
                        service. 
    
                        
     
    
                          Unless the client tells the AS where it
                          intends to use the token we 
    
                          will be leaving a security hole because the
                          bearer tokens will have 
    
                          too loose an audience if they have one at all.
                          
    
                        
    
                        This is the biggest risk we have IMHO. 
    
                        
     
    
                          True you are telling the AS (Webfinger
                          service) what the RS is but 
    
                          that is not at a place that is useful in the
                          token production process. 
    
                        
    
                        
    
                        This has nothing to do with token production. =

    
                        
    
                        What we want to ensure is whether an honest
                        client is correctly 
    
                        configured and has not been mislead - eg by a
                        phishing page. 
    
                        
     
    
                          I also think there are use cases where the AS
                          doesn=E2=80=99t know all the 
    
                          possible RS.   That is not something =
that a
                          out of band check can 
    
                          address. 
    
                        
    
                        
    
                        May be. Lets identify them. 
    
                        
    
                        
    There are =
also
                          cases where a token might be good at multiple
                          RS 
    
                          endpoints intentionally. 
    
                        
    
                        
    
                        
     In =
your
                          solution the client would need to make a
                          discovery request 
    
                          for each endpoint. 
    
                        
    
                        Sure. Otherwise how would it know if there is
                        one AS or a pool of AS 
    
                        servers assigned to each instance? 
    =

                        
    Those =
requests
                          lack the context of who the client and
                          resource owner 
    
                          are.  I think that will be a problem in =
some
                          use cases. 
    
                        
    
                        
    
                        Not sure I agree. This is about discovering a
                        valid set of endpoints. 
    
                        For mitm, we mainly want to check the hostname
                        is correct. If a 
    
                        client chooses evil.com <http://evil.com/>
                        the cert can be valid and 
    
                        TLS will pass. How does it otherwise know it is
                        supposed to talk to 
    
                        res.example.com
                        <http://res.example.com/>?
                        
    
                        
     
    
                          If this is added to the token endpoint it
                          would be checked when code 
    
                          or refresh are exchanged, not every time the
                          token is used. 
    
                        
    
                        Your proposal requires rhe client to check. I am
                        not clear how the AS 
    
                        can know the exact uri. It is far easier to
                        validate than to lookup 
    
                        since as you say the client may be authorized to
                        use multiple ASs. 
    
                        
    With a out =
of
                          band check the client would never know if a RS
                          was 
    
                          removed/revoked. 
    
                        
    
                        
    
                        Not sure that is in scope. 
    
                        
    
                        None of the current proposals address this
                        issue. 
    
                        
     
    
                          I don=E2=80=99t see checking when refreshing a =
token
                          as something that is a 
    
                          huge burden. 
    
                        
    
                        
    
                        Still its a lot more than once. 
    
                        
    
                        Why don't you draft another alternative? 
    
                        
     
    
                          If the server wants to do the check on it=E2=80=99=
s
                          side then we could 
    
                          require the client to send the RS URI in the
                          token request. that way 
    
                          you really know the client is not going to get
                          a token for the wrong 
    
                          RS endpoint. 
    
                          If you check out of band in discovery you
                          really have no idea if the 
    
                          client is checking. 
    
                        
    
                        
    
                        In the new webfinger draft, the client isn't
                        checking. The service 
    
                        provider simply does not disclose oauth
                        information to misconfigured 
    
                        clients. 
    
                        
     
    
                          John B. 
    
                          
    
                          
    
                          
    On Mar =
14,
                            2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com
                            
    
                            <mailto:phil.hunt@oracle.com>>
                            wrote: 
    
                            
    
                            Thanks to Mike and John for their =
feedback. 
                            I=E2=80=99ll take each in turn: 
    
                            
    
                            Mike, 
    
                            
    
                            Regarding your suggested amendments 
    
                            
    
                            Item 1: Returning the config URL would
                            create two problems. One,it 
    
                            makes bound discovery a two-step process -
                            that adds complexity. 
    
                             It seems far simpler to mandate TLS =
(which
                            I think it already does 
    
                            in the security considerations). 
    
                            
    
                            The two-step process allows the current
                            discovery process to 
    
                            continue. I disagree with this. This is why
                            I put forward an 
    
                            =E2=80=9Calternate" draft that is almost the =
same
                            but simply adds the check 
    
                            before returning the configuration =
data.  I
                            worry that  developers 
    
                            would have no incentive to do the two-step
                            approach. They would 
    
                            just start at step 2 which in turn puts =
AS=E2=80=99s
                            at risk of exposing 
    
                            tokens because it works. This makes OAuth
                            promiscuous. 
    
                            
    
                            Regarding existing implementations. Most of
                            those implementations 
    
                            are for OIDC.  I think it makes sense =
for
                            OIDF to continue use of 
    
                            OIDC's discovery spec because the UserInfo
                            endpoint is well defined 
    
                            and the likelihood of a client mis-informed
                            about the resource 
    
                            endpoint is not there.  IMO This does =
not
                            apply to the broader 
    
                            OAuth community. 
    
                            
    
                            Item 2:  It may be appropriate to have =
a
                            separate configuration 
    
                            registry specification, but I think we
                            should hold off until we 
    
                            have a complete solution and then make the
                            decision what drafts 
    
                            should exist and how many pieces.  A =
big
                            concern is the perceived 
    
                            complexity of multiple solutions and
                            multiple drafts. 
    
                            
    
                            As to John Bradley=E2=80=99s comments: 
    
                            
    
                            Re: Discovery is the wrong place to mitigate
                            threats. 
    
                            I=E2=80=99m confused by this.  Our =
mandate was to
                            solve a security threat 
    
                            by having a discovery specification to
                            prevent clients being 
    
                            mis-lead about endpoints (of which resource
                            service is one) in an 
    
                            oauth protected exchange.  Maybe what =
you
                            mean is we should not use 
    
                            .well-known of any kind and we should just
                            create a =E2=80=9C/Config=E2=80=9D 
    
                            endpoint to OAuth? 
    
                            
    
                            Re: Your proposal for MITM mitigation 
    
                            You propose that instead the resource
                            endpoint check should be in 
    
                            the oauth protocol itself.  The =
difference
                            is that validation is 
    
                            transferred back to the client to get it
                            right. As well, without 
    
                            the client informing the AS, I can=E2=80=99t =
see a
                            way for the AS to know 
    
                            what endpoint the client is using.  The
                            webfinger approach does 
    
                            this once and only requires that the host
                            name be checked in many 
    
                            cases. 
    
                            
    
                            As a principle, the members have discussed
                            many times that the AS 
    
                            service should do validation when possible =
=E2=80=94
                            this was particularly 
    
                            true at the Germany meeting when this came
                            up. This is why I prefer 
    
                            the client tell the service provider what it
                            intends to do and the 
    
                            service provider can fail that request
                            immediately if necessary. We 
    
                            don=E2=80=99t have to depend on the =
developer
                            getting the spec correct to 
    
                            fail the correct way. 
    
                            
    
                            I worry that adding more parameters to the
                            authz and token protocol 
    
                            flows increases complexity and attack
                            surface. It also means per 
    
                            authorization validation has to take place
                            vs. a one-time 
    
                            validation at config time.  Placing it =
in
                            the configuration lookup 
    
                            phase (whether via web finger or just a
                            special OAuth endpoint) 
    
                            seems more appropriate and far less complex
                            - as the request itself 
    
                            is simple and has only one parameter. Here
                            we are not considered 
    
                            about legitimacy of the client. we=E2=80=99re =
just
                            concerned with the issue 
    
                            "has the client been correctly informed?=E2=80=
=9D 
    
                            
    
                            That said, it may be that when we consider
                            all the use cases, some 
    
                            combination of AS protocol and discovery may
                            be both needed. I=E2=80=99m 
    
                            not ready to make conclusions about =
this. 
                            The current 
    
                            oauth-discovery spec seems to put future
                            generic clients at risk 
    
                            and that is my primary concern. 
    
                            
    
                            Best Regards, 
    
                            
    
                            Phil 
    
                            
    
                            @independentid 
    
                                www.independentid.com
                            <http://www.independentid.com/&g=
t;
                            
    
                            phil.hunt@oracle.com
                            <mailto:phil.hunt@oracle.com>
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    
                            
    On Mar =
13,
                              2016, at 10:28 PM, Mike Jones 
    
                              <    Michael.Jones@microsoft.com
                              <mailto:Michael.Jones@micro=
soft.com>>

                              
    
                              wrote: 
    
                              
    
                              Thanks for posting this, Phil.  It
                              provides a concrete example of 
    
                              a way that protected resource discovery
                              could be added to 
    
                              authorization server metadata discovery,
                              and as such, should 
    
                              provide useful input for working group
                              discussions on this topic. 
    
                              It=E2=80=99s always great when someone =
takes the
                              time to write an actual 
    
                              draft that can be examined and
                              implemented, and I appreciate you 
    
                              doing that. 
    
                              The content of your draft points out that
                              there appears to be 
    
                              complete agreement on what the
                              authorization server metadata 
    
                              format should be, which is great!  =
I=E2=80=99ll
                              note that Section 3 of 
    
                              draft-hunt-oauth-bound-config-00 titled
                              =E2=80=9CAuthorization Server 
    
                              Metadata=E2=80=9D is an exact copy of =
Section 2 of
                              
    
                              draft-ietf-oauth-discovery-01 (with the
                              same title), modulo 
    
                              applying a correction suggested by the
                              working group.  To me this 
    
                              suggests that the authorization server
                              metadata definitions in 
    
                              draft-ietf-oauth-discovery (which is now
                              the whole normative 
    
                              content of the draft) are clearly ready
                              for standardization, since 
    
                              even your alternative proposal includes
                              them verbatim. 
    
                              Reading your draft, the problem I have
                              with it is that you are 
    
                              returning the AS metadata only as a
                              WebFinger response, rather 
    
                              than as an https-protected resource
                              published by the authorization 
    
                              server.  The choice to only return =
this
                              via WebFinger makes your 
    
                              draft incompatible with most deployed
                              implementations of OAuth 
    
                              metadata, including the 22 implementations
                              using it listed 
    
                              athttp://openid.net/certification/(see
                              the =E2=80=9COP Config=E2=80=9D column in =

    
                              the table) andOAuth 2.0 libraries such as
                              Microsoft=E2=80=99s =E2=80=9CADAL=E2=80=9D =

    
                              library, which uses the metadata path for
                              client configuration. 
    
                              Without having ASs provide the metadata as
                              an https-protected 
    
                              resource, implementations such as ADAL
                              can=E2=80=99t use it for client 
    
                              configuration as the currently do. 
    
                              Therefore, I would request that you make
                              these minor revisions to 
    
                              your draft and republish, so as to provide
                              a unified way forward 
    
                              that is compatible with all known existing
                              OAuth Discovery 
    
                              deployments: 
    
                              1.Modify your section 2 =E2=80=9CAuthorizati=
on
                              Server WebFinger Discovery=E2=80=9D 
    
                              to have the WebFinger request return the
                              issuer identifier for the 
    
                              AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=
=80=9D value, rather
                              than returning the 
    
                              metadata values by value as the
                              =E2=80=9Cproperties=E2=80=9D value. 
    
                              2.Reference the metadata definitions from
                              Section 2 of 
    
                              draft-ietf-oauth-discovery, rather than
                              duplicating them in your 
    
                              Section 3. 
    
                              That would have the advantage of paring
                              your draft down to only 
    
                              the new things that it proposes, enabling
                              them to be more clearly 
    
                              understood and evaluated on their own
                              merits.  I look forward to 
    
                              the discussions of ways of performing
                              additional kinds of OAuth 
    
                              discovery, and consider your draft a
                              valuable input to those 
    
                              discussions. 
    
                              =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       

                              Best wishes, 
    
                              =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       

                              -- Mike 
    
                              *From:*OAuth [mailto:oauth-bounces@ietf.org]*=
On
                              Behalf Of*John Bradley 
    
                              *Sent:*Sunday, March 13, 2016 6:45 PM 
    
                              *To:*Phil Hunt <phil.hunt@oracle.com
                              <mailto:phil.hunt@oracle.com>>

                              
    
                              *Cc:*oauth <    oauth@ietf.org
                              <mailto:oauth@ietf.org>>

                              
    
                              *Subject:*Re: [OAUTH-WG] New Version
                              Notification for 
    
                              draft-hunt-oauth-bound-config-00.txt 
    
                              As I have told Phil off list. 
    
                              Discovery is the wrong place to try and
                              provide security against 
    
                              man in the middle attacks on the RS. 
    
                              This requires the client to know what the
                              RS URI is before 
    
                              retrieving the information on the AS
                              Configuration. 
    
                              The proposal Mike and I have been working
                              on requires the client 
    
                              to have a notion of what API it is looking
                              for and retrieve the 
    
                              .well-known file for that API from the
                              issuer.   That allows a 
    
                              protocol like Connect to register its own
                              config file that can 
    
                              point to the RS. 
    
                              If the API specific well known is not
                              available the client can try 
    =

                              the default oauth-server one. 
    
                              That then allows us to deal with
                              restricting where AT are 
    
                              presented as part of the protocol rather
                              then dragging discovery 
    
                              in as a requirement. 
    
                              In my opinion the resource the token is
                              targeted to should be 
    
                              separated from the scope and returned as
                              part of the meta-data 
    
                              about the AT along with scopes granted and
                              expiry time.   We 
    
                              should also have a input parameter for
                              resources so that a client 
    
                              can restrict tokens issued to a subset of
                              the ones granted by the 
    
                              refresh token.   It would then =
also be
                              possible to ask a AS for a 
    
                              token for a unregistered RS and have the
                              AS produce a JWT access 
    
                              token with the resource as an audience if
                              policy allows. 
    
                              That however was supposed to be dealt with
                              as part of the mixed up 
    
                              client set of mitigations. 
    
                              In that the goal was to mitigate the
                              attacks by returning 
    
                              meta-data about the tokens, and not to
                              require discovery. 
    
                              We intend to return =E2=80=9Ciss=E2=80=9D =
and =E2=80=9Ccleint_id=E2=80=9D
                              for the code, and I 
    
                              intend to discuss at the F2F returning
                              resource for AT as well. 
    
                              Those mitigate the attack. 
    
                              I will continue to resist mixing up
                              discovery of configuration 
    
                              meta-data with mitigation of the attacks.
                              
    
                              We return meta-data about the tokens now,
                              because AT are opaque to 
    
                              the client, we neglected to include some
                              of the information for 
    
                              the client needs to be secure.   =
We just
                              need to add that in to 
    
                              the existing flows. 
    
                              While Phil=E2=80=99s proposal is easier =
for the AS
                              to implement as an add 
    
                              on, it puts more of a burden on the client
                              needing to potentially 
    
                              change how it stores the relationships
                              between AS and RS to 
    
                              prevent compromise, I think the solution
                              should be biased towards 
    
                              simplicity on the client side. 
    
                              If we return the resources as part of the
                              existing meta data the 
    
                              client checks that against the resource it
                              intends to send the 
    
                              token to and if it is not in the list then
                              it can=E2=80=99t send the 
    
                              token.  Simple check every time it =
gets a
                              new AT, no optionality. 
    
                              I am not saying anything new Nat has been
                              advocating basically 
    
                              this for some time, and dis submit a
                              draft.   I prefer to return 
    
                              the info in the existing format rather
                              than as link headers,  but 
    
                              that is the largest difference between
                              what Nat and I are saying 
    
                              with respect to resource. 
    
                              That is the core of my problem with =
Phil=E2=80=99s
                              draft. 
    
                              I guess we will need to have a long
                              conversation in BA. 
    
                              Regards 
    
                              John B. 
    
                              
    
                                  On Mar 13, 2016, at =
8:12 PM, Phil Hunt
                              <phil.hunt@oracle.com
                              
    
                                  <mailto:phil.hunt@oracle.com>>
                              wrote: 
    
                                  This draft is a =
proposed alternate
                              proposal for 
    
                                  =
draft-ietf-oauth-discovery.  As such,
                              it contains the same 
    
                                  registry for OAuth =
Config Metadata as
                              the authors believe that 
    
                                  both solutions are not =
required, or
                              depending on WG discussion 
    
                                  they will be merged. =
The intent is to
                              provide a simple 
    
                                  complete draft for =
consideration. 
    
                                  How it works... 
    
                                  Given that a client has =
previously
                              discovered an OAuth 
    
                                  protected resource, the =
bound
                              configuration method allows a 
    
                                  client to return the =
configuration for
                              an oauth authorization 
    
                                  server that can issue =
tokens for the
                              resource URI specified by 
    
                                  the client.  The =
AS is not required to
                              be in the same domain. 
    
                                   The AS is however =
required to know if
                              it can issue tokens for 
    
                                  a resource service =
(which presumes
                              some agreement exists on 
    
                                  tokens etc). 
    
                                  The draft does not =
require that the
                              resource exist (e.g. for 
    
                                  unconfigured or new =
user based
                              resources). It only requires 
    =

                                  that the AS service =
provider agrees it
                              can issue tokens. 
    
                                  =46rom a security =
perspective, returning
                              the OAuth service 
    
                                  configuration for a =
specified resource
                              URI serves to confirm 
    
                                  the client is in =
possession of a valid
                              resource URI ensuring 
    
                                  the client has received =
a valid set of
                              endpoints for the 
    
                                  resource and the =
associated oauth
                              services. 
    
                                  I propose that the WG =
consider the
                              alternate draft carefully 
    
                                  as well as other =
submissions and
                              evaluate the broader 
    
                                  discovery problem =
before proceeding
                              with WGLC on OAuth Discovery. 
    
                                  Thanks! 
    
                                  Phil 
    
                                  @independentid 
    
                                      www.independentid.com
                              <http://www.independentid.com/&g=
t;
                              
    
                                  phil.hunt@oracle.com
                              <mailto:phil.hunt@oracle.com>
                              
    
                              
    
                              
    
                                      =
Begin forwarded message: 
    
                                      =
*From:*    internet-drafts@ietf.org 
    
                                      =
<mailto:internet-drafts@ietf.o=
rg>
                              
    
                                      =
*Subject: New Version Notification
                              for 
    
                                     
                              draft-hunt-oauth-bound-config-00.txt* 
    
                                      =
*Date:*March 13, 2016 at 3:53:37
                              PM PDT 
    
                                      =
*To:*"Phil Hunt" <phil.hunt@yahoo.com
                              
    
                                      =
<mailto:phil.hunt@yahoo.com>=
>,

                              "Anthony Nadalin" 
    
                                      =
<tonynad@microsoft.com
                              <mailto:tonynad@microsoft.com>=
>,

                              
    
                                      =
"Tony Nadalin" <tonynad@microsoft.com
                              
    
                                      =
<mailto:tonynad@microsoft.com>=
>

                              
    
                              
    
                              
    
                                      =
A new version of I-D,
                              draft-hunt-oauth-bound-config-00.txt 
    
                                      =
has been successfully submitted by
                              Phil Hunt and posted to the 
    
                                      =
IETF repository. 
    
                              
    
                                      =
Name:draft-hunt-oauth-bound-config
                              
    
                                      =
Revision:00 
    
                                      =
Title:OAuth 2.0 Bound
                              Configuration Lookup 
    
                                      =
Document date:2016-03-13 
    
                                      =
Group:Individual Submission 
    
                                      =
Pages:22 
    
                                      =
URL: 
    
                                     
                              https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-confi=
g-00.txt
    
                                      =
Status: 
    
                                      =
h=
ttps://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                              
    
                                      =
Htmlized: 
    
                                      =
http=
s://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                              
    
                              
    
                              
    
                                      =
Abstract: 
    
                              =
          This =
specification defines a
                              mechanism for the client of 
    
                                      =
an OAuth 2.0 
    
                              =
          protected =
resource service to
                              obtain the configuration 
    
                                      =
details of an 
    
                              =
          OAuth 2.0 =
authorization server
                              that is capable of 
    
                                      =
authorizing access 
    
                              =
          to a specific =
resource service. 
                              The information 
    
                                      =
includes the OAuth 
    
                              =
          2.0 component =
endpoint location
                              URIs and as well as 
    
                                      =
authorization 
    
                              =
          server =
capabilities. 
    
                              
    
                              
    
                              
    
                              
    
                                      =
Please note that it may take a
                              couple of minutes from the 
    
                                      =
time of submission 
    
                                      =
until the htmlized version and
                              diff are available 
    
                                      =
attools.ietf.org
                              <http://tools.ietf.org/>.
                              
    
                              
    
                                      =
The IETF Secretariat 
    
                              
    
                                 
                              =
_______________________________________________
                              
    
                                  OAuth mailing list 
    
                                  OAuth@ietf.org
                              <mailto:OAuth@ietf.org>
                              
    
                                  https://www.ietf.org/=
mailman/listinfo/oauth
                              
    
                            
    
                            
    
                          
    
                          
    
                        
    
                      
    
                      
    
                      _______________________________________________ =

    
                      OAuth mailing list 
    
                      OAuth@ietf.org
                      <mailto:OAuth@ietf.org>
                      
    
                      https://www.ietf.org/=
mailman/listinfo/oauth
                      
    
                    
    
                    
    
                    
    
                    
    
                    _______________________________________________ 
    
                    OAuth mailing list 
    
                    OAuth@ietf.org 
    
                    https://www.ietf.org/=
mailman/listinfo/oauth
                    
    
                    
    
                  
    
                  
    
                
    
                
    
              
    
            
    
          
    
        
    
        
    
      
    
    
    
    
    
  
    



    =

--Apple-Mail=_E0173164-BCFE-486D-8BEC-B51574758E38--

--Apple-Mail=_4F9A4862-8D2D-43D2-99E5-55975C455FAB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxNzQzMDdaMCMGCSqGSIb3DQEJBDEWBBSvNaC9K3yRpGL+LrIuMQGT
TQLq/TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAqxyp0QAIvCmiBakky7LbeaZBzx7GWdtgmu10QfePWzP6zVOddfeo5
a//TKWEa3nVL6v6ZvqMmpqIK9hW5jhaIaN9sdfwCHJz4hQKc0VaVjbfGcpbKGoj0Uy4O27q6OdDq
riGiu63PMXQfBrKgzSv8NROdx3KApl5tMrmv0i1lsAbvfYqTXEgVgeWq98ku0y4WTu0C3uR5+GMb
4+dSAfCgIJY79MJw9k0+2ro/Fxs2PQgM0nNv8899Wr0qRdUAly08prfspQHINxAvm13CQFUQNq+D
ivGkUi1mpQ9toHTh5FrYHkpFzqO71YUxtzoX+LvVjl8Ct23FkFhP4zu1Jrf5AAAAAAAA
--Apple-Mail=_4F9A4862-8D2D-43D2-99E5-55975C455FAB--


From nobody Tue Mar 15 10:45:16 2016
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 C8E2412DBDD for ; Tue, 15 Mar 2016 10:45:15 -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=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 0XrSy962CAil for ; Tue, 15 Mar 2016 10:45:11 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 B3C4512DBD8 for ; Tue, 15 Mar 2016 10:45:10 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id m184so33297869iof.1 for ; Tue, 15 Mar 2016 10:45:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NqdHGjYjz0v2MIigYTAsUtdjJsvTK3pPVVeHbTzX+9c=; b=lRnFhLCBg5WkQb2yGunhe1rKhqSG3IgHy4gBpXBsxsm94/LSRx71D/YWDZvPSVIQf6 mqvQmh9j7kkZgKr8ODORmPOVaCunoHavShln1UjYwrCiZXPhvpcrdgINS8B+zg+oFRgB 0Ww5UtAqQZIme4/ZcWXFwZGRBVxTxj17CuexY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NqdHGjYjz0v2MIigYTAsUtdjJsvTK3pPVVeHbTzX+9c=; b=Xsn6tMr0EhRMVhThGKCIP+lvYWPn08z/fQt+EfYdF/gsA1WcZEaUSeSiyUqoxmG/Lx 0OJCZDPp8Wgpc2H7QhSg7XbIWG4xFczKDg6qnqMW0SdeYrpynY49RUkLrA+JGCi456/d uq57aLvOWsjx9TVxRo5hxxEp5KkINmhxhnIQ/7QLyp6tHgJHZMXYUIF11/P4WJdxA3Z6 Q7AfEq8oeZZNixzpsIo0nY+BJd0QVSqEYtKQqdKoAxvNMBXyAFc0KH6lc9drwhlrOVbP HAhvrl+8d+rj2ShMUbO6GUvb3wAsZpk/PAWtfzKJhl8/gAWaAKyVD2ojiT/a4VO9Ei1f ITwQ==
X-Gm-Message-State: AD7BkJK9mhLDapqR6C7bKXwoDxwAyns+hRHJFaeodlOODu4/rW5JR5idHYEFRxWKpcEazuVQUQvqgf6ZzeDyYF+u
X-Received: by 10.107.137.152 with SMTP id t24mr35878148ioi.147.1458063909857;  Tue, 15 Mar 2016 10:45:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 15 Mar 2016 10:44:39 -0700 (PDT)
In-Reply-To: <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>
From: Brian Campbell 
Date: Tue, 15 Mar 2016 11:44:39 -0600
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a113f9022688e3a052e19f552
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:45:16 -0000

--001a113f9022688e3a052e19f552
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I was thinking it'd be simpler to error, if the requested resource(s)
weren't okay. That puts the burden of checking in the AS. And doesn't add
anything to the token or authorization response. I see the potential
similarity to scope but not sure it's worth it.

On Tue, Mar 15, 2016 at 11:37 AM, John Bradley  wrote:

> If the client specifies the resource it wants the token for, then the
> meta-data would not be required unless the resources the token is good at
> are different from the request.
> Lat is the same logic as scopes.
>
> For backwards compatibility if the client is happy with the default
> resources based on scopes then I think it is a good idea to tell the clie=
nt
> what the resources are in the response.
>
> I suspect that it is simpler with less optionality and always return the
> resources, even if they are not required.
>
> John B.
>
> On Mar 15, 2016, at 12:46 PM, Brian Campbell 
> wrote:
>
> If the client specifies the desired audience(s)/resource(s), is that
> metadata to the client needed? The AS can audience restrict the token as
> needed or respond with an error if it can't or wont issue a token for the
> resource the client asked for.
>
> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  wrote:
>
>> Yes,  I think bearer tokens with no audience are a bad idea.
>>
>> The AS needs to infer an audience from the scopes snd/or have the client
>> specify the desired audience.
>>
>> If the AT has a audience or audiences then as long as the endpoint URI
>> are provided as meta-data with the token, the client can determine if it=
 is
>> sending the token to the correct place.
>>
>> I think Phil would prefer the server rather than the client do the check=
,
>> but the client always needs to take some responsibility to not leak toke=
ns
>> giving them to the wrong RS or the code to the wrong token endpoint is
>> leaking.
>>
>> I imagine that claims based access tokens are going to become more
>> popular and the static relationship between one RS and one AS will not b=
e
>> the majority of deployments over time.
>>
>> In any case where the client is configured up front to know the RS and
>> the AS it seems like that would not require Phil=E2=80=99s Solution, but=
 that is
>> the only case supported by that discovery.
>>
>> If the client itself is bad there is not much you can do to stop it from
>> passing on the AT in way way it wants.  That however is a different prob=
lem
>> and needs claimed URI or attestations to prevent client spoofing.
>> William and I are working on that in the mobile best practices draft.
>>
>> John B.
>>
>>
>> On Mar 15, 2016, at 12:09 PM, George Fletcher  wrote:
>>
>> I worry about two directions I see in this thread...
>>
>> 1. Client's accessing resources dynamically so that discovery is require=
d
>> to know the correct AS, etc. This is pretty much the classic use case fo=
r
>> UMA and I'd rather not re-invent the wheel.
>>
>> 2. Creating a tight coupling between RS and AS such that RS endpoint
>> changes must be continually communicated to the AS. If an RS supports
>> multiple AS's then the RS has to deal with "guaranteed" delivery. The AS
>> needs an endpoint to receive such communications. If not dynamic via API=
s,
>> then deployment of the new RS is bound by the associated AS's getting an=
d
>> deploying the new endpoints. Can both endpoints of the RS be supported
>> within the AS for some period of time, etc. This is an operation nightma=
re
>> and almost assuredly going to go wrong in production.
>>
>> Maybe an OAuth2 "audience binding" spec is what's needed for those
>> deployments that require this. I believe that is what John Bradley is
>> suggesting.
>>
>> Thanks,
>> George
>>
>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>
>> +1, I've found the very same in OAuth deployments that I was involved in=
;
>> the hard part is to give names and descriptions to these concepts so tha=
t
>> they cover all use cases and can be applied unambiguously
>>
>> Hans.
>>
>> On 3/14/16 10:44 PM, Justin Richer wrote:
>>
>> I agree that this is valuable, and not just for PoP. In all honesty,
>> it=E2=80=99s not even really required for PoP to function in many cases =
=E2=80=94 it=E2=80=99s
>> just an optimization for one particular kind of key distribution
>> mechanism in that case.
>>
>> In the years of deployment experience with OAuth 2, I think we=E2=80=99v=
e really
>> got three different kinds of things that currently get folded into
>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out better:
>>
>>
>>   - What things do I want to access? (photos, profile)
>>   - What actions do I want to take on these things? (read, write, delete=
)
>>   - How long do I want these tokens to work?
>> (offline_access/refresh_token, one time use, next hour, etc)
>>
>>
>> I think the first one is close to the audience/resource parameters that
>> have been bandied about a few times, including in the current token
>> exchange document. We should be consistent across drafts in that regard.
>> The second is more traditional scope-ish. The third has been patched in
>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.
>>
>> Just another vector to think about if we=E2=80=99re going to be adding t=
hings
>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or both to=
 the token requests.
>>
>>   =E2=80=94 Justin
>>
>>
>> On Mar 14, 2016, at 6:26 PM, John Bradley >  > wrote:
>>
>> Yes I will work on another proposal for allowing clients to specify
>> what resource they want a token for and providing the meta-data to the
>> client about the resources that a token is valid for.
>>
>> We have part of it in the POP key distribution spec and talked about
>> separating it, as it is used more places than just for assigning keys.
>> I know some AS use different token formats for different RS so are
>> all-ready needing to pass the resource in the request to avoid making
>> a mess of scopes.
>>
>> John B.
>>
>>
>>
>>
>>
>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >  > wrote:
>>
>> Inline
>>
>> Phil
>>
>> On Mar 14, 2016, at 14:13, John Bradley >  > wrote:
>>
>> We had two mandates.  One was to provide a spec for AS metadata.
>> The other was to mitigate the client mixup attack.  The request was
>> to do the latter without requiring the former for clients that don=E2=80=
=99t
>> otherwise need discovery.
>>
>> There is no mandate for any of this. See
>> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.=
txt
>>
>>
>> Returning the issuer and client_id from the authorization endpoint
>> and the client checking them can be done by the client without
>> discovery.
>>
>>
>> How does this address the issue of whether the client is talking to
>> the wrong endpoint?
>>
>>
>> Any client that has the resource and issuer hard coded probably
>> doesn=E2=80=99t need discovery.
>>
>> We agree
>>
>>
>> One of the things that a client will need discovery for is to find
>> the RS, so requiring the client to know the RS URI before getting
>> the AS config seems backwards to me.
>>
>> How can you make an assumption on order? You seem to be conflating
>> authentication with authorization by assuming the identity drives
>> what the resource is.
>>
>> There are lots of applications that require user rights but are not
>> identify centric. For example a document service.
>>
>>
>> Unless the client tells the AS where it intends to use the token we
>> will be leaving a security hole because the bearer tokens will have
>> too loose an audience if they have one at all.
>>
>> This is the biggest risk we have IMHO.
>>
>>
>> True you are telling the AS (Webfinger service) what the RS is but
>> that is not at a place that is useful in the token production process.
>>
>>
>> This has nothing to do with token production.
>>
>> What we want to ensure is whether an honest client is correctly
>> configured and has not been mislead - eg by a phishing page.
>>
>>
>> I also think there are use cases where the AS doesn=E2=80=99t know all t=
he
>> possible RS.   That is not something that a out of band check can
>> address.
>>
>>
>> May be. Lets identify them.
>>
>> There are also cases where a token might be good at multiple RS
>> endpoints intentionally.
>>
>>
>>  In your solution the client would need to make a discovery request
>> for each endpoint.
>>
>> Sure. Otherwise how would it know if there is one AS or a pool of AS
>> servers assigned to each instance?
>>
>> Those requests lack the context of who the client and resource owner
>> are.  I think that will be a problem in some use cases.
>>
>>
>> Not sure I agree. This is about discovering a valid set of endpoints.
>> For mitm, we mainly want to check the hostname is correct. If a
>> client chooses evil.com   the cert
>> can be valid and
>> TLS will pass. How does it otherwise know it is supposed to talk to
>> res.example.com  ?
>>
>>
>> If this is added to the token endpoint it would be checked when code
>> or refresh are exchanged, not every time the token is used.
>>
>> Your proposal requires rhe client to check. I am not clear how the AS
>> can know the exact uri. It is far easier to validate than to lookup
>> since as you say the client may be authorized to use multiple ASs.
>>
>> With a out of band check the client would never know if a RS was
>> removed/revoked.
>>
>>
>> Not sure that is in scope.
>>
>> None of the current proposals address this issue.
>>
>>
>> I don=E2=80=99t see checking when refreshing a token as something that i=
s a
>> huge burden.
>>
>>
>> Still its a lot more than once.
>>
>> Why don't you draft another alternative?
>>
>>
>> If the server wants to do the check on it=E2=80=99s side then we could
>> require the client to send the RS URI in the token request. that way
>> you really know the client is not going to get a token for the wrong
>> RS endpoint.
>> If you check out of band in discovery you really have no idea if the
>> client is checking.
>>
>>
>> In the new webfinger draft, the client isn't checking. The service
>> provider simply does not disclose oauth information to misconfigured
>> clients.
>>
>>
>> John B.
>>
>>
>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >  > wrote:
>>
>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take each in t=
urn:
>>
>> Mike,
>>
>> Regarding your suggested amendments
>>
>> Item 1: Returning the config URL would create two problems. One,it
>> makes bound discovery a two-step process - that adds complexity.
>>  It seems far simpler to mandate TLS (which I think it already does
>> in the security considerations).
>>
>> The two-step process allows the current discovery process to
>> continue. I disagree with this. This is why I put forward an
>> =E2=80=9Calternate" draft that is almost the same but simply adds the ch=
eck
>> before returning the configuration data.  I worry that  developers
>> would have no incentive to do the two-step approach. They would
>> just start at step 2 which in turn puts AS=E2=80=99s at risk of exposing
>> tokens because it works. This makes OAuth promiscuous.
>>
>> Regarding existing implementations. Most of those implementations
>> are for OIDC.  I think it makes sense for OIDF to continue use of
>> OIDC's discovery spec because the UserInfo endpoint is well defined
>> and the likelihood of a client mis-informed about the resource
>> endpoint is not there.  IMO This does not apply to the broader
>> OAuth community.
>>
>> Item 2:  It may be appropriate to have a separate configuration
>> registry specification, but I think we should hold off until we
>> have a complete solution and then make the decision what drafts
>> should exist and how many pieces.  A big concern is the perceived
>> complexity of multiple solutions and multiple drafts.
>>
>> As to John Bradley=E2=80=99s comments:
>>
>> Re: Discovery is the wrong place to mitigate threats.
>> I=E2=80=99m confused by this.  Our mandate was to solve a security threa=
t
>> by having a discovery specification to prevent clients being
>> mis-lead about endpoints (of which resource service is one) in an
>> oauth protected exchange.  Maybe what you mean is we should not use
>> .well-known of any kind and we should just create a =E2=80=9C/Config=E2=
=80=9D
>> endpoint to OAuth?
>>
>> Re: Your proposal for MITM mitigation
>> You propose that instead the resource endpoint check should be in
>> the oauth protocol itself.  The difference is that validation is
>> transferred back to the client to get it right. As well, without
>> the client informing the AS, I can=E2=80=99t see a way for the AS to kno=
w
>> what endpoint the client is using.  The webfinger approach does
>> this once and only requires that the host name be checked in many
>> cases.
>>
>> As a principle, the members have discussed many times that the AS
>> service should do validation when possible =E2=80=94 this was particular=
ly
>> true at the Germany meeting when this came up. This is why I prefer
>> the client tell the service provider what it intends to do and the
>> service provider can fail that request immediately if necessary. We
>> don=E2=80=99t have to depend on the developer getting the spec correct t=
o
>> fail the correct way.
>>
>> I worry that adding more parameters to the authz and token protocol
>> flows increases complexity and attack surface. It also means per
>> authorization validation has to take place vs. a one-time
>> validation at config time.  Placing it in the configuration lookup
>> phase (whether via web finger or just a special OAuth endpoint)
>> seems more appropriate and far less complex - as the request itself
>> is simple and has only one parameter. Here we are not considered
>> about legitimacy of the client. we=E2=80=99re just concerned with the is=
sue
>> "has the client been correctly informed?=E2=80=9D
>>
>> That said, it may be that when we consider all the use cases, some
>> combination of AS protocol and discovery may be both needed. I=E2=80=99m
>> not ready to make conclusions about this.  The current
>> oauth-discovery spec seems to put future generic clients at risk
>> and that is my primary concern.
>>
>> Best Regards,
>>
>> Phil
>>
>> @independentid
>> www.independentid.com 
>> 
>> phil.hunt@oracle.com  
>>
>>
>>
>>
>>
>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>> 
>> >
>> wrote:
>>
>> Thanks for posting this, Phil.  It provides a concrete example of
>> a way that protected resource discovery could be added to
>> authorization server metadata discovery, and as such, should
>> provide useful input for working group discussions on this topic.
>> It=E2=80=99s always great when someone takes the time to write an actual
>> draft that can be examined and implemented, and I appreciate you
>> doing that.
>> The content of your draft points out that there appears to be
>> complete agreement on what the authorization server metadata
>> format should be, which is great!  I=E2=80=99ll note that Section 3 of
>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization Server
>> Metadata=E2=80=9D is an exact copy of Section 2 of
>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>> applying a correction suggested by the working group.  To me this
>> suggests that the authorization server metadata definitions in
>> draft-ietf-oauth-discovery (which is now the whole normative
>> content of the draft) are clearly ready for standardization, since
>> even your alternative proposal includes them verbatim.
>> Reading your draft, the problem I have with it is that you are
>> returning the AS metadata only as a WebFinger response, rather
>> than as an https-protected resource published by the authorization
>> server.  The choice to only return this via WebFinger makes your
>> draft incompatible with most deployed implementations of OAuth
>> metadata, including the 22 implementations using it listed
>> athttp://openid.net/certification/(see the =E2=80=9COP Config=E2=80=9D c=
olumn in
>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CA=
DAL=E2=80=9D
>> library, which uses the metadata path for client configuration.
>> Without having ASs provide the metadata as an https-protected
>> resource, implementations such as ADAL can=E2=80=99t use it for client
>> configuration as the currently do.
>> Therefore, I would request that you make these minor revisions to
>> your draft and republish, so as to provide a unified way forward
>> that is compatible with all known existing OAuth Discovery
>> deployments:
>> 1.Modify your section 2 =E2=80=9CAuthorization Server WebFinger Discover=
y=E2=80=9D
>> to have the WebFinger request return the issuer identifier for the
>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, rather than re=
turning the
>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D value.
>> 2.Reference the metadata definitions from Section 2 of
>> draft-ietf-oauth-discovery, rather than duplicating them in your
>> Section 3.
>> That would have the advantage of paring your draft down to only
>> the new things that it proposes, enabling them to be more clearly
>> understood and evaluated on their own merits.  I look forward to
>> the discussions of ways of performing additional kinds of OAuth
>> discovery, and consider your draft a valuable input to those
>> discussions.
>>                                                           Best wishes,
>>                                                           -- Mike
>> *From:*OAuth [mailto:oauth-bounces@ietf.org ]*On
>> Behalf Of*John Bradley
>> *Sent:*Sunday, March 13, 2016 6:45 PM
>> *To:*Phil Hunt 
>> >
>> *Cc:*oauth  >
>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-bound-config-00.txt
>> As I have told Phil off list.
>> Discovery is the wrong place to try and provide security against
>> man in the middle attacks on the RS.
>> This requires the client to know what the RS URI is before
>> retrieving the information on the AS Configuration.
>> The proposal Mike and I have been working on requires the client
>> to have a notion of what API it is looking for and retrieve the
>> .well-known file for that API from the issuer.   That allows a
>> protocol like Connect to register its own config file that can
>> point to the RS.
>> If the API specific well known is not available the client can try
>> the default oauth-server one.
>> That then allows us to deal with restricting where AT are
>> presented as part of the protocol rather then dragging discovery
>> in as a requirement.
>> In my opinion the resource the token is targeted to should be
>> separated from the scope and returned as part of the meta-data
>> about the AT along with scopes granted and expiry time.   We
>> should also have a input parameter for resources so that a client
>> can restrict tokens issued to a subset of the ones granted by the
>> refresh token.   It would then also be possible to ask a AS for a
>> token for a unregistered RS and have the AS produce a JWT access
>> token with the resource as an audience if policy allows.
>> That however was supposed to be dealt with as part of the mixed up
>> client set of mitigations.
>> In that the goal was to mitigate the attacks by returning
>> meta-data about the tokens, and not to require discovery.
>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_id=E2=80=
=9D for the code, and I
>> intend to discuss at the F2F returning resource for AT as well.
>> Those mitigate the attack.
>> I will continue to resist mixing up discovery of configuration
>> meta-data with mitigation of the attacks.
>> We return meta-data about the tokens now, because AT are opaque to
>> the client, we neglected to include some of the information for
>> the client needs to be secure.   We just need to add that in to
>> the existing flows.
>> While Phil=E2=80=99s proposal is easier for the AS to implement as an ad=
d
>> on, it puts more of a burden on the client needing to potentially
>> change how it stores the relationships between AS and RS to
>> prevent compromise, I think the solution should be biased towards
>> simplicity on the client side.
>> If we return the resources as part of the existing meta data the
>> client checks that against the resource it intends to send the
>> token to and if it is not in the list then it can=E2=80=99t send the
>> token.  Simple check every time it gets a new AT, no optionality.
>> I am not saying anything new Nat has been advocating basically
>> this for some time, and dis submit a draft.   I prefer to return
>> the info in the existing format rather than as link headers,  but
>> that is the largest difference between what Nat and I are saying
>> with respect to resource.
>> That is the core of my problem with Phil=E2=80=99s draft.
>> I guess we will need to have a long conversation in BA.
>> Regards
>> John B.
>>
>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt >      > wrote:
>>     This draft is a proposed alternate proposal for
>>     draft-ietf-oauth-discovery.  As such, it contains the same
>>     registry for OAuth Config Metadata as the authors believe that
>>     both solutions are not required, or depending on WG discussion
>>     they will be merged. The intent is to provide a simple
>>     complete draft for consideration.
>>     How it works...
>>     Given that a client has previously discovered an OAuth
>>     protected resource, the bound configuration method allows a
>>     client to return the configuration for an oauth authorization
>>     server that can issue tokens for the resource URI specified by
>>     the client.  The AS is not required to be in the same domain.
>>      The AS is however required to know if it can issue tokens for
>>     a resource service (which presumes some agreement exists on
>>     tokens etc).
>>     The draft does not require that the resource exist (e.g. for
>>     unconfigured or new user based resources). It only requires
>>     that the AS service provider agrees it can issue tokens.
>>     From a security perspective, returning the OAuth service
>>     configuration for a specified resource URI serves to confirm
>>     the client is in possession of a valid resource URI ensuring
>>     the client has received a valid set of endpoints for the
>>     resource and the associated oauth services.
>>     I propose that the WG consider the alternate draft carefully
>>     as well as other submissions and evaluate the broader
>>     discovery problem before proceeding with WGLC on OAuth Discovery.
>>     Thanks!
>>     Phil
>>     @independentid
>>     www.independentid.com 
>> 
>>     phil.hunt@oracle.com 
>> 
>>
>>
>>         Begin forwarded message:
>>         *From:*internet-drafts@ietf.org
>>          
>>         *Subject: New Version Notification for
>>         draft-hunt-oauth-bound-config-00.txt*
>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>         *To:*"Phil Hunt" >          >, "Anthony
>> Nadalin"
>>         
>> >,
>>         "Tony Nadalin" >          >
>>
>>
>>         A new version of I-D, draft-hunt-oauth-bound-config-00.txt
>>         has been successfully submitted by Phil Hunt and posted to the
>>         IETF repository.
>>
>>         Name:draft-hunt-oauth-bound-config
>>         Revision:00
>>         Title:OAuth 2.0 Bound Configuration Lookup
>>         Document date:2016-03-13
>>         Group:Individual Submission
>>         Pages:22
>>         URL:
>>
>> https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.tx=
t
>>         Status:
>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>         Htmlized:
>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>
>>
>>         Abstract:
>>           This specification defines a mechanism for the client of
>>         an OAuth 2.0
>>           protected resource service to obtain the configuration
>>         details of an
>>           OAuth 2.0 authorization server that is capable of
>>         authorizing access
>>           to a specific resource service.  The information
>>         includes the OAuth
>>           2.0 component endpoint location URIs and as well as
>>         authorization
>>           server capabilities.
>>
>>
>>
>>
>>         Please note that it may take a couple of minutes from the
>>         time of submission
>>         until the htmlized version and diff are available
>>         attools.ietf.org 
>> .
>>
>>         The IETF Secretariat
>>
>>     _______________________________________________
>>     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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>

--001a113f9022688e3a052e19f552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I was thinking it'd be simpler to error, if the reques=
ted resource(s) weren't okay. That puts the burden of checking in the A=
S. And doesn't add anything to the token or authorization response. I s=
ee the potential similarity to scope but not sure it's worth it.=C2=A0 =
=C2=A0 

    On T=
ue, Mar 15, 2016 at 11:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    If the client specifies the resource it wants the token for, then the =
meta-data would not be required unless the resources the token is good at a=
re different from the request. =C2=A0
    Lat is the same logic as scopes.<=
/div>

    For backwards compatibility if the client is happy=
 with the default resources based on scopes then I think it is a good idea =
to tell the client what the resources are in the response.

    I suspect that it is simpler with less optionality and always retu=
rn the resources, even if they are not required.

    J=
ohn B.

    On Mar 15, 2016, at 12:46 PM, Brian Campbell <bcampbell@pingidentit=
y.com> wrote:

    If the client specifies=
 the desired audience(s)/resource(s), is that metadata to the client needed=
? The AS can audience restrict the token as needed or respond with an error=
 if it can't or wont issue a token for the resource the client asked fo=
r. 

    =
On Tue, Mar 15, 2016 at 9:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    Yes, =C2=A0I think bearer tokens with no audienc=
e are a bad idea.

    The AS needs to infer an audience from=
 the scopes snd/or have the client specify the desired audience.
    =

    If the AT has a audience or audiences then as long as the en=
dpoint URI are provided as meta-data with the token, the client can determi=
ne if it is sending the token to the correct place.

    I think Phil would prefer the server rather than the client do the check,=
 but the client always needs to take some responsibility to not leak tokens=
 giving them to the wrong RS or the code to the wrong token endpoint is lea=
king.

    I imagine that claims based access tokens ar=
e going to become more popular and the static relationship between one RS a=
nd one AS will not be the majority of deployments over time.=C2=A0

    In any case where the client is configured up front to kno=
w the RS and the AS it seems like that would not require Phil=E2=80=99s Sol=
ution, but that is the only case supported by that discovery.
    =C2=
=A0=C2=A0
    If the client itself is bad there is not much you can d=
o to stop it from passing on the AT in way way it wants.=C2=A0 That however=
 is a different problem and needs claimed URI or attestations to prevent cl=
ient spoofing.
    William and I are working on that in the mobile be=
st practices draft.

    John B.


    On Mar 15, 2016, at 12:09 PM, Ge=
orge Fletcher <gff=
letch@aol.com> wrote:

    
 =20
   =20
 =20
  
    
    I worry about two
      directions I see in this thread...
    
      
    
      1. Client's accessing resources dynamically so that discovery is
      required to know the correct AS, etc. This is pretty much the
      classic use case for UMA and I'd rather not re-invent the wheel.<=
br>
      
    
      2. Creating a tight coupling between RS and AS such that RS
      endpoint changes must be continually communicated to the AS. If an
      RS supports multiple AS's then the RS has to deal with
      "guaranteed" delivery. The AS needs an endpoint to receive =
such
      communications. If not dynamic via APIs, then deployment of the
      new RS is bound by the associated AS's getting and deploying the
      new endpoints. Can both endpoints of the RS be supported within
      the AS for some period of time, etc. This is an operation
      nightmare and almost assuredly going to go wrong in production.
    
      
    
      Maybe an OAuth2 "audience binding" spec is what's neede=
d for those
      deployments that require this. I believe that is what John Bradley
      is suggesting.
    
      
    
      Thanks,
    
      George
    
    

    
    
    On 3/14/16 7:29 PM, Hans Zandbelt
      wrote:
    
    
    
    
    +1,
      I've found the very same in OAuth deployments that I was involved
      in; the hard part is to give names and descriptions to these
      concepts so that they cover all use cases and can be applied
      unambiguously
      
    
      
    
      Hans.
      
    
      
    
      On 3/14/16 10:44 PM, Justin Richer wrote:
      
    
      
    I agree that this is valuable, and not
        just for PoP. In all honesty,
        
    
        it=E2=80=99s not even really required for PoP to function in many c=
ases
        =E2=80=94 it=E2=80=99s
        
    
        just an optimization for one particular kind of key distribution
        
    
        mechanism in that case.
        
    
        
    
        In the years of deployment experience with OAuth 2, I think
        we=E2=80=99ve really
        
    
        got three different kinds of things that currently get folded
        into
        
    
        =E2=80=9Cscope=E2=80=9D that we might want to try separating out be=
tter:
        
    
        
    
        
    
        =C2=A0 - What things do I want to access? (photos, profile)
        
    
        =C2=A0 - What actions do I want to take on these things? (read,
        write, delete)
        
    
        =C2=A0 - How long do I want these tokens to work?
        
    
        (offline_access/refresh_token, one time use, next hour, etc)
        
    
        
    
        
    
        I think the first one is close to the audience/resource
        parameters that
        
    
        have been bandied about a few times, including in the current
        token
        
    
        exchange document. We should be consistent across drafts in that
        regard.
        
    
        The second is more traditional scope-ish. The third has been
        patched in
        
    
        with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.
        
    
        
    
        Just another vector to think about if we=E2=80=99re going to be add=
ing
        things
        
    
        like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or bo=
th to the token requests.
        
    
        
    
        =C2=A0 =E2=80=94 Justin
        
    
        
    
        
    
        
    On Mar 14, 2016, at 6:26 PM, John
          Bradley <ve7jtb@ve7jtb.com
          
    
          <mailto=
:ve7jtb@ve7jtb.com>> wrote:
          
    
          
    
          Yes I will work on another proposal for allowing clients to
          specify
          
    
          what resource they want a token for and providing the
          meta-data to the
          
    
          client about the resources that a token is valid for.
          
    
          
    
          We have part of it in the POP key distribution spec and talked
          about
          
    
          separating it, as it is used more places than just for
          assigning keys.
          
    
          I know some AS use different token formats for different RS so
          are
          
    
          all-ready needing to pass the resource in the request to avoid
          making
          
    
          a mess of scopes.
          
    
          
    
          John B.
          
    
          
    
          
    
          
    
          
    
          
    
          
    On Mar 14, 2016, at 7:17 PM, Phil Hunt
            (IDM) <phil.hunt@oracle.com
            
    
            <m=
ailto:phil.hunt@oracle.com>> wrote:
            
    
            
    
            Inline
            
    
            
    
            Phil
            
    
            
    
            On Mar 14, 2016, at 14:13, John Bradley
            <ve7j=
tb@ve7jtb.com
            
    
            <mail=
to:ve7jtb@ve7jtb.com>> wrote:
            
    
            
    
            
    We had two mandates.=C2=A0 One was to
              provide a spec for AS metadata.
              
    
              The other was to mitigate the client mixup attack.=C2=A0 The
              request was
              
    
              to do the latter without requiring the former for clients
              that don=E2=80=99t
              
    
              otherwise need discovery.
              
    
            
    
            There is no mandate for any of this. See
            
    
http://tools.ietf.org/wg/oauth/charters?item=
=3Dcharter-oauth-2016-01-22.txt
            
    
            
    
              
    
              Returning the issuer and client_id from the authorization
              endpoint
              
    
              and the client checking them can be done by the client
              without
              
    
              discovery.
              
    
            
    
            
    
            How does this address the issue of whether the client is
            talking to
            
    
            the wrong endpoint?
            
    
            
    
              
    
              Any client that has the resource and issuer hard coded
              probably
              
    
              doesn=E2=80=99t need discovery.
              
    
            
    
            We agree
            
    
            
    
            
    
            
    One of the things that a client will
              need discovery for is to find
              
    
              the RS, so requiring the client to know the RS URI before
              getting
              
    
              the AS config seems backwards to me.
              
    
            
    
            How can you make an assumption on order? You seem to be
            conflating
            
    
            authentication with authorization by assuming the identity
            drives
            
    
            what the resource is.
            
    
            
    
            There are lots of applications that require user rights but
            are not
            
    
            identify centric. For example a document service.
            
    
            
    
              
    
              Unless the client tells the AS where it intends to use the
              token we
              
    
              will be leaving a security hole because the bearer tokens
              will have
              
    
              too loose an audience if they have one at all.
              
    
            
    
            This is the biggest risk we have IMHO.
            
    
            
    
              
    
              True you are telling the AS (Webfinger service) what the
              RS is but
              
    
              that is not at a place that is useful in the token
              production process.
              
    
            
    
            
    
            This has nothing to do with token production.
            
    
            
    
            What we want to ensure is whether an honest client is
            correctly
            
    
            configured and has not been mislead - eg by a phishing page.
            
    
            
    
              
    
              I also think there are use cases where the AS doesn=E2=80=99t=
 know
              all the
              
    
              possible RS.=C2=A0=C2=A0 That is not something that a out of =
band
              check can
              
    
              address.
              
    
            
    
            
    
            May be. Lets identify them.
            
    
            
    
            
    There are also cases where a token
              might be good at multiple RS
              
    
              endpoints intentionally.
              
    
            
    
            
    
            
    =C2=A0In your solution the client wou=
ld
              need to make a discovery request
              
    
              for each endpoint.
              
    
            
    
            Sure. Otherwise how would it know if there is one AS or a
            pool of AS
            
    
            servers assigned to each instance?
            
    
            
    Those requests lack the context of
              who the client and resource owner
              
    
              are.=C2=A0 I think that will be a problem in some use cases.
              
    
            
    
            
    
            Not sure I agree. This is about discovering a valid set of
            endpoints.
            
    
            For mitm, we mainly want to check the hostname is correct.
            If a
            
    
            client chooses e=
vil.com <http://evil.=
com/> the cert
            can be valid and
            
    
            TLS will pass. How does it otherwise know it is supposed to
            talk to
            
    
            res.examp=
le.com <http:/=
/res.example.com/>?
            
    
            
    
              
    
              If this is added to the token endpoint it would be checked
              when code
              
    
              or refresh are exchanged, not every time the token is
              used.
              
    
            
    
            Your proposal requires rhe client to check. I am not clear
            how the AS
            
    
            can know the exact uri. It is far easier to validate than to
            lookup
            
    
            since as you say the client may be authorized to use
            multiple ASs.
            
    
            
    With a out of band check the client
              would never know if a RS was
              
    
              removed/revoked.
              
    
            
    
            
    
            Not sure that is in scope.
            
    
            
    
            None of the current proposals address this issue.
            
    
            
    
              
    
              I don=E2=80=99t see checking when refreshing a token as somet=
hing
              that is a
              
    
              huge burden.
              
    
            
    
            
    
            Still its a lot more than once.
            
    
            
    
            Why don't you draft another alternative?
            
    
            
    
              
    
              If the server wants to do the check on it=E2=80=99s side then=
 we
              could
              
    
              require the client to send the RS URI in the token
              request. that way
              
    
              you really know the client is not going to get a token for
              the wrong
              
    
              RS endpoint.
              
    
              If you check out of band in discovery you really have no
              idea if the
              
    
              client is checking.
              
    
            
    
            
    
            In the new webfinger draft, the client isn't checking. The
            service
            
    
            provider simply does not disclose oauth information to
            misconfigured
            
    
            clients.
            
    
            
    
              
    
              John B.
              
    
              
    
              
    
              
    On Mar 14, 2016, at 3:56 PM, Phil
                Hunt <phil.hunt@oracle.com
                
    
                &=
lt;mailto:phil.hunt@oracle.com>> wrote:
                
    
                
    
                Thanks to Mike and John for their feedback.=C2=A0 I=E2=80=
=99ll take
                each in turn:
                
    
                
    
                Mike,
                
    
                
    
                Regarding your suggested amendments
                
    
                
    
                Item 1: Returning the config URL would create two
                problems. One,it
                
    
                makes bound discovery a two-step process - that adds
                complexity.
                
    
                =C2=A0It seems far simpler to mandate TLS (which I think it
                already does
                
    
                in the security considerations).
                
    
                
    
                The two-step process allows the current discovery
                process to
                
    
                continue. I disagree with this. This is why I put
                forward an
                
    
                =E2=80=9Calternate" draft that is almost the same but =
simply
                adds the check
                
    
                before returning the configuration data.=C2=A0 I worry that=
=C2=A0
                developers
                
    
                would have no incentive to do the two-step approach.
                They would
                
    
                just start at step 2 which in turn puts AS=E2=80=99s at ris=
k of
                exposing
                
    
                tokens because it works. This makes OAuth promiscuous.
                
    
                
    
                Regarding existing implementations. Most of those
                implementations
                
    
                are for OIDC.=C2=A0 I think it makes sense for OIDF to
                continue use of
                
    
                OIDC's discovery spec because the UserInfo endpoint is
                well defined
                
    
                and the likelihood of a client mis-informed about the
                resource
                
    
                endpoint is not there.=C2=A0 IMO This does not apply to the
                broader
                
    
                OAuth community.
                
    
                
    
                Item 2:=C2=A0 It may be appropriate to have a separate
                configuration
                
    
                registry specification, but I think we should hold off
                until we
                
    
                have a complete solution and then make the decision what
                drafts
                
    
                should exist and how many pieces.=C2=A0 A big concern is th=
e
                perceived
                
    
                complexity of multiple solutions and multiple drafts.
                
    
                
    
                As to John Bradley=E2=80=99s comments:
                
    
                
    
                Re: Discovery is the wrong place to mitigate threats.
                
    
                I=E2=80=99m confused by this.=C2=A0 Our mandate was to solv=
e a
                security threat
                
    
                by having a discovery specification to prevent clients
                being
                
    
                mis-lead about endpoints (of which resource service is
                one) in an
                
    
                oauth protected exchange.=C2=A0 Maybe what you mean is we
                should not use
                
    
                .well-known of any kind and we should just create a
                =E2=80=9C/Config=E2=80=9D
                
    
                endpoint to OAuth?
                
    
                
    
                Re: Your proposal for MITM mitigation
                
    
                You propose that instead the resource endpoint check
                should be in
                
    
                the oauth protocol itself.=C2=A0 The difference is that
                validation is
                
    
                transferred back to the client to get it right. As well,
                without
                
    
                the client informing the AS, I can=E2=80=99t see a way for =
the
                AS to know
                
    
                what endpoint the client is using.=C2=A0 The webfinger
                approach does
                
    
                this once and only requires that the host name be
                checked in many
                
    
                cases.
                
    
                
    
                As a principle, the members have discussed many times
                that the AS
                
    
                service should do validation when possible =E2=80=94 this w=
as
                particularly
                
    
                true at the Germany meeting when this came up. This is
                why I prefer
                
    
                the client tell the service provider what it intends to
                do and the
                
    
                service provider can fail that request immediately if
                necessary. We
                
    
                don=E2=80=99t have to depend on the developer getting the s=
pec
                correct to
                
    
                fail the correct way.
                
    
                
    
                I worry that adding more parameters to the authz and
                token protocol
                
    
                flows increases complexity and attack surface. It also
                means per
                
    
                authorization validation has to take place vs. a
                one-time
                
    
                validation at config time.=C2=A0 Placing it in the
                configuration lookup
                
    
                phase (whether via web finger or just a special OAuth
                endpoint)
                
    
                seems more appropriate and far less complex - as the
                request itself
                
    
                is simple and has only one parameter. Here we are not
                considered
                
    
                about legitimacy of the client. we=E2=80=99re just concerne=
d
                with the issue
                
    
                "has the client been correctly informed?=E2=80=9D
                
    
                
    
                That said, it may be that when we consider all the use
                cases, some
                
    
                combination of AS protocol and discovery may be both
                needed. I=E2=80=99m
                
    
                not ready to make conclusions about this.=C2=A0 The current
                
    
                oauth-discovery spec seems to put future generic clients
                at risk
                
    
                and that is my primary concern.
                
    
                
    
                Best Regards,
                
    
                
    
                Phil
                
    
                
    
                @independentid
                
    
                www.independentid.com
                <http://www.independentid.com/>
                
    
                p=
hil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 13, 2016, at 10:28 PM,
                  Mike Jones
                  
    
                  <Michael.Jones@microsoft.com
                  <mailto:Michael.Jones@microsoft.com>>
                  
    
                  wrote:
                  
    
                  
    
                  Thanks for posting this, Phil.=C2=A0 It provides a concre=
te
                  example of
                  
    
                  a way that protected resource discovery could be added
                  to
                  
    
                  authorization server metadata discovery, and as such,
                  should
                  
    
                  provide useful input for working group discussions on
                  this topic.
                  
    
                  It=E2=80=99s always great when someone takes the time to =
write
                  an actual
                  
    
                  draft that can be examined and implemented, and I
                  appreciate you
                  
    
                  doing that.
                  
    
                  The content of your draft points out that there
                  appears to be
                  
    
                  complete agreement on what the authorization server
                  metadata
                  
    
                  format should be, which is great!=C2=A0 I=E2=80=99ll note=
 that
                  Section 3 of
                  
    
                  draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthoriz=
ation
                  Server
                  
    
                  Metadata=E2=80=9D is an exact copy of Section 2 of
                  
    
                  draft-ietf-oauth-discovery-01 (with the same title),
                  modulo
                  
    
                  applying a correction suggested by the working group.=C2=
=A0
                  To me this
                  
    
                  suggests that the authorization server metadata
                  definitions in
                  
    
                  draft-ietf-oauth-discovery (which is now the whole
                  normative
                  
    
                  content of the draft) are clearly ready for
                  standardization, since
                  
    
                  even your alternative proposal includes them verbatim.
                  
    
                  Reading your draft, the problem I have with it is that
                  you are
                  
    
                  returning the AS metadata only as a WebFinger
                  response, rather
                  
    
                  than as an https-protected resource published by the
                  authorization
                  
    
                  server.=C2=A0 The choice to only return this via WebFinge=
r
                  makes your
                  
    
                  draft incompatible with most deployed implementations
                  of OAuth
                  
    
                  metadata, including the 22 implementations using it
                  listed
                  
    
                  athttp://openid.net/certification/(see the =E2=80=
=9COP Config=E2=80=9D
                  column in
                  
    
                  the table) andOAuth 2.0 libraries such as Microsoft=E2=80=
=99s
                  =E2=80=9CADAL=E2=80=9D
                  
    
                  library, which uses the metadata path for client
                  configuration.
                  
    
                  Without having ASs provide the metadata as an
                  https-protected
                  
    
                  resource, implementations such as ADAL can=E2=80=99t use =
it
                  for client
                  
    
                  configuration as the currently do.
                  
    
                  Therefore, I would request that you make these minor
                  revisions to
                  
    
                  your draft and republish, so as to provide a unified
                  way forward
                  
    
                  that is compatible with all known existing OAuth
                  Discovery
                  
    
                  deployments:
                  
    
                  1.Modify your section 2 =E2=80=9CAuthorization Server
                  WebFinger Discovery=E2=80=9D
                  
    
                  to have the WebFinger request return the issuer
                  identifier for the
                  
    
                  AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value,=
 rather than
                  returning the
                  
    
                  metadata values by value as the =E2=80=9Cproperties=E2=80=
=9D value.
                  
    
                  2.Reference the metadata definitions from Section 2 of
                  
    
                  draft-ietf-oauth-discovery, rather than duplicating
                  them in your
                  
    
                  Section 3.
                  
    
                  That would have the advantage of paring your draft
                  down to only
                  
    
                  the new things that it proposes, enabling them to be
                  more clearly
                  
    
                  understood and evaluated on their own merits.=C2=A0 I loo=
k
                  forward to
                  
    
                  the discussions of ways of performing additional kinds
                  of OAuth
                  
    
                  discovery, and consider your draft a valuable input to
                  those
                  
    
                  discussions.
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  Best wishes,
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  -- Mike
                  
    
                  *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf
                  Of*John Bradley
                  
    
                  *Sent:*Sunday, March 13, 2016 6:45 PM
                  
    
                  *To:*Phil Hunt <phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>>
                  
    
                  *Cc:*oauth <oauth@ietf.org
                  <m=
ailto:oauth@ietf.org>>
                  
    
                  *Subject:*Re: [OAUTH-WG] New Version Notification for
                  
    
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  As I have told Phil off list.
                  
    
                  Discovery is the wrong place to try and provide
                  security against
                  
    
                  man in the middle attacks on the RS.
                  
    
                  This requires the client to know what the RS URI is
                  before
                  
    
                  retrieving the information on the AS Configuration.
                  
    
                  The proposal Mike and I have been working on requires
                  the client
                  
    
                  to have a notion of what API it is looking for and
                  retrieve the
                  
    
                  .well-known file for that API from the issuer.=C2=A0=C2=
=A0 That
                  allows a
                  
    
                  protocol like Connect to register its own config file
                  that can
                  
    
                  point to the RS.
                  
    
                  If the API specific well known is not available the
                  client can try
                  
    
                  the default oauth-server one.
                  
    
                  That then allows us to deal with restricting where AT
                  are
                  
    
                  presented as part of the protocol rather then dragging
                  discovery
                  
    
                  in as a requirement.
                  
    
                  In my opinion the resource the token is targeted to
                  should be
                  
    
                  separated from the scope and returned as part of the
                  meta-data
                  
    
                  about the AT along with scopes granted and expiry
                  time.=C2=A0=C2=A0 We
                  
    
                  should also have a input parameter for resources so
                  that a client
                  
    
                  can restrict tokens issued to a subset of the ones
                  granted by the
                  
    
                  refresh token.=C2=A0=C2=A0 It would then also be possible=
 to ask
                  a AS for a
                  
    
                  token for a unregistered RS and have the AS produce a
                  JWT access
                  
    
                  token with the resource as an audience if policy
                  allows.
                  
    
                  That however was supposed to be dealt with as part of
                  the mixed up
                  
    
                  client set of mitigations.
                  
    
                  In that the goal was to mitigate the attacks by
                  returning
                  
    
                  meta-data about the tokens, and not to require
                  discovery.
                  
    
                  We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccl=
eint_id=E2=80=9D for the
                  code, and I
                  
    
                  intend to discuss at the F2F returning resource for AT
                  as well.
                  
    
                  Those mitigate the attack.
                  
    
                  I will continue to resist mixing up discovery of
                  configuration
                  
    
                  meta-data with mitigation of the attacks.
                  
    
                  We return meta-data about the tokens now, because AT
                  are opaque to
                  
    
                  the client, we neglected to include some of the
                  information for
                  
    
                  the client needs to be secure.=C2=A0=C2=A0 We just need t=
o add
                  that in to
                  
    
                  the existing flows.
                  
    
                  While Phil=E2=80=99s proposal is easier for the AS to
                  implement as an add
                  
    
                  on, it puts more of a burden on the client needing to
                  potentially
                  
    
                  change how it stores the relationships between AS and
                  RS to
                  
    
                  prevent compromise, I think the solution should be
                  biased towards
                  
    
                  simplicity on the client side.
                  
    
                  If we return the resources as part of the existing
                  meta data the
                  
    
                  client checks that against the resource it intends to
                  send the
                  
    
                  token to and if it is not in the list then it can=E2=80=
=99t
                  send the
                  
    
                  token.=C2=A0 Simple check every time it gets a new AT, no
                  optionality.
                  
    
                  I am not saying anything new Nat has been advocating
                  basically
                  
    
                  this for some time, and dis submit a draft.=C2=A0=C2=A0 I=
 prefer
                  to return
                  
    
                  the info in the existing format rather than as link
                  headers,=C2=A0 but
                  
    
                  that is the largest difference between what Nat and I
                  are saying
                  
    
                  with respect to resource.
                  
    
                  That is the core of my problem with Phil=E2=80=99s draft.
                  
    
                  I guess we will need to have a long conversation in
                  BA.
                  
    
                  Regards
                  
    
                  John B.
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0 On Mar 13, 2016, at 8:12 PM, Phil Hunt
                  <phil.hunt@oracle.com
                  
    
                  =C2=A0=C2=A0=C2=A0 <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                  =C2=A0=C2=A0=C2=A0 This draft is a proposed alternate pro=
posal for
                  
    
                  =C2=A0=C2=A0=C2=A0 draft-ietf-oauth-discovery.=C2=A0 As s=
uch, it contains
                  the same
                  
    
                  =C2=A0=C2=A0=C2=A0 registry for OAuth Config Metadata as =
the authors
                  believe that
                  
    
                  =C2=A0=C2=A0=C2=A0 both solutions are not required, or de=
pending on
                  WG discussion
                  
    
                  =C2=A0=C2=A0=C2=A0 they will be merged. The intent is to =
provide a
                  simple
                  
    
                  =C2=A0=C2=A0=C2=A0 complete draft for consideration.
                  
    
                  =C2=A0=C2=A0=C2=A0 How it works...
                  
    
                  =C2=A0=C2=A0=C2=A0 Given that a client has previously dis=
covered an
                  OAuth
                  
    
                  =C2=A0=C2=A0=C2=A0 protected resource, the bound configur=
ation method
                  allows a
                  
    
                  =C2=A0=C2=A0=C2=A0 client to return the configuration for=
 an oauth
                  authorization
                  
    
                  =C2=A0=C2=A0=C2=A0 server that can issue tokens for the r=
esource URI
                  specified by
                  
    
                  =C2=A0=C2=A0=C2=A0 the client.=C2=A0 The AS is not requir=
ed to be in the
                  same domain.
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0 The AS is however required to kn=
ow if it can
                  issue tokens for
                  
    
                  =C2=A0=C2=A0=C2=A0 a resource service (which presumes som=
e agreement
                  exists on
                  
    
                  =C2=A0=C2=A0=C2=A0 tokens etc).
                  
    
                  =C2=A0=C2=A0=C2=A0 The draft does not require that the re=
source exist
                  (e.g. for
                  
    
                  =C2=A0=C2=A0=C2=A0 unconfigured or new user based resourc=
es). It only
                  requires
                  
    
                  =C2=A0=C2=A0=C2=A0 that the AS service provider agrees it=
 can issue
                  tokens.
                  
    
                  =C2=A0=C2=A0=C2=A0 From a security perspective, returning=
 the OAuth
                  service
                  
    
                  =C2=A0=C2=A0=C2=A0 configuration for a specified resource=
 URI serves
                  to confirm
                  
    
                  =C2=A0=C2=A0=C2=A0 the client is in possession of a valid=
 resource
                  URI ensuring
                  
    
                  =C2=A0=C2=A0=C2=A0 the client has received a valid set of=
 endpoints
                  for the
                  
    
                  =C2=A0=C2=A0=C2=A0 resource and the associated oauth serv=
ices.
                  
    
                  =C2=A0=C2=A0=C2=A0 I propose that the WG consider the alt=
ernate draft
                  carefully
                  
    
                  =C2=A0=C2=A0=C2=A0 as well as other submissions and evalu=
ate the
                  broader
                  
    
                  =C2=A0=C2=A0=C2=A0 discovery problem before proceeding wi=
th WGLC on
                  OAuth Discovery.
                  
    
                  =C2=A0=C2=A0=C2=A0 Thanks!
                  
    
                  =C2=A0=C2=A0=C2=A0 Phil
                  
    
                  =C2=A0=C2=A0=C2=A0 @independentid
                  
    
                  =C2=A0=C2=A0=C2=A0 www.independentid.com
                  <http://www.independentid.com/>
                  
    
                  =C2=A0=C2=A0=C2=A0 phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Begin forwarde=
d message:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *From:*internet-drafts@ietf=
.org
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:internet-drafts@=
ietf.org>
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Subject: New =
Version Notification for
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-hunt-oau=
th-bound-config-00.txt*
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Date:*March 1=
3, 2016 at 3:53:37 PM PDT
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *To:*"Phi=
l Hunt" <p=
hil.hunt@yahoo.com
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:phil.hunt@yahoo.com&g=
t;>,
                  "Anthony Nadalin"
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <tonynad@microsoft.com
                  <mailto:tonynad@microsoft.com>>,
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Tony Nad=
alin" <t=
onynad@microsoft.com
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:tonynad@microsoft.c=
om>>
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A new version =
of I-D,
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has been succe=
ssfully submitted by Phil Hunt
                  and posted to the
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IETF repositor=
y.
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Name:draft-hun=
t-oauth-bound-config
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Revision:00
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title:OAuth 2.=
0 Bound Configuration Lookup
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Document date:=
2016-03-13
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Group:Individu=
al Submission
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pages:22
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URL:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
https://www.ietf.org/internet-drafts/draft-hun=
t-oauth-bound-config-00.txt
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Status:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  https://datatracker.ietf.org/doc/draft=
-hunt-oauth-bound-config/
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Htmlized:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  https://tools.ietf.org/html/draft-hunt-oa=
uth-bound-config-00
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Abstract:
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Th=
is specification defines a mechanism for
                  the client of
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an OAuth 2.0
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pr=
otected resource service to obtain the
                  configuration
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 details of an
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OA=
uth 2.0 authorization server that is
                  capable of
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorizing ac=
cess
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to=
 a specific resource service.=C2=A0 The
                  information
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 includes the O=
Auth
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.=
0 component endpoint location URIs and as
                  well as
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 se=
rver capabilities.
                  
    
                  
    
                  
    
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please note th=
at it may take a couple of
                  minutes from the
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 time of submis=
sion
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 until the html=
ized version and diff are
                  available
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attools.ietf.org
                  <=
http://tools.ietf.org/>.
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The IETF Secre=
tariat
                  
    
                  
    
                  =C2=A0=C2=A0=C2=A0 ______________________________________=
_________
                  
    
                  =C2=A0=C2=A0=C2=A0 OAuth mailing list
                  
    
                  =C2=A0=C2=A0=C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                  =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/o=
auth
                  
    
                
    
                
    
              
    
              
    
            
    
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.or=
g <mailto:OAuth@=
ietf.org>
          
    
          https://www.ietf.org/mailman/listinfo/oauth
          
    
        
    
        
    
        
    
        
    
        _______________________________________________
        
    
        OAuth mailing list
        
    
        OAuth@ietf.org<=
/a>
        
    
            https://www.ietf.org/mailman/listinfo/oauth
        
    
        
    
      
    
      
    
    
    
    
    
  
    




    ______________________________=
_________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    


    


    

--001a113f9022688e3a052e19f552--


From nobody Tue Mar 15 10:49:11 2016
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 AD22312DCCD for ; Tue, 15 Mar 2016 10:49:10 -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, SPF_PASS=-0.001] autolearn=unavailable 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 K3TLliVWUqda for ; Tue, 15 Mar 2016 10:49:08 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 A0B6E12D586 for ; Tue, 15 Mar 2016 10:42:06 -0700 (PDT)
Received: by mail-lb0-x229.google.com with SMTP id x1so31968183lbj.3 for ; Tue, 15 Mar 2016 10:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mM0KxbQDyNA2s8LkLBb/Wm3k10b8P1h55fhenDTkJws=; b=xB6/ormIMxqIgxwPbWbFH+37P+EK3FSYDwyJ7BgJAPHbm7w+S3lMPJut4wXHJrV7j2 HtiZ7/YWwb0e8/lTtozwihcZJ3GrIB4r9my1hs5gvaTiT5cNq2xskt2M5Krj9AwVswkT AgA8lC/E2FJQ/IufhY9llXYmM5f8inc1IJq0utJJ9IJSV72Q2lFcCu37lIbiQFFBNl/f 8PcE7NE9PTti4NUeYSi2Xi8ZAJyLUrOz5JE+vMtMZ3MlhsSKh5d3CbC3udfHFsTtRDTq dAbbCzszj5MdI3qX/UEwfITBygGDbDd829RPtlp/4NttcnabRW103CxQ1zrvcVvJvptM 1I6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mM0KxbQDyNA2s8LkLBb/Wm3k10b8P1h55fhenDTkJws=; b=PvkEUsQ5cZPTCSFI00nmEWcsWuUMUCY/IbL7wSmk0LADuwTd6eQZ8AevzhjHQcyTxy +B5rzyHTFcWTZUSUzj2oXSqIeyign57CxpaperPeQxuCpyRxxwKMYP7QLWb+Hjjjg2tk wSB4TOFql0179EuBh5doXvGISAPZwiEqzVY/cmtRR80f9ZHnU76CoZe9UFoARgrIvgPT Jp7Np8ct4PFeZXed68AJlRmLi3BiTmZBg4/PzRxLSIs9hAbqzml5wtNPBRScYSqIQRJU ES8O61W81rOEgUgugZuWYgmtnw/8Vttv7gSN2a7rsqSw97Skq5dqOmWrQLR7td+6tZuc +tzw==
X-Gm-Message-State: AD7BkJJPcaULqWR1eTQ2WLeabW6gIEdIrvZX8SofsxWCAEPbIY4egOmQ3hZDTZ5pr7mxdIRYzq2rlnHFuXjF+w==
X-Received: by 10.112.30.163 with SMTP id t3mr218352lbh.15.1458063724876; Tue, 15 Mar 2016 10:42:04 -0700 (PDT)
MIME-Version: 1.0
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E8079C.3010402@gmail.com>  <7EF652C2-B3DA-4806-BB81-CFDCE2FB951A@mit.edu>
In-Reply-To: <7EF652C2-B3DA-4806-BB81-CFDCE2FB951A@mit.edu>
From: Thomas Broyer 
Date: Tue, 15 Mar 2016 17:41:54 +0000
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=001a11336424619b88052e19ea6f
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:49:11 -0000

--001a11336424619b88052e19ea6f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 15, 2016 at 6:23 PM Justin Richer  wrote:

> +1 to all of this.
>
> Our reasoning for the JWT+introspection was to allow for an RS to take in
> tokens from multiple AS, by looking up the issuer in the JWT itself.
>

But then, as I said, you need the AS to "cooperate" by making their ATs
JWTs; only for one RS that want to also accept ATs from other (concurrent?)
ASs. They could make everyone pay the price with bloated tokens, or start
treating some RSs different from others (at registration time, say you want
JWTs), or add extensions to the authorization endpoint or token endpoint so
clients can ask for JWT tokens.

Overall, I think my proposal to exchange an AS token for a RS-specific
token at an AS-specific endpoint at the RS (see mail in the other thread
from last week; that phrasing here is =E2=80=9Cfun=E2=80=9D but not really =
legible ;-) )
would have the best of both worlds.
At the RS, linking the issued token with the received token from the AS
allows the RS to introspect the original token from time to time to check
for revocation (possibly in addition to its own revocation mechanism for
its own tokens).
Downside is that clients now have to do the token exchange and keep track
of both tokens.


>  =E2=80=94 Justin
>
> On Mar 15, 2016, at 12:34 PM, Thomas Broyer  wrote:
>
>
>
> On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin 
> wrote:
>
>> Hi
>>
>> After following the recent thread on multiple authorization servers, but
>> also reading some other related threads, I have a question related to
>> when the token introspection can be avoided.
>>
>> My understanding has been that given that access tokens are opaque the
>> RS does not know anything about its content, hence that was the purpose
>> of the token introspection spec: provide an interoperable way for RS to
>> submit a token to AS and get the token data for RS to make a final
>> decision about this token.
>>
>> I think if the access tokens are really opaque, i.e, they are sequences
>> RS can not look into, then having the introspection option is the only
>> way to check what the token is really about.
>>
>> But the recent replies with respect to using JWS or JWE tokens have
>> confused me.
>>
>> 1. AccessToken as JWS JWT Token:
>>
>> RS can easily look into it, but Justin mentioned that in one case they
>> first validate this JWS token and then forward it for some further
>> introspection. Why start introspecting if the token has been validated
>> and its content is visible ?
>>
>
> Because you want to know whether it's been revoked before its expiration.
> Introspection is the only way (unless AS and RS are colocated), as only t=
he
> AS knows.
>
>
>> Perhaps because some token data which are sensitive are only visible in
>> the introspection response ? If yes then why use a self-contained token
>> if some more external data are associated with it.
>>
>
> If the token is not valid (bad issuer, bad signature, expired; or if the
> scopes are included: insufficient scopes), it saves you a request to the
> introspection endpoint ;-)
> Only if the token passes the first checks would you introspect it to see
> if it's still active (not revoked) and possibly retrieve more data about =
it.
>
>
>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of
>> times recently, Jonh B. suggested in the other thread the introspection
>> may not be needed (sorry if I misread it).
>> The question here, how can RS deal with a JWE token, it would need to
>> share the decrypting key with AS.
>>
>
> I think that was the idea yes (didn't someone commented on the thread tha=
t
> they deployed JWT tokens with shared secrets or symmetric keys?)
>
>
>> So, is introspection needed only for the completely opaque tokens or it
>> is also needed for JWS and JWE tokens. I'd say it might be reasonable to
>> skip it in case of JWS, depending on the specific requirements (as the
>> expiry, issuer, will be typically set in JWS JWT), while with JWE I can
>> not see how RS can avoid introspecting unless it shares the
>> secret/private key with AS.
>>
>
> As Justin mentioned in the other thread: introspection is useful
> (required?) for checking the "liveness" of the token.
>
> Side-note: given the size of a JWT compared to some "simpler", opaque
> tokens (mere identifiers), and the fact introspection response are likely
> to be cached for a few minutes by the RS, I wonder if using a JWT so you
> can possibly avoid an introspection request outweights (sic!) the bloat o=
f
> a JWT sent repeatedly over the network (possibly a network with high
> latency, low bandwidth, and sometimes paid based on exchanged volumes).
> This is rhetoric actually: I side on the "small token that require
> introspection" until someone comes with a compelling argument to go the
> other way.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a11336424619b88052e19ea6f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On Tue=
, Mar 15, 2016 at 6:23 PM Justin Richer <jricher@mit.edu> wrote:
    =

    +1 to all of this.

    O=
ur reasoning for the JWT+introspection was to allow for an RS to take in to=
kens from multiple AS, by looking up the issuer in the JWT itself.

    But then, as I said, you need the AS to=
 "cooperate" by making their ATs JWTs; only for one RS that want =
to also accept ATs from other (concurrent?) ASs. They could make everyone p=
ay the price with bloated tokens, or start treating some RSs different from=
 others (at registration time, say you want JWTs), or add extensions to the=
 authorization endpoint or token endpoint so clients can ask for JWT tokens=
.

    Overall, I think my proposal to exchange an AS t=
oken for a RS-specific token at an AS-specific endpoint at the RS (see mail=
 in the other thread from last week; that phrasing here is =E2=80=9Cfun=E2=
=80=9D but not really legible ;-) ) would have the best of both worlds.
    At the RS, linking the issued token with the received token from the=
 AS allows the RS to introspect the original token from time to time to che=
ck for revocation (possibly in addition to its own revocation mechanism for=
 its own tokens).
    Downside is that clients now have to do the tok=
en exchange and keep track of both tokens.
    =C2=A0
    =C2=A0=E2=80=
=94 Justin
    On Mar 15, 2016, at 12:34 PM, Thomas Broyer <t.broyer@gmail.com=
> wrote:


    =

    On Tue, Mar 15, 2016 at 2:0=
2 PM Sergey Beryozkin <sberyozkin@gmail.com> wrote:
    Hi
    

    
After following the recent thread on multiple authorization servers, but
also reading some other related threads, I have a question related to
    
when the token introspection can be avoided.
    

    
My understanding has been that given that access tokens are opaque the
    
RS does not know anything about its content, hence that was the purpose
    
of the token introspection spec: provide an interoperable way for RS to
    
submit a token to AS and get the token data for RS to make a final
    
decision about this token.
    

    
I think if the access tokens are really opaque, i.e, they are sequences
    
RS can not look into, then having the introspection option is the only
    
way to check what the token is really about.
    

    
But the recent replies with respect to using JWS or JWE tokens have
    
confused me.
    

    
1. AccessToken as JWS JWT Token:
    

    
RS can easily look into it, but Justin mentioned that in one case they
    
first validate this JWS token and then forward it for some further
    
introspection. Why start introspecting if the token has been validated
    
and its content is visible ?

    Because yo=
u want to know whether it's been revoked before its expiration. Introsp=
ection is the only way (unless AS and RS are colocated), as only the AS kno=
ws.
    =C2=A0
    
Perhaps because some token data which are sensitive are only visible in
    
the introspection response ? If yes then why use a self-contained token
    
if some more external data are associated with it.
    If the token is not valid (bad issuer, bad signature, expired; =
or if the scopes are included: insufficient scopes), it saves you a request=
 to the introspection endpoint ;-)
    Only if the token passes the f=
irst checks would you introspect it to see if it's still active (not re=
voked) and possibly retrieve more data about it.
    =C2=A0
    
2. AccessToken as JWE JWT Token: this option was mentioned a couple of
    
times recently, Jonh B. suggested in the other thread the introspection
    
may not be needed (sorry if I misread it).
    
The question here, how can RS deal with a JWE token, it would need to
    
share the decrypting key with AS.

    I thi=
nk that was the idea yes (didn't someone commented on the thread that t=
hey deployed JWT tokens with shared secrets or symmetric keys?)
    =
=C2=A0
    
So, is introspection needed only for the completely opaque tokens or it
    
is also needed for JWS and JWE tokens. I'd say it might be reasonable t=
o
    
skip it in case of JWS, depending on the specific requirements (as the
    
expiry, issuer, will be typically set in JWS JWT), while with JWE I can
    
not see how RS can avoid introspecting unless it shares the
    
secret/private key with AS.

    As Justin m=
entioned in the other thread: introspection is useful (required?) for check=
ing the "liveness" of the token.

    Side-no=
te: given the size of a JWT compared to some "simpler", opaque to=
kens (mere identifiers), and the fact introspection response are likely to =
be cached for a few minutes by the RS, I wonder if using a JWT so you can p=
ossibly avoid an introspection request outweights (sic!) the bloat of a JWT=
 sent repeatedly over the network (possibly a network with high latency, lo=
w bandwidth, and sometimes paid based on exchanged volumes).
    This=
 is rhetoric actually: I side on the "small token that require introsp=
ection" until someone comes with a compelling argument to go the other=
 way.
    
_______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    http=
s://www.ietf.org/mailman/listinfo/oauth
    

--001a11336424619b88052e19ea6f--


From nobody Tue Mar 15 10:51:53 2016
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 D60B812DC06 for ; Tue, 15 Mar 2016 10:51:51 -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, FREEMAIL_FROM=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 (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 qfyf3ZdMAIoc for ; Tue, 15 Mar 2016 10:51:49 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 058CF12D586 for ; Tue, 15 Mar 2016 10:51:49 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id l68so37915939wml.1 for ; Tue, 15 Mar 2016 10:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XaueB/iZS7m+x/j+dQwRrcoF/G9EUhMbVGf6hp38MRE=; b=AIub2D+9OgT2nSnKEcHbPgnGweBbPqvF/qNX6UZma/u4KqQgs5hu6nBlOQwjYOoYHP SrwVR1QYSFmdfdJzIDVFIz+tOv2YDoVy3s5hopuFvk7OmhS5txx+fw0CKStExFS2NKqN E9p/vEVOcjgDkMnoCmNCj5CuDHbuOgSAsF5lOmfWU68OPM6r54Y/gQMWIwNqMyRei+Hf eMiWBS+5c6AO946jOk5IJDZl6P7bA+paNTLS9YZ6t7sss56NuC40vWRlycI3cz550hvz hhAJPYA+VaO9pD/FcdfMLtlNMnApecX+OpIPxHxi3YwXLNstb8sbZLhzaBymTTyT7erL aSnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XaueB/iZS7m+x/j+dQwRrcoF/G9EUhMbVGf6hp38MRE=; b=cuWTrVUiBlvCtUJRuX5cp4DYGTfLBL+u4AUWAyJFXQJa/uIZIooDLrLNhzWiBDvhfo 9OrqsXjeKv8MW9hPI5rQYClOA68ywZtx73nzMrpDT+siUIiHCz2KcwecgVGFrNLZPMqa 5mkGH6SncH/Q7+Rq2nG6LFJ+XQAZDL9f34+Ruz/PlFyamixnJnKnqQlcSd2XA/Gc+y4A 9xoD81zuMPZG/kZeRH0Z7IIjYV5OkaLlld4CQPnKmIwWgkFB9iv+S7OpVgHqpNWuszBg SVGMR762Y20I9SBLByPcecrNhuuIIhgeUi0e+pijMmAMp5Lv0xZ6F/rWMhkU1p6F972g XA5Q==
X-Gm-Message-State: AD7BkJLMw0GxgSGk1hxajbwtuOYW53m88NmLLU0KgHyL1hcu4WzcWNJA2md6VeWlVLjcgw==
X-Received: by 10.28.55.74 with SMTP id e71mr26024740wma.26.1458064307539; Tue, 15 Mar 2016 10:51:47 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id v188sm21765988wmv.3.2016.03.15.10.51.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 10:51:46 -0700 (PDT)
To: Justin Richer 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E805B8.5000305@mit.edu> <56E80B7B.2010801@gmail.com> 
From: Sergey Beryozkin 
Message-ID: <56E84BB2.5030203@gmail.com>
Date: Tue, 15 Mar 2016 17:51:46 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:51:52 -0000

Hi Justin

AFAIK many Java JAAS systems, etc have things like "username", 
"password" set in various properties files, etc, and often these are 
really "client_id", "client_secret" in that these are not meant to 
support  a direct authentication between some command line client and 
this server.

I understand that if say I had a user working with some server, the user 
has authenticated, then the server does some outbound call on behalf of 
this user, then it is the impersonation, and I'd plan to use client 
credentials here but rather user a code flow. STS for the REST of us 
seems to be to support different cases...


Many Thanks
Sergey

On 15/03/16 15:29, Justin Richer wrote:
> So long as you’re storing the client_id and client_secret in your LDAP and not putting a username and password (that normally represents a person) into the software, you’re fine. That’s just a case of externalizing the client registration to the LDAP system — it’s still registered.
>
> Otherwise, if you’re putting a person’s information into the client there, you’re doing impersonation. That’s bad, don’t do that.
>
>   — Justin
>
>> On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin  wrote:
>>
>> Hi Justin
>>
>> Many thanks for the quick response.
>> On 15/03/16 12:53, Justin Richer wrote:
>>> Is Alice the client here (the piece of software), or is Alice the
>>> resource owner?
>> Piece of software, something that needs to run without the human user being involved
>>> If Alice is the resource owner, then you should
>>> absolutely not be using the client credentials flow like this.
>>>
>> Sure.
>>
>>> The client credentials flow is designed for cases where the client is
>>> acting on its own behalf, not on behalf of any particular user. It's an
>>> optimization of the canonical authorization code flow, where there is no
>>> interaction with the resource owner because there is no resource owner
>>> as a separate entity. It's most useful for backend systems that would
>>> have traditionally used a developer key to get access to bulk data. If
>>> you're using it for single-user access, you're doing it wrong.
>>>
>> I guess I'm still OK here, as I said, it is a piece of software which runs without a user. Like in all web services (SOAP or plain HTTP client invocations) where the client sets some credentials and accesses some data in the remote service.
>>
>>> Also, you should keep in mind that things that seem "simple" on the
>>> surface are often simplified at the cost of making specific security
>>> concessions and assumptions. The authorization code flow is "complex"
>>> for very good reasons, all of them security focused. You should never
>>> pick a different OAuth flow just because it looks simpler, you should
>>> only pick them if you're within the use case that it was designed for,
>>> and therefor the assumptions of its security patterns match.
>>>
>> +1
>>> We've seen a *ton* of problems with people picking the implicit flow in
>>> the real world and using it with clients other than in-browser
>>> applications that it was designed for. If you're not in that specific
>>> space, you're taking on huge risks.
>> Sure, I understand.
>>
>> So, as far as my original question is concerned, given that a client piece of software (no human user is involved) uses some credentials to get the token with client_credentials, would it be OK to avoid the explicit 'Client' registration with AS, given that the authentication system employed by AS is already aware of such credentials, I guess yes.
>>
>> Thanks, Sergey
>>>
>>>   -- Justin
>>>
>>> On 3/15/2016 8:37 AM, Sergey Beryozkin wrote:
>>>> Hi All
>>>>
>>>> I've alway been thinking of Client Credentials as being the simplest
>>>> flow but now that I'm looking at implementing it myself to be used in
>>>> the real productions, I'm realizing that there's something I do not
>>>> understand about it:
>>>>
>>>> Do the clients using Client Credentials flow need to be
>>>> OAuth2-registered, even when such clients are already known to the
>>>> authentication system ?
>>>>
>>>> For example, there might be some LDAP/etc entry for Alice (name,
>>>> password). Now a client is using a client credentials flow to get an
>>>> access token:
>>>>
>>>> POST /token HTTP/1.1
>>>> Host: server.example.com
>>>> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>>> Content-Type: application/x-www-form-urlencoded
>>>>
>>>> grant_type=client_credentials
>>>>
>>>> I hope that in this case no explicit registration (the one typically
>>>> required in redirection based flows) is needed, the client (Alice) has
>>>> been 'implicitly' registered (as far as the notion of OAuth2 client is
>>>> concerned) in LDAP/etc.
>>>>
>>>> If the explicit registration with OAuth2 AS was still required in the
>>>> case above then it would lead to a fairly massive duplication of
>>>> effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>>>>
>>>> Can someone clarify it please ?
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/


From nobody Tue Mar 15 10:52:53 2016
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 07C0812DBEE for ; Tue, 15 Mar 2016 10:52: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, FREEMAIL_FROM=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 (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 74B0JI1wv5ve for ; Tue, 15 Mar 2016 10:52:50 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 C6E8F12DC7C for ; Tue, 15 Mar 2016 10:52:49 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id p65so38022801wmp.0 for ; Tue, 15 Mar 2016 10:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=zuox0WnVZxvs4OnwH/hT1QDz5F3bJisn9bYn6TUV6YQ=; b=jFNVglXExwRVcYuKoyORsSn7YZuAN513anX6cwNBViccFCBIS0PWYc9kVVWauXCEHL 8jn3X/G3E2M6R5q5g9wt4xBV1TlLDAHqrcTpPORCoFd9OkAEXiY32WaqPTeZoVLVWgNd nh+c/rcKiZXcDm1U7h5B39dI6UWBKl0P1TWxSXFs7Br+EMPt7kvNZFAOUCUo54hljCE7 R4eDELn3ZHGZPU+5Cu5242Afmvjhb1QBVIB+BO/i8SLxKiMH6PieKcRICr5H6d68SCTr NxGnE83A1LIPx60L77tnGSJm3CgRPLOs23w4haUeOsJ3BV2tQoSeCfpaQTGb5EtZGxpa PPSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zuox0WnVZxvs4OnwH/hT1QDz5F3bJisn9bYn6TUV6YQ=; b=GrstAXNlTtx61EulznIyGhBHVhF9xnNvKIFQb4yrMwNtqMWjuptPJwPrf/eVKS/ocb Ej5TJ3HlaUOTqz+KQd0/0TiKNHosSPrgdb8EGhmDlUTBotZHt7J6ugyWcUkhfj/EgC78 LD2OB7Ea2u8jPMNjqIKKwEXsaHsu64/ekDOLhjqDhg9IfxjcktmAIKeju1XuypDBbJPt fABBt/95f2kUZaJNXD9X5sKPC9j9+8iooibMthcQDDCgTPVVg6LyxFuSVrWiBEAD2ykE rRwHbG2re643BBtDQrJbMGLD/2gW81/QTrCmgm4CIF9c+r2BrpXcJuleQHmE27GNl3mY LoVw==
X-Gm-Message-State: AD7BkJJbj4SJD4+q1lnTXwevSdAr4PUbGlFAmA8lIzURqeZrLdPeS9fGbVcDDuwjbp8VDQ==
X-Received: by 10.28.132.212 with SMTP id g203mr25241955wmd.30.1458064368301;  Tue, 15 Mar 2016 10:52:48 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id gt7sm28020743wjc.1.2016.03.15.10.52.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 10:52:47 -0700 (PDT)
To: Justin Richer 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <7C5B6DD5-102B-4142-B64A-FB2B3C618E9A@ve7jtb.com> <56E80227.7080709@gmail.com> <56E805B8.5000305@mit.edu> <56E80B7B.2010801@gmail.com>  <56E84BB2.5030203@gmail.com>
From: Sergey Beryozkin 
Message-ID: <56E84BEF.5080704@gmail.com>
Date: Tue, 15 Mar 2016 17:52:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E84BB2.5030203@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:52:52 -0000

Sorry,
On 15/03/16 17:51, Sergey Beryozkin wrote:
> Hi Justin
>
> AFAIK many Java JAAS systems, etc have things like "username",
> "password" set in various properties files, etc, and often these are
> really "client_id", "client_secret" in that these are not meant to
> support  a direct authentication between some command line client and
> this server.
Was actually trying to say above "are meant to"
>
> I understand that if say I had a user working with some server, the user
> has authenticated, then the server does some outbound call on behalf of
> this user, then it is the impersonation, and I'd plan to use client
> credentials here but rather user a code flow. STS for the REST of us
> seems to be to support different cases...
>
>
> Many Thanks
> Sergey
>
> On 15/03/16 15:29, Justin Richer wrote:
>> So long as you’re storing the client_id and client_secret in your LDAP
>> and not putting a username and password (that normally represents a
>> person) into the software, you’re fine. That’s just a case of
>> externalizing the client registration to the LDAP system — it’s still
>> registered.
>>
>> Otherwise, if you’re putting a person’s information into the client
>> there, you’re doing impersonation. That’s bad, don’t do that.
>>
>>   — Justin
>>
>>> On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin 
>>> wrote:
>>>
>>> Hi Justin
>>>
>>> Many thanks for the quick response.
>>> On 15/03/16 12:53, Justin Richer wrote:
>>>> Is Alice the client here (the piece of software), or is Alice the
>>>> resource owner?
>>> Piece of software, something that needs to run without the human user
>>> being involved
>>>> If Alice is the resource owner, then you should
>>>> absolutely not be using the client credentials flow like this.
>>>>
>>> Sure.
>>>
>>>> The client credentials flow is designed for cases where the client is
>>>> acting on its own behalf, not on behalf of any particular user. It's an
>>>> optimization of the canonical authorization code flow, where there
>>>> is no
>>>> interaction with the resource owner because there is no resource owner
>>>> as a separate entity. It's most useful for backend systems that would
>>>> have traditionally used a developer key to get access to bulk data. If
>>>> you're using it for single-user access, you're doing it wrong.
>>>>
>>> I guess I'm still OK here, as I said, it is a piece of software which
>>> runs without a user. Like in all web services (SOAP or plain HTTP
>>> client invocations) where the client sets some credentials and
>>> accesses some data in the remote service.
>>>
>>>> Also, you should keep in mind that things that seem "simple" on the
>>>> surface are often simplified at the cost of making specific security
>>>> concessions and assumptions. The authorization code flow is "complex"
>>>> for very good reasons, all of them security focused. You should never
>>>> pick a different OAuth flow just because it looks simpler, you should
>>>> only pick them if you're within the use case that it was designed for,
>>>> and therefor the assumptions of its security patterns match.
>>>>
>>> +1
>>>> We've seen a *ton* of problems with people picking the implicit flow in
>>>> the real world and using it with clients other than in-browser
>>>> applications that it was designed for. If you're not in that specific
>>>> space, you're taking on huge risks.
>>> Sure, I understand.
>>>
>>> So, as far as my original question is concerned, given that a client
>>> piece of software (no human user is involved) uses some credentials
>>> to get the token with client_credentials, would it be OK to avoid the
>>> explicit 'Client' registration with AS, given that the authentication
>>> system employed by AS is already aware of such credentials, I guess yes.
>>>
>>> Thanks, Sergey
>>>>
>>>>   -- Justin
>>>>
>>>> On 3/15/2016 8:37 AM, Sergey Beryozkin wrote:
>>>>> Hi All
>>>>>
>>>>> I've alway been thinking of Client Credentials as being the simplest
>>>>> flow but now that I'm looking at implementing it myself to be used in
>>>>> the real productions, I'm realizing that there's something I do not
>>>>> understand about it:
>>>>>
>>>>> Do the clients using Client Credentials flow need to be
>>>>> OAuth2-registered, even when such clients are already known to the
>>>>> authentication system ?
>>>>>
>>>>> For example, there might be some LDAP/etc entry for Alice (name,
>>>>> password). Now a client is using a client credentials flow to get an
>>>>> access token:
>>>>>
>>>>> POST /token HTTP/1.1
>>>>> Host: server.example.com
>>>>> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>>>> Content-Type: application/x-www-form-urlencoded
>>>>>
>>>>> grant_type=client_credentials
>>>>>
>>>>> I hope that in this case no explicit registration (the one typically
>>>>> required in redirection based flows) is needed, the client (Alice) has
>>>>> been 'implicitly' registered (as far as the notion of OAuth2 client is
>>>>> concerned) in LDAP/etc.
>>>>>
>>>>> If the explicit registration with OAuth2 AS was still required in the
>>>>> case above then it would lead to a fairly massive duplication of
>>>>> effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>>>>>
>>>>> Can someone clarify it please ?
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/


From nobody Tue Mar 15 10:57:00 2016
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 D80D512DBE3 for ; Tue, 15 Mar 2016 10:56:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 jW9gcwMfdoyl for ; Tue, 15 Mar 2016 10:56:53 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 B4AF412DBD9 for ; Tue, 15 Mar 2016 10:56:52 -0700 (PDT)
Received: by mail-qg0-x235.google.com with SMTP id y89so21319033qge.2 for ; Tue, 15 Mar 2016 10:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=WdxipR+QPyw9UtQsqmtGlU7NmTg/zdxC5r7qtVAgloQ=; b=ZHJ/mX+m2lbB4rihtEG7nR6k8N8L3zzIKNOPQx5UttKH2pAZqMRkM5VqSpehp7FFx7 6yIncjYfWVjHXzFTgroZchtGmMyFEukiD5/qAHfPI51aOp31B8nRQ7RulZt+FiThbeNs FIclWUaxCUwT9AHIjYDQQINWR5w+K674yluQvj/AKb9YItH7lfoNYl6GivtaE1WNoSEd 9jtjOwzg4R3shw8b29DLLIgkc77tnWtM7EnhCEJzBxO4u00jnuoyjnt7lWnzQ2Oo6y/z naMTMUAlan40ydXKvXuP/I3/T1FafzHUmgaVqxpNCX2qJgbPg5LyClXeyzihNU3ue9XZ b4eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WdxipR+QPyw9UtQsqmtGlU7NmTg/zdxC5r7qtVAgloQ=; b=cmxc0BQs9LWEnVK7AzvtiWIJcZori1u6gzIoURsjKBDDdq/FUoyg79DQRSGOzY0d5y gxFR+gxRfQ8taM2woHH7BoOPrT9aC+jDnj+xsaBf3BRLkG35nLI+hf5vTEFFfrDUv5Qu W2afnjwxziDB+Jzoqqm2Y/rxXySgKzAqsIaNfKJbi4O4ohjkz6EQohgnrvIHTChU58ZK nGZW91MN+ETTHNY+Jv+fhG0LYezv+28S94kKyGMTmuUg5kNVBSFIwo0ad0TG1GoIGUsS 3N1SGKMLqv6EB9eKpYNfQT2hxiGuS4GonxABnVEqtZ2Tz7CcdJLbd/2EW9/tzd4atFxh lYWQ==
X-Gm-Message-State: AD7BkJKx/+8QjGQrs5I/R4Vy8taTe+XlL82mZZMN/CuD1laytG1QPjF8wmw4Eiuu2BS2kw==
X-Received: by 10.140.170.70 with SMTP id q67mr43210099qhq.8.1458064611415; Tue, 15 Mar 2016 10:56:51 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.31.112]) by smtp.gmail.com with ESMTPSA id u202sm13191842qka.43.2016.03.15.10.56.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 10:56:50 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_7BE89A08-EF3D-4053-9376-96B146C72007"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 15 Mar 2016 14:56:47 -0300
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com> 
To: Brian Campbell 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:56:59 -0000

--Apple-Mail=_7BE89A08-EF3D-4053-9376-96B146C72007
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E0363D10-2D95-4180-8877-2CE0915742EC"


--Apple-Mail=_E0363D10-2D95-4180-8877-2CE0915742EC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think it is a AS policy decision if it should error or take the =
requested resource and issue a token audianced for that resource.

I guess the question is how to transition from now to a future state.   =
If you cannot upgrade all the clients at once.

A processing rule on the AS that allowed some clients to not send the =
requested resource , but would error out for other upgraded clients  =
with a "resource not allowed=E2=80=9D oauth error would work and not =
require the return of the resources. =20

If you return the resources and let the client error if it is trying to =
send to the wrong endpoint that make upgrading easier, but gives less =
control to the AS.

I could live with it ether way.

The advantage of always sending it in the token request is that it =
allows the AS to do the mapping from a resource URI to one or more =
abstract audience for the token.

That might help address George=E2=80=99s concern.

John B.


> On Mar 15, 2016, at 2:44 PM, Brian Campbell =
 wrote:
>=20
> I was thinking it'd be simpler to error, if the requested resource(s) =
weren't okay. That puts the burden of checking in the AS. And doesn't =
add anything to the token or authorization response. I see the potential =
similarity to scope but not sure it's worth it.  =20
>=20
> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley > wrote:
> If the client specifies the resource it wants the token for, then the =
meta-data would not be required unless the resources the token is good =
at are different from the request. =20
> Lat is the same logic as scopes.
>=20
> For backwards compatibility if the client is happy with the default =
resources based on scopes then I think it is a good idea to tell the =
client what the resources are in the response.
>=20
> I suspect that it is simpler with less optionality and always return =
the resources, even if they are not required.
>=20
> John B.
>=20
>> On Mar 15, 2016, at 12:46 PM, Brian Campbell =
> wrote:
>>=20
>> If the client specifies the desired audience(s)/resource(s), is that =
metadata to the client needed? The AS can audience restrict the token as =
needed or respond with an error if it can't or wont issue a token for =
the resource the client asked for.=20
>>=20
>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley > wrote:
>> Yes,  I think bearer tokens with no audience are a bad idea.
>>=20
>> The AS needs to infer an audience from the scopes snd/or have the =
client specify the desired audience.
>>=20
>> If the AT has a audience or audiences then as long as the endpoint =
URI are provided as meta-data with the token, the client can determine =
if it is sending the token to the correct place.
>>=20
>> I think Phil would prefer the server rather than the client do the =
check, but the client always needs to take some responsibility to not =
leak tokens giving them to the wrong RS or the code to the wrong token =
endpoint is leaking.
>>=20
>> I imagine that claims based access tokens are going to become more =
popular and the static relationship between one RS and one AS will not =
be the majority of deployments over time.=20
>>=20
>> In any case where the client is configured up front to know the RS =
and the AS it seems like that would not require Phil=E2=80=99s Solution, =
but that is the only case supported by that discovery.
>>  =20
>> If the client itself is bad there is not much you can do to stop it =
from passing on the AT in way way it wants.  That however is a different =
problem and needs claimed URI or attestations to prevent client =
spoofing.
>> William and I are working on that in the mobile best practices draft.
>>=20
>> John B.
>>=20
>>=20
>>> On Mar 15, 2016, at 12:09 PM, George Fletcher > wrote:
>>>=20
>>> I worry about two directions I see in this thread...
>>>=20
>>> 1. Client's accessing resources dynamically so that discovery is =
required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>>>=20
>>> 2. Creating a tight coupling between RS and AS such that RS endpoint =
changes must be continually communicated to the AS. If an RS supports =
multiple AS's then the RS has to deal with "guaranteed" delivery. The AS =
needs an endpoint to receive such communications. If not dynamic via =
APIs, then deployment of the new RS is bound by the associated AS's =
getting and deploying the new endpoints. Can both endpoints of the RS be =
supported within the AS for some period of time, etc. This is an =
operation nightmare and almost assuredly going to go wrong in =
production.
>>>=20
>>> Maybe an OAuth2 "audience binding" spec is what's needed for those =
deployments that require this. I believe that is what John Bradley is =
suggesting.
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>> +1, I've found the very same in OAuth deployments that I was =
involved in; the hard part is to give names and descriptions to these =
concepts so that they cover all use cases and can be applied =
unambiguously=20
>>>>=20
>>>> Hans.=20
>>>>=20
>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>> I agree that this is valuable, and not just for PoP. In all =
honesty,=20
>>>>> it=E2=80=99s not even really required for PoP to function in many =
cases =E2=80=94 it=E2=80=99s=20
>>>>> just an optimization for one particular kind of key distribution=20=

>>>>> mechanism in that case.=20
>>>>>=20
>>>>> In the years of deployment experience with OAuth 2, I think =
we=E2=80=99ve really=20
>>>>> got three different kinds of things that currently get folded into=20=

>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:=20
>>>>>=20
>>>>>=20
>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>   - What actions do I want to take on these things? (read, write, =
delete)=20
>>>>>   - How long do I want these tokens to work?=20
>>>>> (offline_access/refresh_token, one time use, next hour, etc)=20
>>>>>=20
>>>>>=20
>>>>> I think the first one is close to the audience/resource parameters =
that=20
>>>>> have been bandied about a few times, including in the current =
token=20
>>>>> exchange document. We should be consistent across drafts in that =
regard.=20
>>>>> The second is more traditional scope-ish. The third has been =
patched in=20
>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.=20=

>>>>>=20
>>>>> Just another vector to think about if we=E2=80=99re going to be =
adding things=20
>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.=20
>>>>>=20
>>>>>   =E2=80=94 Justin=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley =20
>>>>>>  > wrote:=20
>>>>>>=20
>>>>>> Yes I will work on another proposal for allowing clients to =
specify=20
>>>>>> what resource they want a token for and providing the meta-data =
to the=20
>>>>>> client about the resources that a token is valid for.=20
>>>>>>=20
>>>>>> We have part of it in the POP key distribution spec and talked =
about=20
>>>>>> separating it, as it is used more places than just for assigning =
keys.=20
>>>>>> I know some AS use different token formats for different RS so =
are=20
>>>>>> all-ready needing to pass the resource in the request to avoid =
making=20
>>>>>> a mess of scopes.=20
>>>>>>=20
>>>>>> John B.=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) =
=20
>>>>>>>  > =
wrote:=20
>>>>>>>=20
>>>>>>> Inline=20
>>>>>>>=20
>>>>>>> Phil=20
>>>>>>>=20
>>>>>>> On Mar 14, 2016, at 14:13, John Bradley =20
>>>>>>>  > wrote:=20
>>>>>>>=20
>>>>>>>> We had two mandates.  One was to provide a spec for AS =
metadata.=20
>>>>>>>> The other was to mitigate the client mixup attack.  The request =
was=20
>>>>>>>> to do the latter without requiring the former for clients that =
don=E2=80=99t=20
>>>>>>>> otherwise need discovery.=20
>>>>>>> There is no mandate for any of this. See=20
>>>>>>> =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.tx=
t =
=20
>>>>>>>>=20
>>>>>>>> Returning the issuer and client_id from the authorization =
endpoint=20
>>>>>>>> and the client checking them can be done by the client without=20=

>>>>>>>> discovery.=20
>>>>>>>=20
>>>>>>> How does this address the issue of whether the client is talking =
to=20
>>>>>>> the wrong endpoint?=20
>>>>>>>>=20
>>>>>>>> Any client that has the resource and issuer hard coded probably=20=

>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>> We agree=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> One of the things that a client will need discovery for is to =
find=20
>>>>>>>> the RS, so requiring the client to know the RS URI before =
getting=20
>>>>>>>> the AS config seems backwards to me.=20
>>>>>>> How can you make an assumption on order? You seem to be =
conflating=20
>>>>>>> authentication with authorization by assuming the identity =
drives=20
>>>>>>> what the resource is.=20
>>>>>>>=20
>>>>>>> There are lots of applications that require user rights but are =
not=20
>>>>>>> identify centric. For example a document service.=20
>>>>>>>>=20
>>>>>>>> Unless the client tells the AS where it intends to use the =
token we=20
>>>>>>>> will be leaving a security hole because the bearer tokens will =
have=20
>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>=20
>>>>>>>> True you are telling the AS (Webfinger service) what the RS is =
but=20
>>>>>>>> that is not at a place that is useful in the token production =
process.=20
>>>>>>>=20
>>>>>>> This has nothing to do with token production.=20
>>>>>>>=20
>>>>>>> What we want to ensure is whether an honest client is correctly=20=

>>>>>>> configured and has not been mislead - eg by a phishing page.=20
>>>>>>>>=20
>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99t =
know all the=20
>>>>>>>> possible RS.   That is not something that a out of band check =
can=20
>>>>>>>> address.=20
>>>>>>>=20
>>>>>>> May be. Lets identify them.=20
>>>>>>>=20
>>>>>>>> There are also cases where a token might be good at multiple RS=20=

>>>>>>>> endpoints intentionally.=20
>>>>>>>=20
>>>>>>>>  In your solution the client would need to make a discovery =
request=20
>>>>>>>> for each endpoint.=20
>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool =
of AS=20
>>>>>>> servers assigned to each instance?=20
>>>>>>>> Those requests lack the context of who the client and resource =
owner=20
>>>>>>>> are.  I think that will be a problem in some use cases.=20
>>>>>>>=20
>>>>>>> Not sure I agree. This is about discovering a valid set of =
endpoints.=20
>>>>>>> For mitm, we mainly want to check the hostname is correct. If a=20=

>>>>>>> client chooses evil.com   =
 the cert can be valid and=20
>>>>>>> TLS will pass. How does it otherwise know it is supposed to talk =
to=20
>>>>>>> res.example.com  =
 ?=20
>>>>>>>>=20
>>>>>>>> If this is added to the token endpoint it would be checked when =
code=20
>>>>>>>> or refresh are exchanged, not every time the token is used.=20
>>>>>>> Your proposal requires rhe client to check. I am not clear how =
the AS=20
>>>>>>> can know the exact uri. It is far easier to validate than to =
lookup=20
>>>>>>> since as you say the client may be authorized to use multiple =
ASs.=20
>>>>>>>> With a out of band check the client would never know if a RS =
was=20
>>>>>>>> removed/revoked.=20
>>>>>>>=20
>>>>>>> Not sure that is in scope.=20
>>>>>>>=20
>>>>>>> None of the current proposals address this issue.=20
>>>>>>>>=20
>>>>>>>> I don=E2=80=99t see checking when refreshing a token as =
something that is a=20
>>>>>>>> huge burden.=20
>>>>>>>=20
>>>>>>> Still its a lot more than once.=20
>>>>>>>=20
>>>>>>> Why don't you draft another alternative?=20
>>>>>>>>=20
>>>>>>>> If the server wants to do the check on it=E2=80=99s side then =
we could=20
>>>>>>>> require the client to send the RS URI in the token request. =
that way=20
>>>>>>>> you really know the client is not going to get a token for the =
wrong=20
>>>>>>>> RS endpoint.=20
>>>>>>>> If you check out of band in discovery you really have no idea =
if the=20
>>>>>>>> client is checking.=20
>>>>>>>=20
>>>>>>> In the new webfinger draft, the client isn't checking. The =
service=20
>>>>>>> provider simply does not disclose oauth information to =
misconfigured=20
>>>>>>> clients.=20
>>>>>>>>=20
>>>>>>>> John B.=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt =20
>>>>>>>>>  > =
wrote:=20
>>>>>>>>>=20
>>>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll take =
each in turn:=20
>>>>>>>>>=20
>>>>>>>>> Mike,=20
>>>>>>>>>=20
>>>>>>>>> Regarding your suggested amendments=20
>>>>>>>>>=20
>>>>>>>>> Item 1: Returning the config URL would create two problems. =
One,it=20
>>>>>>>>> makes bound discovery a two-step process - that adds =
complexity.=20
>>>>>>>>>  It seems far simpler to mandate TLS (which I think it already =
does=20
>>>>>>>>> in the security considerations).=20
>>>>>>>>>=20
>>>>>>>>> The two-step process allows the current discovery process to=20=

>>>>>>>>> continue. I disagree with this. This is why I put forward an=20=

>>>>>>>>> =E2=80=9Calternate" draft that is almost the same but simply =
adds the check=20
>>>>>>>>> before returning the configuration data.  I worry that  =
developers=20
>>>>>>>>> would have no incentive to do the two-step approach. They =
would=20
>>>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at risk =
of exposing=20
>>>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>>>=20
>>>>>>>>> Regarding existing implementations. Most of those =
implementations=20
>>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue use =
of=20
>>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well =
defined=20
>>>>>>>>> and the likelihood of a client mis-informed about the resource=20=

>>>>>>>>> endpoint is not there.  IMO This does not apply to the broader=20=

>>>>>>>>> OAuth community.=20
>>>>>>>>>=20
>>>>>>>>> Item 2:  It may be appropriate to have a separate =
configuration=20
>>>>>>>>> registry specification, but I think we should hold off until =
we=20
>>>>>>>>> have a complete solution and then make the decision what =
drafts=20
>>>>>>>>> should exist and how many pieces.  A big concern is the =
perceived=20
>>>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>>>=20
>>>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>>>=20
>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a =
security threat=20
>>>>>>>>> by having a discovery specification to prevent clients being=20=

>>>>>>>>> mis-lead about endpoints (of which resource service is one) in =
an=20
>>>>>>>>> oauth protected exchange.  Maybe what you mean is we should =
not use=20
>>>>>>>>> .well-known of any kind and we should just create a =
=E2=80=9C/Config=E2=80=9D=20
>>>>>>>>> endpoint to OAuth?=20
>>>>>>>>>=20
>>>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>>>> You propose that instead the resource endpoint check should be =
in=20
>>>>>>>>> the oauth protocol itself.  The difference is that validation =
is=20
>>>>>>>>> transferred back to the client to get it right. As well, =
without=20
>>>>>>>>> the client informing the AS, I can=E2=80=99t see a way for the =
AS to know=20
>>>>>>>>> what endpoint the client is using.  The webfinger approach =
does=20
>>>>>>>>> this once and only requires that the host name be checked in =
many=20
>>>>>>>>> cases.=20
>>>>>>>>>=20
>>>>>>>>> As a principle, the members have discussed many times that the =
AS=20
>>>>>>>>> service should do validation when possible =E2=80=94 this was =
particularly=20
>>>>>>>>> true at the Germany meeting when this came up. This is why I =
prefer=20
>>>>>>>>> the client tell the service provider what it intends to do and =
the=20
>>>>>>>>> service provider can fail that request immediately if =
necessary. We=20
>>>>>>>>> don=E2=80=99t have to depend on the developer getting the spec =
correct to=20
>>>>>>>>> fail the correct way.=20
>>>>>>>>>=20
>>>>>>>>> I worry that adding more parameters to the authz and token =
protocol=20
>>>>>>>>> flows increases complexity and attack surface. It also means =
per=20
>>>>>>>>> authorization validation has to take place vs. a one-time=20
>>>>>>>>> validation at config time.  Placing it in the configuration =
lookup=20
>>>>>>>>> phase (whether via web finger or just a special OAuth =
endpoint)=20
>>>>>>>>> seems more appropriate and far less complex - as the request =
itself=20
>>>>>>>>> is simple and has only one parameter. Here we are not =
considered=20
>>>>>>>>> about legitimacy of the client. we=E2=80=99re just concerned =
with the issue=20
>>>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>>>=20
>>>>>>>>> That said, it may be that when we consider all the use cases, =
some=20
>>>>>>>>> combination of AS protocol and discovery may be both needed. =
I=E2=80=99m=20
>>>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>>>> oauth-discovery spec seems to put future generic clients at =
risk=20
>>>>>>>>> and that is my primary concern.=20
>>>>>>>>>=20
>>>>>>>>> Best Regards,=20
>>>>>>>>>=20
>>>>>>>>> Phil=20
>>>>>>>>>=20
>>>>>>>>> @independentid=20
>>>>>>>>> www.independentid.com  =
 =20
>>>>>>>>> phil.hunt@oracle.com  =
 =20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>>>  =
 =
>=20
>>>>>>>>>> wrote:=20
>>>>>>>>>>=20
>>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete =
example of=20
>>>>>>>>>> a way that protected resource discovery could be added to=20
>>>>>>>>>> authorization server metadata discovery, and as such, should=20=

>>>>>>>>>> provide useful input for working group discussions on this =
topic.=20
>>>>>>>>>> It=E2=80=99s always great when someone takes the time to =
write an actual=20
>>>>>>>>>> draft that can be examined and implemented, and I appreciate =
you=20
>>>>>>>>>> doing that.=20
>>>>>>>>>> The content of your draft points out that there appears to be=20=

>>>>>>>>>> complete agreement on what the authorization server metadata=20=

>>>>>>>>>> format should be, which is great!  I=E2=80=99ll note that =
Section 3 of=20
>>>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization =
Server=20
>>>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo=20=

>>>>>>>>>> applying a correction suggested by the working group.  To me =
this=20
>>>>>>>>>> suggests that the authorization server metadata definitions =
in=20
>>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative=20=

>>>>>>>>>> content of the draft) are clearly ready for standardization, =
since=20
>>>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>>>> Reading your draft, the problem I have with it is that you =
are=20
>>>>>>>>>> returning the AS metadata only as a WebFinger response, =
rather=20
>>>>>>>>>> than as an https-protected resource published by the =
authorization=20
>>>>>>>>>> server.  The choice to only return this via WebFinger makes =
your=20
>>>>>>>>>> draft incompatible with most deployed implementations of =
OAuth=20
>>>>>>>>>> metadata, including the 22 implementations using it listed=20
>>>>>>>>>> athttp://openid.net/certification/ <>(see the =E2=80=9COP =
Config=E2=80=9D column in=20
>>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s =
=E2=80=9CADAL=E2=80=9D=20
>>>>>>>>>> library, which uses the metadata path for client =
configuration.=20
>>>>>>>>>> Without having ASs provide the metadata as an https-protected=20=

>>>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use it =
for client=20
>>>>>>>>>> configuration as the currently do.=20
>>>>>>>>>> Therefore, I would request that you make these minor =
revisions to=20
>>>>>>>>>> your draft and republish, so as to provide a unified way =
forward=20
>>>>>>>>>> that is compatible with all known existing OAuth Discovery=20
>>>>>>>>>> deployments:=20
>>>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D=20
>>>>>>>>>> to have the WebFinger request return the issuer identifier =
for the=20
>>>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, =
rather than returning the=20
>>>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D =
value.=20
>>>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in =
your=20
>>>>>>>>>> Section 3.=20
>>>>>>>>>> That would have the advantage of paring your draft down to =
only=20
>>>>>>>>>> the new things that it proposes, enabling them to be more =
clearly=20
>>>>>>>>>> understood and evaluated on their own merits.  I look forward =
to=20
>>>>>>>>>> the discussions of ways of performing additional kinds of =
OAuth=20
>>>>>>>>>> discovery, and consider your draft a valuable input to those=20=

>>>>>>>>>> discussions.=20
>>>>>>>>>>                                                           =
Best wishes,=20
>>>>>>>>>>                                                           -- =
Mike=20
>>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org =
]*On Behalf Of*John Bradley=20
>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>>>> *To:*Phil Hunt   =
>=20
>>>>>>>>>> *Cc:*oauth  =
 >=20
>>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>> As I have told Phil off list.=20
>>>>>>>>>> Discovery is the wrong place to try and provide security =
against=20
>>>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>>>> This requires the client to know what the RS URI is before=20
>>>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>>>> The proposal Mike and I have been working on requires the =
client=20
>>>>>>>>>> to have a notion of what API it is looking for and retrieve =
the=20
>>>>>>>>>> .well-known file for that API from the issuer.   That allows =
a=20
>>>>>>>>>> protocol like Connect to register its own config file that =
can=20
>>>>>>>>>> point to the RS.=20
>>>>>>>>>> If the API specific well known is not available the client =
can try=20
>>>>>>>>>> the default oauth-server one.=20
>>>>>>>>>> That then allows us to deal with restricting where AT are=20
>>>>>>>>>> presented as part of the protocol rather then dragging =
discovery=20
>>>>>>>>>> in as a requirement.=20
>>>>>>>>>> In my opinion the resource the token is targeted to should be=20=

>>>>>>>>>> separated from the scope and returned as part of the =
meta-data=20
>>>>>>>>>> about the AT along with scopes granted and expiry time.   We=20=

>>>>>>>>>> should also have a input parameter for resources so that a =
client=20
>>>>>>>>>> can restrict tokens issued to a subset of the ones granted by =
the=20
>>>>>>>>>> refresh token.   It would then also be possible to ask a AS =
for a=20
>>>>>>>>>> token for a unregistered RS and have the AS produce a JWT =
access=20
>>>>>>>>>> token with the resource as an audience if policy allows.=20
>>>>>>>>>> That however was supposed to be dealt with as part of the =
mixed up=20
>>>>>>>>>> client set of mitigations.=20
>>>>>>>>>> In that the goal was to mitigate the attacks by returning=20
>>>>>>>>>> meta-data about the tokens, and not to require discovery.=20
>>>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_i=
d=E2=80=9D for the code, and I=20
>>>>>>>>>> intend to discuss at the F2F returning resource for AT as =
well.=20
>>>>>>>>>> Those mitigate the attack.=20
>>>>>>>>>> I will continue to resist mixing up discovery of =
configuration=20
>>>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>>>> We return meta-data about the tokens now, because AT are =
opaque to=20
>>>>>>>>>> the client, we neglected to include some of the information =
for=20
>>>>>>>>>> the client needs to be secure.   We just need to add that in =
to=20
>>>>>>>>>> the existing flows.=20
>>>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add=20
>>>>>>>>>> on, it puts more of a burden on the client needing to =
potentially=20
>>>>>>>>>> change how it stores the relationships between AS and RS to=20=

>>>>>>>>>> prevent compromise, I think the solution should be biased =
towards=20
>>>>>>>>>> simplicity on the client side.=20
>>>>>>>>>> If we return the resources as part of the existing meta data =
the=20
>>>>>>>>>> client checks that against the resource it intends to send =
the=20
>>>>>>>>>> token to and if it is not in the list then it can=E2=80=99t =
send the=20
>>>>>>>>>> token.  Simple check every time it gets a new AT, no =
optionality.=20
>>>>>>>>>> I am not saying anything new Nat has been advocating =
basically=20
>>>>>>>>>> this for some time, and dis submit a draft.   I prefer to =
return=20
>>>>>>>>>> the info in the existing format rather than as link headers,  =
but=20
>>>>>>>>>> that is the largest difference between what Nat and I are =
saying=20
>>>>>>>>>> with respect to resource.=20
>>>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20
>>>>>>>>>> I guess we will need to have a long conversation in BA.=20
>>>>>>>>>> Regards=20
>>>>>>>>>> John B.=20
>>>>>>>>>>=20
>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt =
=20
>>>>>>>>>>      =
> wrote:=20
>>>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the =
same=20
>>>>>>>>>>     registry for OAuth Config Metadata as the authors believe =
that=20
>>>>>>>>>>     both solutions are not required, or depending on WG =
discussion=20
>>>>>>>>>>     they will be merged. The intent is to provide a simple=20
>>>>>>>>>>     complete draft for consideration.=20
>>>>>>>>>>     How it works...=20
>>>>>>>>>>     Given that a client has previously discovered an OAuth=20
>>>>>>>>>>     protected resource, the bound configuration method allows =
a=20
>>>>>>>>>>     client to return the configuration for an oauth =
authorization=20
>>>>>>>>>>     server that can issue tokens for the resource URI =
specified by=20
>>>>>>>>>>     the client.  The AS is not required to be in the same =
domain.=20
>>>>>>>>>>      The AS is however required to know if it can issue =
tokens for=20
>>>>>>>>>>     a resource service (which presumes some agreement exists =
on=20
>>>>>>>>>>     tokens etc).=20
>>>>>>>>>>     The draft does not require that the resource exist (e.g. =
for=20
>>>>>>>>>>     unconfigured or new user based resources). It only =
requires=20
>>>>>>>>>>     that the AS service provider agrees it can issue tokens.=20=

>>>>>>>>>>     =46rom a security perspective, returning the OAuth =
service=20
>>>>>>>>>>     configuration for a specified resource URI serves to =
confirm=20
>>>>>>>>>>     the client is in possession of a valid resource URI =
ensuring=20
>>>>>>>>>>     the client has received a valid set of endpoints for the=20=

>>>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>>>     I propose that the WG consider the alternate draft =
carefully=20
>>>>>>>>>>     as well as other submissions and evaluate the broader=20
>>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth =
Discovery.=20
>>>>>>>>>>     Thanks!=20
>>>>>>>>>>     Phil=20
>>>>>>>>>>     @independentid=20
>>>>>>>>>>     www.independentid.com  =
 =20
>>>>>>>>>>     phil.hunt@oracle.com  =
 =20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Begin forwarded message:=20
>>>>>>>>>>         *From:*internet-drafts@ietf.org =
=20
>>>>>>>>>>          =
=20
>>>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>>>         *To:*"Phil Hunt" =20
>>>>>>>>>>          =
>, "Anthony Nadalin"=20
>>>>>>>>>>          =
 >,=20
>>>>>>>>>>         "Tony Nadalin" =20
>>>>>>>>>>          =
>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>>         has been successfully submitted by Phil Hunt and =
posted to the=20
>>>>>>>>>>         IETF repository.=20
>>>>>>>>>>=20
>>>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>>>         Revision:00=20
>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>>>         Group:Individual Submission=20
>>>>>>>>>>         Pages:22=20
>>>>>>>>>>         URL:=20
>>>>>>>>>>         =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt =

>>>>>>>>>>         Status:=20
>>>>>>>>>>         =
https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =
=20
>>>>>>>>>>         Htmlized:=20
>>>>>>>>>>         =
https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 =
=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Abstract:=20
>>>>>>>>>>           This specification defines a mechanism for the =
client of=20
>>>>>>>>>>         an OAuth 2.0=20
>>>>>>>>>>           protected resource service to obtain the =
configuration=20
>>>>>>>>>>         details of an=20
>>>>>>>>>>           OAuth 2.0 authorization server that is capable of=20=

>>>>>>>>>>         authorizing access=20
>>>>>>>>>>           to a specific resource service.  The information=20
>>>>>>>>>>         includes the OAuth=20
>>>>>>>>>>           2.0 component endpoint location URIs and as well as=20=

>>>>>>>>>>         authorization=20
>>>>>>>>>>           server capabilities.=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>         Please note that it may take a couple of minutes from =
the=20
>>>>>>>>>>         time of submission=20
>>>>>>>>>>         until the htmlized version and diff are available=20
>>>>>>>>>>         attools.ietf.org  =
 .=20
>>>>>>>>>>=20
>>>>>>>>>>         The IETF Secretariat=20
>>>>>>>>>>=20
>>>>>>>>>>     _______________________________________________=20
>>>>>>>>>>     OAuth mailing list=20
>>>>>>>>>>     OAuth@ietf.org  =
 =20
>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________=20
>>>>>> OAuth mailing list=20
>>>>>> OAuth@ietf.org   =
=20
>>>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________=20
>>>>> OAuth mailing list=20
>>>>> OAuth@ietf.org =20
>>>>> https://www.ietf.org/mailman/listinfo/oauth =
=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>>=20
>>=20
>=20
>=20


--Apple-Mail=_E0363D10-2D95-4180-8877-2CE0915742EC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I think it is a AS policy decision if it should error or take =
the requested resource and issue a token audianced for that =
resource.

    I guess =
the question is how to transition from now to a future state.   If =
you cannot upgrade all the clients at once.

    A processing rule on the AS that =
allowed some clients to not send the requested resource , but would =
error out for other upgraded clients  with a "resource not =
allowed=E2=80=9D oauth error would work and not require the return of =
the resources.  

    If you return the resources and let the client error if it is =
trying to send to the wrong endpoint that make upgrading easier, but =
gives less control to the AS.

    I could live with it ether =
way.

    The advantage of always =
sending it in the token request is that it allows the AS to do the =
mapping from a resource URI to one or more abstract audience for the =
token.

    That might help address =
George=E2=80=99s concern.

    John =
B.


    On Mar 15, 2016, at 2:44 PM, =
Brian Campbell <bcampbell@pingidentity.com> wrote:

    I was thinking it'd be simpler to error, if the requested =
resource(s) weren't okay. That puts the burden of checking in the AS. =
And doesn't add anything to the token or authorization response. I see =
the potential similarity to scope but not sure it's worth it.  =
  

    On Tue, Mar 15, 2016 at 11:37 AM, John Bradley =
<ve7jtb@ve7jtb.com> wrote:
    If the client specifies the =
resource it wants the token for, then the meta-data would not be =
required unless the resources the token is good at are different from =
the request.  
    Lat is the same logic as =
scopes.

    For =
backwards compatibility if the client is happy with the default =
resources based on scopes then I think it is a good idea to tell the =
client what the resources are in the response.

    I suspect that it is simpler with less =
optionality and always return the resources, even if they are not =
required.

    John =
B.

    On Mar 15, 2016, at 12:46 PM, Brian Campbell =
<bcampbell@pingidentity.com> wrote:

    If the client =
specifies the desired audience(s)/resource(s), is that metadata to the =
client needed? The AS can audience restrict the token as needed or =
respond with an error if it can't or wont issue a token for the resource =
the client asked for. 

    On Tue, =
Mar 15, 2016 at 9:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    Yes,  I think bearer =
tokens with no audience are a bad idea.

    The AS needs to infer an audience from =
the scopes snd/or have the client specify the desired =
audience.

    If =
the AT has a audience or audiences then as long as the endpoint URI are =
provided as meta-data with the token, the client can determine if it is =
sending the token to the correct place.

    I think Phil would prefer the server =
rather than the client do the check, but the client always needs to take =
some responsibility to not leak tokens giving them to the wrong RS or =
the code to the wrong token endpoint is leaking.

    I imagine that claims based access =
tokens are going to become more popular and the static relationship =
between one RS and one AS will not be the majority of deployments over =
time. 

    In =
any case where the client is configured up front to know the RS and the =
AS it seems like that would not require Phil=E2=80=99s Solution, but =
that is the only case supported by that discovery.
      
    If the client itself is bad =
there is not much you can do to stop it from passing on the AT in way =
way it wants.  That however is a different problem and needs =
claimed URI or attestations to prevent client spoofing.
    William and I are working on that in the mobile best =
practices draft.

    John B.


    On Mar 15, 2016, at 12:09 PM, George Fletcher =
<gffletch@aol.com> wrote:

    
 =20
   =20
 =20
  
    
    I worry about =
two
      directions I see in this thread...
    
      
    
      1. Client's accessing resources dynamically so that discovery is
      required to know the correct AS, etc. This is pretty much the
      classic use case for UMA and I'd rather not re-invent the =
wheel.
    
      
    
      2. Creating a tight coupling between RS and AS such that RS
      endpoint changes must be continually communicated to the AS. If an
      RS supports multiple AS's then the RS has to deal with
      "guaranteed" delivery. The AS needs an endpoint to receive such
      communications. If not dynamic via APIs, then deployment of the
      new RS is bound by the associated AS's getting and deploying the
      new endpoints. Can both endpoints of the RS be supported within
      the AS for some period of time, etc. This is an operation
      nightmare and almost assuredly going to go wrong in production.
    
      
    
      Maybe an OAuth2 "audience binding" spec is what's needed for those
      deployments that require this. I believe that is what John Bradley
      is suggesting.
    
      
    
      Thanks,
    
      George
    
    

    
    
    On 3/14/16 7:29 PM, Hans Zandbelt
      wrote:
    
    
    
    
    +1,
      I've found the very same in OAuth deployments that I was involved
      in; the hard part is to give names and descriptions to these
      concepts so that they cover all use cases and can be applied
      unambiguously
      
    
      
    
      Hans.
      
    
      
    
      On 3/14/16 10:44 PM, Justin Richer wrote:
      
    
      
    I agree that this is =
valuable, and not
        just for PoP. In all honesty,
        
    
        it=E2=80=99s not even really required for PoP to function in =
many cases
        =E2=80=94 it=E2=80=99s
        
    
        just an optimization for one particular kind of key distribution
        
    
        mechanism in that case.
        
    
        
    
        In the years of deployment experience with OAuth 2, I think
        we=E2=80=99ve really
        
    
        got three different kinds of things that currently get folded
        into
        
    
        =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:
        
    
        
    
        
    
          - What things do I want to access? (photos, profile)
        
    
          - What actions do I want to take on these things? (read,
        write, delete)
        
    
          - How long do I want these tokens to work?
        
    
        (offline_access/refresh_token, one time use, next hour, etc)
        
    
        
    
        
    
        I think the first one is close to the audience/resource
        parameters that
        
    
        have been bandied about a few times, including in the current
        token
        
    
        exchange document. We should be consistent across drafts in that
        regard.
        
    
        The second is more traditional scope-ish. The third has been
        patched in
        
    
        with things like =E2=80=9Coffline_access=E2=80=9D in certain =
APIs.
        
    
        
    
        Just another vector to think about if we=E2=80=99re going to be =
adding
        things
        
    
        like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.
        
    
        
    
          =E2=80=94 Justin
        
    
        
    
        
    
        
    On Mar 14, 2016, at 6:26 =
PM, John
          Bradley <ve7jtb@ve7jtb.com
          
    
          <mailto:ve7jtb@ve7jtb.com>> wrote:
          
    
          
    
          Yes I will work on another proposal for allowing clients to
          specify
          
    
          what resource they want a token for and providing the
          meta-data to the
          
    
          client about the resources that a token is valid for.
          
    
          
    
          We have part of it in the POP key distribution spec and talked
          about
          
    
          separating it, as it is used more places than just for
          assigning keys.
          
    
          I know some AS use different token formats for different RS so
          are
          
    
          all-ready needing to pass the resource in the request to avoid
          making
          
    
          a mess of scopes.
          
    
          
    
          John B.
          
    
          
    
          
    
          
    
          
    
          
    
          
    On Mar 14, 2016, at 7:17 =
PM, Phil Hunt
            (IDM) <phil.hunt@oracle.com
            
    
            <mailto:phil.hunt@oracle.com>> wrote:
            
    
            
    
            Inline
            
    
            
    
            Phil
            
    
            
    
            On Mar 14, 2016, at 14:13, John Bradley
            <ve7jtb@ve7jtb.com
            
    
            <mailto:ve7jtb@ve7jtb.com>> wrote:
            
    
            
    
            
    We had two =
mandates.  One was to
              provide a spec for AS metadata.
              
    
              The other was to mitigate the client mixup attack.  =
The
              request was
              
    
              to do the latter without requiring the former for clients
              that don=E2=80=99t
              
    
              otherwise need discovery.
              
    
            
    
            There is no mandate for any of this. See
            
    
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt
            
    
            
    
              
    
              Returning the issuer and client_id from the authorization
              endpoint
              
    
              and the client checking them can be done by the client
              without
              
    
              discovery.
              
    
            
    
            
    
            How does this address the issue of whether the client is
            talking to
            
    
            the wrong endpoint?
            
    
            
    
              
    
              Any client that has the resource and issuer hard coded
              probably
              
    
              doesn=E2=80=99t need discovery.
              
    
            
    
            We agree
            
    
            
    
            
    
            
    One of the things that =
a client will
              need discovery for is to find
              
    
              the RS, so requiring the client to know the RS URI before
              getting
              
    
              the AS config seems backwards to me.
              
    
            
    
            How can you make an assumption on order? You seem to be
            conflating
            
    
            authentication with authorization by assuming the identity
            drives
            
    
            what the resource is.
            
    
            
    
            There are lots of applications that require user rights but
            are not
            
    
            identify centric. For example a document service.
            
    
            
    
              
    
              Unless the client tells the AS where it intends to use the
              token we
              
    
              will be leaving a security hole because the bearer tokens
              will have
              
    
              too loose an audience if they have one at all.
              
    
            
    
            This is the biggest risk we have IMHO.
            
    
            
    
              
    
              True you are telling the AS (Webfinger service) what the
              RS is but
              
    
              that is not at a place that is useful in the token
              production process.
              
    
            
    
            
    
            This has nothing to do with token production.
            
    
            
    
            What we want to ensure is whether an honest client is
            correctly
            
    
            configured and has not been mislead - eg by a phishing page.
            
    
            
    
              
    
              I also think there are use cases where the AS doesn=E2=80=99=
t know
              all the
              
    
              possible RS.   That is not something that a out =
of band
              check can
              
    
              address.
              
    
            
    
            
    
            May be. Lets identify them.
            
    
            
    
            
    There are also cases =
where a token
              might be good at multiple RS
              
    
              endpoints intentionally.
              
    
            
    
            
    
            
     In your solution =
the client would
              need to make a discovery request
              
    
              for each endpoint.
              
    
            
    
            Sure. Otherwise how would it know if there is one AS or a
            pool of AS
            
    
            servers assigned to each instance?
            
    
            
    Those requests lack the =
context of
              who the client and resource owner
              
    
              are.  I think that will be a problem in some use =
cases.
              
    
            
    
            
    
            Not sure I agree. This is about discovering a valid set of
            endpoints.
            
    
            For mitm, we mainly want to check the hostname is correct.
            If a
            
    
            client chooses evil.com <http://evil.com/> the cert
            can be valid and
            
    
            TLS will pass. How does it otherwise know it is supposed to
            talk to
            
    
            res.example.com <http://res.example.com/>?
            
    
            
    
              
    
              If this is added to the token endpoint it would be checked
              when code
              
    
              or refresh are exchanged, not every time the token is
              used.
              
    
            
    
            Your proposal requires rhe client to check. I am not clear
            how the AS
            
    
            can know the exact uri. It is far easier to validate than to
            lookup
            
    
            since as you say the client may be authorized to use
            multiple ASs.
            
    
            
    With a out of band =
check the client
              would never know if a RS was
              
    
              removed/revoked.
              
    
            
    
            
    
            Not sure that is in scope.
            
    
            
    
            None of the current proposals address this issue.
            
    
            
    
              
    
              I don=E2=80=99t see checking when refreshing a token as =
something
              that is a
              
    
              huge burden.
              
    
            
    
            
    
            Still its a lot more than once.
            
    
            
    
            Why don't you draft another alternative?
            
    
            
    
              
    
              If the server wants to do the check on it=E2=80=99s side =
then we
              could
              
    
              require the client to send the RS URI in the token
              request. that way
              
    
              you really know the client is not going to get a token for
              the wrong
              
    
              RS endpoint.
              
    
              If you check out of band in discovery you really have no
              idea if the
              
    
              client is checking.
              
    
            
    
            
    
            In the new webfinger draft, the client isn't checking. The
            service
            
    
            provider simply does not disclose oauth information to
            misconfigured
            
    
            clients.
            
    
            
    
              
    
              John B.
              
    
              
    
              
    
              
    On Mar 14, 2016, at =
3:56 PM, Phil
                Hunt <phil.hunt@oracle.com
                
    
                <mailto:phil.hunt@oracle.com>> wrote:
                
    
                
    
                Thanks to Mike and John for their feedback.  I=E2=80=99=
ll take
                each in turn:
                
    
                
    
                Mike,
                
    
                
    
                Regarding your suggested amendments
                
    
                
    
                Item 1: Returning the config URL would create two
                problems. One,it
                
    
                makes bound discovery a two-step process - that adds
                complexity.
                
    
                 It seems far simpler to mandate TLS (which I think =
it
                already does
                
    
                in the security considerations).
                
    
                
    
                The two-step process allows the current discovery
                process to
                
    
                continue. I disagree with this. This is why I put
                forward an
                
    
                =E2=80=9Calternate" draft that is almost the same but =
simply
                adds the check
                
    
                before returning the configuration data.  I worry =
that 
                developers
                
    
                would have no incentive to do the two-step approach.
                They would
                
    
                just start at step 2 which in turn puts AS=E2=80=99s at =
risk of
                exposing
                
    
                tokens because it works. This makes OAuth promiscuous.
                
    
                
    
                Regarding existing implementations. Most of those
                implementations
                
    
                are for OIDC.  I think it makes sense for OIDF to
                continue use of
                
    
                OIDC's discovery spec because the UserInfo endpoint is
                well defined
                
    
                and the likelihood of a client mis-informed about the
                resource
                
    
                endpoint is not there.  IMO This does not apply to =
the
                broader
                
    
                OAuth community.
                
    
                
    
                Item 2:  It may be appropriate to have a separate
                configuration
                
    
                registry specification, but I think we should hold off
                until we
                
    
                have a complete solution and then make the decision what
                drafts
                
    
                should exist and how many pieces.  A big concern is =
the
                perceived
                
    
                complexity of multiple solutions and multiple drafts.
                
    
                
    
                As to John Bradley=E2=80=99s comments:
                
    
                
    
                Re: Discovery is the wrong place to mitigate threats.
                
    
                I=E2=80=99m confused by this.  Our mandate was to =
solve a
                security threat
                
    
                by having a discovery specification to prevent clients
                being
                
    
                mis-lead about endpoints (of which resource service is
                one) in an
                
    
                oauth protected exchange.  Maybe what you mean is =
we
                should not use
                
    
                .well-known of any kind and we should just create a
                =E2=80=9C/Config=E2=80=9D
                
    
                endpoint to OAuth?
                
    
                
    
                Re: Your proposal for MITM mitigation
                
    
                You propose that instead the resource endpoint check
                should be in
                
    
                the oauth protocol itself.  The difference is that
                validation is
                
    
                transferred back to the client to get it right. As well,
                without
                
    
                the client informing the AS, I can=E2=80=99t see a way =
for the
                AS to know
                
    
                what endpoint the client is using.  The webfinger
                approach does
                
    
                this once and only requires that the host name be
                checked in many
                
    
                cases.
                
    
                
    
                As a principle, the members have discussed many times
                that the AS
                
    
                service should do validation when possible =E2=80=94 =
this was
                particularly
                
    
                true at the Germany meeting when this came up. This is
                why I prefer
                
    
                the client tell the service provider what it intends to
                do and the
                
    
                service provider can fail that request immediately if
                necessary. We
                
    
                don=E2=80=99t have to depend on the developer getting =
the spec
                correct to
                
    
                fail the correct way.
                
    
                
    
                I worry that adding more parameters to the authz and
                token protocol
                
    
                flows increases complexity and attack surface. It also
                means per
                
    
                authorization validation has to take place vs. a
                one-time
                
    
                validation at config time.  Placing it in the
                configuration lookup
                
    
                phase (whether via web finger or just a special OAuth
                endpoint)
                
    
                seems more appropriate and far less complex - as the
                request itself
                
    
                is simple and has only one parameter. Here we are not
                considered
                
    
                about legitimacy of the client. we=E2=80=99re just =
concerned
                with the issue
                
    
                "has the client been correctly informed?=E2=80=9D
                
    
                
    
                That said, it may be that when we consider all the use
                cases, some
                
    
                combination of AS protocol and discovery may be both
                needed. I=E2=80=99m
                
    
                not ready to make conclusions about this.  The =
current
                
    
                oauth-discovery spec seems to put future generic clients
                at risk
                
    
                and that is my primary concern.
                
    
                
    
                Best Regards,
                
    
                
    
                Phil
                
    
                
    
                @independentid
                
    
                www.independentid.com
                <http://www.independentid.com/>
                
    
                phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 13, 2016, at =
10:28 PM,
                  Mike Jones
                  
    
                  <Michael.Jones@microsoft.com
                  <mailto:Michael.Jones@microsoft.com>>
                  
    
                  wrote:
                  
    
                  
    
                  Thanks for posting this, Phil.  It provides a =
concrete
                  example of
                  
    
                  a way that protected resource discovery could be added
                  to
                  
    
                  authorization server metadata discovery, and as such,
                  should
                  
    
                  provide useful input for working group discussions on
                  this topic.
                  
    
                  It=E2=80=99s always great when someone takes the time =
to write
                  an actual
                  
    
                  draft that can be examined and implemented, and I
                  appreciate you
                  
    
                  doing that.
                  
    
                  The content of your draft points out that there
                  appears to be
                  
    
                  complete agreement on what the authorization server
                  metadata
                  
    
                  format should be, which is great!  I=E2=80=99ll =
note that
                  Section 3 of
                  
    
                  draft-hunt-oauth-bound-config-00 titled =
=E2=80=9CAuthorization
                  Server
                  
    
                  Metadata=E2=80=9D is an exact copy of Section 2 of
                  
    
                  draft-ietf-oauth-discovery-01 (with the same title),
                  modulo
                  
    
                  applying a correction suggested by the working =
group. 
                  To me this
                  
    
                  suggests that the authorization server metadata
                  definitions in
                  
    
                  draft-ietf-oauth-discovery (which is now the whole
                  normative
                  
    
                  content of the draft) are clearly ready for
                  standardization, since
                  
    
                  even your alternative proposal includes them verbatim.
                  
    
                  Reading your draft, the problem I have with it is that
                  you are
                  
    
                  returning the AS metadata only as a WebFinger
                  response, rather
                  
    
                  than as an https-protected resource published by the
                  authorization
                  
    
                  server.  The choice to only return this via =
WebFinger
                  makes your
                  
    
                  draft incompatible with most deployed implementations
                  of OAuth
                  
    
                  metadata, including the 22 implementations using it
                  listed
                  
    
                  athttp://openid.net/certification/(see=
 the =E2=80=9COP Config=E2=80=9D
                  column in
                  
    
                  the table) andOAuth 2.0 libraries such as =
Microsoft=E2=80=99s
                  =E2=80=9CADAL=E2=80=9D
                  
    
                  library, which uses the metadata path for client
                  configuration.
                  
    
                  Without having ASs provide the metadata as an
                  https-protected
                  
    
                  resource, implementations such as ADAL can=E2=80=99t =
use it
                  for client
                  
    
                  configuration as the currently do.
                  
    
                  Therefore, I would request that you make these minor
                  revisions to
                  
    
                  your draft and republish, so as to provide a unified
                  way forward
                  
    
                  that is compatible with all known existing OAuth
                  Discovery
                  
    
                  deployments:
                  
    
                  1.Modify your section 2 =E2=80=9CAuthorization Server
                  WebFinger Discovery=E2=80=9D
                  
    
                  to have the WebFinger request return the issuer
                  identifier for the
                  
    
                  AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D =
value, rather than
                  returning the
                  
    
                  metadata values by value as the =E2=80=9Cproperties=E2=80=
=9D value.
                  
    
                  2.Reference the metadata definitions from Section 2 of
                  
    
                  draft-ietf-oauth-discovery, rather than duplicating
                  them in your
                  
    
                  Section 3.
                  
    
                  That would have the advantage of paring your draft
                  down to only
                  
    
                  the new things that it proposes, enabling them to be
                  more clearly
                  
    
                  understood and evaluated on their own merits.  I =
look
                  forward to
                  
    
                  the discussions of ways of performing additional kinds
                  of OAuth
                  
    
                  discovery, and consider your draft a valuable input to
                  those
                  
    
                  discussions.
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  Best wishes,
                  
    
                  =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       
                  -- Mike
                  
    
                  *From:*OAuth [mailto:oauth-bounces@ietf.org]*On =
Behalf
                  Of*John Bradley
                  
    
                  *Sent:*Sunday, March 13, 2016 6:45 PM
                  
    
                  *To:*Phil Hunt <phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>>
                  
    
                  *Cc:*oauth <oauth@ietf.org
                  <mailto:oauth@ietf.org>>
                  
    
                  *Subject:*Re: [OAUTH-WG] New Version Notification for
                  
    
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                  As I have told Phil off list.
                  
    
                  Discovery is the wrong place to try and provide
                  security against
                  
    
                  man in the middle attacks on the RS.
                  
    
                  This requires the client to know what the RS URI is
                  before
                  
    
                  retrieving the information on the AS Configuration.
                  
    
                  The proposal Mike and I have been working on requires
                  the client
                  
    
                  to have a notion of what API it is looking for and
                  retrieve the
                  
    
                  .well-known file for that API from the =
issuer.   That
                  allows a
                  
    
                  protocol like Connect to register its own config file
                  that can
                  
    
                  point to the RS.
                  
    
                  If the API specific well known is not available the
                  client can try
                  
    
                  the default oauth-server one.
                  
    
                  That then allows us to deal with restricting where AT
                  are
                  
    
                  presented as part of the protocol rather then dragging
                  discovery
                  
    
                  in as a requirement.
                  
    
                  In my opinion the resource the token is targeted to
                  should be
                  
    
                  separated from the scope and returned as part of the
                  meta-data
                  
    
                  about the AT along with scopes granted and expiry
                  time.   We
                  
    
                  should also have a input parameter for resources so
                  that a client
                  
    
                  can restrict tokens issued to a subset of the ones
                  granted by the
                  
    
                  refresh token.   It would then also be =
possible to ask
                  a AS for a
                  
    
                  token for a unregistered RS and have the AS produce a
                  JWT access
                  
    
                  token with the resource as an audience if policy
                  allows.
                  
    
                  That however was supposed to be dealt with as part of
                  the mixed up
                  
    
                  client set of mitigations.
                  
    
                  In that the goal was to mitigate the attacks by
                  returning
                  
    
                  meta-data about the tokens, and not to require
                  discovery.
                  
    
                  We intend to return =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Ccleint_id=E2=80=9D for the
                  code, and I
                  
    
                  intend to discuss at the F2F returning resource for AT
                  as well.
                  
    
                  Those mitigate the attack.
                  
    
                  I will continue to resist mixing up discovery of
                  configuration
                  
    
                  meta-data with mitigation of the attacks.
                  
    
                  We return meta-data about the tokens now, because AT
                  are opaque to
                  
    
                  the client, we neglected to include some of the
                  information for
                  
    
                  the client needs to be secure.   We just =
need to add
                  that in to
                  
    
                  the existing flows.
                  
    
                  While Phil=E2=80=99s proposal is easier for the AS to
                  implement as an add
                  
    
                  on, it puts more of a burden on the client needing to
                  potentially
                  
    
                  change how it stores the relationships between AS and
                  RS to
                  
    
                  prevent compromise, I think the solution should be
                  biased towards
                  
    
                  simplicity on the client side.
                  
    
                  If we return the resources as part of the existing
                  meta data the
                  
    
                  client checks that against the resource it intends to
                  send the
                  
    
                  token to and if it is not in the list then it can=E2=80=99=
t
                  send the
                  
    
                  token.  Simple check every time it gets a new AT, =
no
                  optionality.
                  
    
                  I am not saying anything new Nat has been advocating
                  basically
                  
    
                  this for some time, and dis submit a =
draft.   I prefer
                  to return
                  
    
                  the info in the existing format rather than as link
                  headers,  but
                  
    
                  that is the largest difference between what Nat and I
                  are saying
                  
    
                  with respect to resource.
                  
    
                  That is the core of my problem with Phil=E2=80=99s =
draft.
                  
    
                  I guess we will need to have a long conversation in
                  BA.
                  
    
                  Regards
                  
    
                  John B.
                  
    
                  
    
                      On Mar 13, 2016, at 8:12 PM, Phil =
Hunt
                  <phil.hunt@oracle.com
                  
    
                      <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                      This draft is a proposed alternate =
proposal for
                  
    
                      draft-ietf-oauth-discovery.  =
As such, it contains
                  the same
                  
    
                      registry for OAuth Config Metadata =
as the authors
                  believe that
                  
    
                      both solutions are not required, or =
depending on
                  WG discussion
                  
    
                      they will be merged. The intent is =
to provide a
                  simple
                  
    
                      complete draft for consideration.
                  
    
                      How it works...
                  
    
                      Given that a client has previously =
discovered an
                  OAuth
                  
    
                      protected resource, the bound =
configuration method
                  allows a
                  
    
                      client to return the configuration =
for an oauth
                  authorization
                  
    
                      server that can issue tokens for =
the resource URI
                  specified by
                  
    
                      the client.  The AS is not =
required to be in the
                  same domain.
                  
    
                       The AS is however required to =
know if it can
                  issue tokens for
                  
    
                      a resource service (which presumes =
some agreement
                  exists on
                  
    
                      tokens etc).
                  
    
                      The draft does not require that the =
resource exist
                  (e.g. for
                  
    
                      unconfigured or new user based =
resources). It only
                  requires
                  
    
                      that the AS service provider agrees =
it can issue
                  tokens.
                  
    
                      =46rom a security perspective, =
returning the OAuth
                  service
                  
    
                      configuration for a specified =
resource URI serves
                  to confirm
                  
    
                      the client is in possession of a =
valid resource
                  URI ensuring
                  
    
                      the client has received a valid set =
of endpoints
                  for the
                  
    
                      resource and the associated oauth =
services.
                  
    
                      I propose that the WG consider the =
alternate draft
                  carefully
                  
    
                      as well as other submissions and =
evaluate the
                  broader
                  
    
                      discovery problem before proceeding =
with WGLC on
                  OAuth Discovery.
                  
    
                      Thanks!
                  
    
                      Phil
                  
    
                      @independentid
                  
    
                      www.independentid.com
                  <http://www.independentid.com/>
                  
    
                      phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                          Begin =
forwarded message:
                  
    
                          *From:*internet-drafts@ietf.org
                  
    
                          <mailto:internet-drafts@ietf.org>
                  
    
                          *Subject: =
New Version Notification for
                  
    
                          =
draft-hunt-oauth-bound-config-00.txt*
                  
    
                          =
*Date:*March 13, 2016 at 3:53:37 PM PDT
                  
    
                          *To:*"Phil =
Hunt" <phil.hunt@yahoo.com
                  
    
                          <mailto:phil.hunt@yahoo.com>>,
                  "Anthony Nadalin"
                  
    
                          <tonynad@microsoft.com
                  <mailto:tonynad@microsoft.com>>,=

                  
    
                          "Tony =
Nadalin" <tonynad@microsoft.com
                  
    
                          <mailto:tonynad@microsoft.com>>
                  
    
                  
    
                  
    
                          A new =
version of I-D,
                  draft-hunt-oauth-bound-config-00.txt
                  
    
                          has been =
successfully submitted by Phil Hunt
                  and posted to the
                  
    
                          IETF =
repository.
                  
    
                  
    
                          =
Name:draft-hunt-oauth-bound-config
                  
    
                          Revision:00
                  
    
                          Title:OAuth =
2.0 Bound Configuration Lookup
                  
    
                          Document =
date:2016-03-13
                  
    
                          =
Group:Individual Submission
                  
    
                          Pages:22
                  
    
                          URL:
                  
    
                         
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    
                          Status:
                  
    
                         
                  https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

                  
    
                          Htmlized:
                  
    
                         
                  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                  
    
                  
    
                  
    
                          Abstract:
                  
    
                            =
This specification defines a mechanism for
                  the client of
                  
    
                          an OAuth =
2.0
                  
    
                            =
protected resource service to obtain the
                  configuration
                  
    
                          details of =
an
                  
    
                            =
OAuth 2.0 authorization server that is
                  capable of
                  
    
                          authorizing =
access
                  
    
                            =
to a specific resource service.  The
                  information
                  
    
                          includes =
the OAuth
                  
    
                            =
2.0 component endpoint location URIs and as
                  well as
                  
    
                          =
authorization
                  
    
                            =
server capabilities.
                  
    
                  
    
                  
    
                  
    
                  
    
                          Please note =
that it may take a couple of
                  minutes from the
                  
    
                          time of =
submission
                  
    
                          until the =
htmlized version and diff are
                  available
                  
    
                              attools.ietf.org
                  <http://tools.ietf.org/>.
                  
    
                  
    
                          The IETF =
Secretariat
                  
    
                  
    
                      =
_______________________________________________
                  
    
                      OAuth mailing list
                  
    
                      OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                      https://www.ietf.org/mailman/listinfo/oauth
                  
    
                
    
                
    
              
    
              
    
            
    
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.org <mailto:OAuth@ietf.org>
          
    
          https://www.ietf.org/mailman/listinfo/oauth
          
    
        
    
        
    
        
    
        
    
        _______________________________________________
        
    
        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
    


    



    


    =

--Apple-Mail=_E0363D10-2D95-4180-8877-2CE0915742EC--

--Apple-Mail=_7BE89A08-EF3D-4053-9376-96B146C72007
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxNzU2NDdaMCMGCSqGSIb3DQEJBDEWBBSIFzoq8l/aJW7WnsXqQp2e
JleXfDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCY0lZeYndLZuclYkCT1HtSlawsuHbUvew2iVj/5nyFYoa19B+Ac/xz
w2WBtdGk70me3bZpXBKFYHqWxNj681bBbpmBWOo41bIZUsOcig0bxHlvEI63+QAaZNyRXu0BYzVG
LWCKtiHcK4PJbWN37PZlKDgKi6EzaXJoaQYTCDt2yZk9gcEYTpNhswz0X/dca5Bue7PEtVvt1xsC
N8VPy1f82VcwqvPoRg1u2vcvjJcRSxKBt9LF05RNHLlAfvlSRin/HgKPe2hkNSXxqrptVmbK3cUo
cXs16rBOJKtwTLU1PTFdcyCQU44P8HvKFzMUiTC0/FRu3L5ghegacW6wa+KqAAAAAAAA
--Apple-Mail=_7BE89A08-EF3D-4053-9376-96B146C72007--


From nobody Tue Mar 15 10:57:57 2016
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 1F50012DC73 for ; Tue, 15 Mar 2016 10:57:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 SsMYixflVHXS for ; Tue, 15 Mar 2016 10:57:51 -0700 (PDT)
Received: from omr-m018e.mx.aol.com (omr-m018e.mx.aol.com [204.29.186.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E587E12DBEE for ; Tue, 15 Mar 2016 10:57:50 -0700 (PDT)
Received: from mtaout-aad01.mx.aol.com (mtaout-aad01.mx.aol.com [172.26.127.225]) by omr-m018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 39C4F3800048; Tue, 15 Mar 2016 13:57:50 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aad01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 6118F38000093; Tue, 15 Mar 2016 13:57:49 -0400 (EDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com> <56E83047.8090908@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E84D1D.1030106@aol.com>
Date: Tue, 15 Mar 2016 13:57:49 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070902050405030904070201"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458064670; bh=RRgTMdNZFcRQY7rLgnXbwDXb+jin293eNhJOyNT5FlQ=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=kQccNR8S3CR7mf1XvlgUmsyr86VSV9Tcx6tvG1XvvVGJP4GQTymvTyZvgfxwr6Yr6 baT0pCYEqcHu35BeS1cz1t10Qvtu1mBZNvnxmkn5K4g7mL45teMj7TFQ9N3SpPuD4n e0pSMz1GInm6AriYc2BcXLqjNBdF5Pgt7TvVpfD0=
x-aol-sid: 3039ac1a7fe156e84d1d21a5
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 17:57:56 -0000

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

Yes, I agree the level of indirection starts us down the road to 
discovery... but if we want the audience binding it's a road I feel we 
have to traverse. The other option creates too tight a coupling in my mind.

On 3/15/16 1:43 PM, John Bradley wrote:
> I am trying to support multiple audiences in a token.   We are agreed 
> on that.
>
> The problem with having a abstract audience is how a client would 
> verify the RS URI is correct.
>
> If we wanted abstract Audience could be a HTTPS URI with only host 
> component,  or a Fully qualified URI that can be retrieved by the 
> client to get the concrete resource endpoints.
> That however starts down the road to resource discovery.
>
> John B.
>> On Mar 15, 2016, at 12:54 PM, George Fletcher > > wrote:
>>
>> I'm not against binding audiences to a token. (Note that in many 
>> deployments today, a single access token can be used at many 
>> endpoints representing different services. It's not uncommon for a 
>> client to request a token to access the mail endpoints, messaging 
>> endpoints, contacts endpoints, etc. This requires the ability to 
>> associate multiple audiences to a single token.)
>>
>> The issue is whether it's possible to represent the RS with an 
>> abstract audience identifier (e.g. URN?) rather than a specific 
>> endpoint. Taking this approach provides a level of indirection that 
>> is much easier to configure. The AS likely knows (or can be 
>> configured) that it supports a Instant-Messaging RS. The client can 
>> then use some other mechanism to determine the exact endpoint of that 
>> abstract audience identifier. This keeps the relationships defined 
>> without the tight-coupling of registering endpoints (even with wild 
>> cards).
>>
>> Now if the direction is to move to a token can only have one 
>> audience, to me that isn't OAuth2. It's a perfectly fine model, but 
>> we should be addressing that as the next gen spec, not trying to 
>> layer it on the existing one that has different deployment semantics.
>>
>> Thanks,
>> George
>>
>> On 3/15/16 11:37 AM, John Bradley wrote:
>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>
>>> The AS needs to infer an audience from the scopes snd/or have the 
>>> client specify the desired audience.
>>>
>>> If the AT has a audience or audiences then as long as the endpoint 
>>> URI are provided as meta-data with the token, the client can 
>>> determine if it is sending the token to the correct place.
>>>
>>> I think Phil would prefer the server rather than the client do the 
>>> check, but the client always needs to take some responsibility to 
>>> not leak tokens giving them to the wrong RS or the code to the wrong 
>>> token endpoint is leaking.
>>>
>>> I imagine that claims based access tokens are going to become more 
>>> popular and the static relationship between one RS and one AS will 
>>> not be the majority of deployments over time.
>>>
>>> In any case where the client is configured up front to know the RS 
>>> and the AS it seems like that would not require Phil’s Solution, but 
>>> that is the only case supported by that discovery.
>>> If the client itself is bad there is not much you can do to stop it 
>>> from passing on the AT in way way it wants.  That however is a 
>>> different problem and needs claimed URI or attestations to prevent 
>>> client spoofing.
>>> William and I are working on that in the mobile best practices draft.
>>>
>>> John B.
>>>
>>>
>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher >>> > wrote:
>>>>
>>>> I worry about two directions I see in this thread...
>>>>
>>>> 1. Client's accessing resources dynamically so that discovery is 
>>>> required to know the correct AS, etc. This is pretty much the 
>>>> classic use case for UMA and I'd rather not re-invent the wheel.
>>>>
>>>> 2. Creating a tight coupling between RS and AS such that RS 
>>>> endpoint changes must be continually communicated to the AS. If an 
>>>> RS supports multiple AS's then the RS has to deal with "guaranteed" 
>>>> delivery. The AS needs an endpoint to receive such communications. 
>>>> If not dynamic via APIs, then deployment of the new RS is bound by 
>>>> the associated AS's getting and deploying the new endpoints. Can 
>>>> both endpoints of the RS be supported within the AS for some period 
>>>> of time, etc. This is an operation nightmare and almost assuredly 
>>>> going to go wrong in production.
>>>>
>>>> Maybe an OAuth2 "audience binding" spec is what's needed for those 
>>>> deployments that require this. I believe that is what John Bradley 
>>>> is suggesting.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>> +1, I've found the very same in OAuth deployments that I was 
>>>>> involved in; the hard part is to give names and descriptions to 
>>>>> these concepts so that they cover all use cases and can be applied 
>>>>> unambiguously
>>>>>
>>>>> Hans.
>>>>>
>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:
>>>>>> I agree that this is valuable, and not just for PoP. In all honesty,
>>>>>> it’s not even really required for PoP to function in many cases — 
>>>>>> it’s
>>>>>> just an optimization for one particular kind of key distribution
>>>>>> mechanism in that case.
>>>>>>
>>>>>> In the years of deployment experience with OAuth 2, I think we’ve 
>>>>>> really
>>>>>> got three different kinds of things that currently get folded into
>>>>>> “scope†that we might want to try separating out better:
>>>>>>
>>>>>>
>>>>>>   - What things do I want to access? (photos, profile)
>>>>>>   - What actions do I want to take on these things? (read, write, 
>>>>>> delete)
>>>>>>   - How long do I want these tokens to work?
>>>>>> (offline_access/refresh_token, one time use, next hour, etc)
>>>>>>
>>>>>>
>>>>>> I think the first one is close to the audience/resource 
>>>>>> parameters that
>>>>>> have been bandied about a few times, including in the current token
>>>>>> exchange document. We should be consistent across drafts in that 
>>>>>> regard.
>>>>>> The second is more traditional scope-ish. The third has been 
>>>>>> patched in
>>>>>> with things like “offline_access†in certain APIs.
>>>>>>
>>>>>> Just another vector to think about if we’re going to be adding 
>>>>>> things
>>>>>> like “audience†or “resource†or both to the token requests.
>>>>>>
>>>>>>   — Justin
>>>>>>
>>>>>>
>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>>>> > wrote:
>>>>>>>
>>>>>>> Yes I will work on another proposal for allowing clients to specify
>>>>>>> what resource they want a token for and providing the meta-data 
>>>>>>> to the
>>>>>>> client about the resources that a token is valid for.
>>>>>>>
>>>>>>> We have part of it in the POP key distribution spec and talked 
>>>>>>> about
>>>>>>> separating it, as it is used more places than just for assigning 
>>>>>>> keys.
>>>>>>> I know some AS use different token formats for different RS so are
>>>>>>> all-ready needing to pass the resource in the request to avoid 
>>>>>>> making
>>>>>>> a mess of scopes.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Inline
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>>>>>>> The other was to mitigate the client mixup attack.  The 
>>>>>>>>> request was
>>>>>>>>> to do the latter without requiring the former for clients that 
>>>>>>>>> don’t
>>>>>>>>> otherwise need discovery.
>>>>>>>> There is no mandate for any of this. See
>>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Returning the issuer and client_id from the authorization 
>>>>>>>>> endpoint
>>>>>>>>> and the client checking them can be done by the client without
>>>>>>>>> discovery.
>>>>>>>>
>>>>>>>> How does this address the issue of whether the client is 
>>>>>>>> talking to
>>>>>>>> the wrong endpoint?
>>>>>>>>>
>>>>>>>>> Any client that has the resource and issuer hard coded probably
>>>>>>>>> doesn’t need discovery.
>>>>>>>> We agree
>>>>>>>>
>>>>>>>>
>>>>>>>>> One of the things that a client will need discovery for is to 
>>>>>>>>> find
>>>>>>>>> the RS, so requiring the client to know the RS URI before getting
>>>>>>>>> the AS config seems backwards to me.
>>>>>>>> How can you make an assumption on order? You seem to be conflating
>>>>>>>> authentication with authorization by assuming the identity drives
>>>>>>>> what the resource is.
>>>>>>>>
>>>>>>>> There are lots of applications that require user rights but are 
>>>>>>>> not
>>>>>>>> identify centric. For example a document service.
>>>>>>>>>
>>>>>>>>> Unless the client tells the AS where it intends to use the 
>>>>>>>>> token we
>>>>>>>>> will be leaving a security hole because the bearer tokens will 
>>>>>>>>> have
>>>>>>>>> too loose an audience if they have one at all.
>>>>>>>> This is the biggest risk we have IMHO.
>>>>>>>>>
>>>>>>>>> True you are telling the AS (Webfinger service) what the RS is 
>>>>>>>>> but
>>>>>>>>> that is not at a place that is useful in the token production 
>>>>>>>>> process.
>>>>>>>>
>>>>>>>> This has nothing to do with token production.
>>>>>>>>
>>>>>>>> What we want to ensure is whether an honest client is correctly
>>>>>>>> configured and has not been mislead - eg by a phishing page.
>>>>>>>>>
>>>>>>>>> I also think there are use cases where the AS doesn’t know all 
>>>>>>>>> the
>>>>>>>>> possible RS.   That is not something that a out of band check can
>>>>>>>>> address.
>>>>>>>>
>>>>>>>> May be. Lets identify them.
>>>>>>>>
>>>>>>>>> There are also cases where a token might be good at multiple RS
>>>>>>>>> endpoints intentionally.
>>>>>>>>
>>>>>>>>>  In your solution the client would need to make a discovery 
>>>>>>>>> request
>>>>>>>>> for each endpoint.
>>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool 
>>>>>>>> of AS
>>>>>>>> servers assigned to each instance?
>>>>>>>>> Those requests lack the context of who the client and resource 
>>>>>>>>> owner
>>>>>>>>> are.  I think that will be a problem in some use cases.
>>>>>>>>
>>>>>>>> Not sure I agree. This is about discovering a valid set of 
>>>>>>>> endpoints.
>>>>>>>> For mitm, we mainly want to check the hostname is correct. If a
>>>>>>>> client chooses evil.com   
>>>>>>>> the cert can be valid and
>>>>>>>> TLS will pass. How does it otherwise know it is supposed to 
>>>>>>>> talk to
>>>>>>>> res.example.com  
>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> If this is added to the token endpoint it would be checked 
>>>>>>>>> when code
>>>>>>>>> or refresh are exchanged, not every time the token is used.
>>>>>>>> Your proposal requires rhe client to check. I am not clear how 
>>>>>>>> the AS
>>>>>>>> can know the exact uri. It is far easier to validate than to 
>>>>>>>> lookup
>>>>>>>> since as you say the client may be authorized to use multiple ASs.
>>>>>>>>> With a out of band check the client would never know if a RS was
>>>>>>>>> removed/revoked.
>>>>>>>>
>>>>>>>> Not sure that is in scope.
>>>>>>>>
>>>>>>>> None of the current proposals address this issue.
>>>>>>>>>
>>>>>>>>> I don’t see checking when refreshing a token as something that 
>>>>>>>>> is a
>>>>>>>>> huge burden.
>>>>>>>>
>>>>>>>> Still its a lot more than once.
>>>>>>>>
>>>>>>>> Why don't you draft another alternative?
>>>>>>>>>
>>>>>>>>> If the server wants to do the check on it’s side then we could
>>>>>>>>> require the client to send the RS URI in the token request. 
>>>>>>>>> that way
>>>>>>>>> you really know the client is not going to get a token for the 
>>>>>>>>> wrong
>>>>>>>>> RS endpoint.
>>>>>>>>> If you check out of band in discovery you really have no idea 
>>>>>>>>> if the
>>>>>>>>> client is checking.
>>>>>>>>
>>>>>>>> In the new webfinger draft, the client isn't checking. The service
>>>>>>>> provider simply does not disclose oauth information to 
>>>>>>>> misconfigured
>>>>>>>> clients.
>>>>>>>>>
>>>>>>>>> John B.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks to Mike and John for their feedback.  I’ll take each 
>>>>>>>>>> in turn:
>>>>>>>>>>
>>>>>>>>>> Mike,
>>>>>>>>>>
>>>>>>>>>> Regarding your suggested amendments
>>>>>>>>>>
>>>>>>>>>> Item 1: Returning the config URL would create two problems. 
>>>>>>>>>> One,it
>>>>>>>>>> makes bound discovery a two-step process - that adds complexity.
>>>>>>>>>>  It seems far simpler to mandate TLS (which I think it 
>>>>>>>>>> already does
>>>>>>>>>> in the security considerations).
>>>>>>>>>>
>>>>>>>>>> The two-step process allows the current discovery process to
>>>>>>>>>> continue. I disagree with this. This is why I put forward an
>>>>>>>>>> “alternate" draft that is almost the same but simply adds the 
>>>>>>>>>> check
>>>>>>>>>> before returning the configuration data.  I worry that  
>>>>>>>>>> developers
>>>>>>>>>> would have no incentive to do the two-step approach. They would
>>>>>>>>>> just start at step 2 which in turn puts AS’s at risk of exposing
>>>>>>>>>> tokens because it works. This makes OAuth promiscuous.
>>>>>>>>>>
>>>>>>>>>> Regarding existing implementations. Most of those 
>>>>>>>>>> implementations
>>>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue 
>>>>>>>>>> use of
>>>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well 
>>>>>>>>>> defined
>>>>>>>>>> and the likelihood of a client mis-informed about the resource
>>>>>>>>>> endpoint is not there.  IMO This does not apply to the broader
>>>>>>>>>> OAuth community.
>>>>>>>>>>
>>>>>>>>>> Item 2:  It may be appropriate to have a separate configuration
>>>>>>>>>> registry specification, but I think we should hold off until we
>>>>>>>>>> have a complete solution and then make the decision what drafts
>>>>>>>>>> should exist and how many pieces.  A big concern is the 
>>>>>>>>>> perceived
>>>>>>>>>> complexity of multiple solutions and multiple drafts.
>>>>>>>>>>
>>>>>>>>>> As to John Bradley’s comments:
>>>>>>>>>>
>>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.
>>>>>>>>>> I’m confused by this.  Our mandate was to solve a security 
>>>>>>>>>> threat
>>>>>>>>>> by having a discovery specification to prevent clients being
>>>>>>>>>> mis-lead about endpoints (of which resource service is one) 
>>>>>>>>>> in an
>>>>>>>>>> oauth protected exchange.  Maybe what you mean is we should 
>>>>>>>>>> not use
>>>>>>>>>> .well-known of any kind and we should just create a “/Configâ€
>>>>>>>>>> endpoint to OAuth?
>>>>>>>>>>
>>>>>>>>>> Re: Your proposal for MITM mitigation
>>>>>>>>>> You propose that instead the resource endpoint check should 
>>>>>>>>>> be in
>>>>>>>>>> the oauth protocol itself.  The difference is that validation is
>>>>>>>>>> transferred back to the client to get it right. As well, without
>>>>>>>>>> the client informing the AS, I can’t see a way for the AS to 
>>>>>>>>>> know
>>>>>>>>>> what endpoint the client is using.  The webfinger approach does
>>>>>>>>>> this once and only requires that the host name be checked in 
>>>>>>>>>> many
>>>>>>>>>> cases.
>>>>>>>>>>
>>>>>>>>>> As a principle, the members have discussed many times that 
>>>>>>>>>> the AS
>>>>>>>>>> service should do validation when possible — this was 
>>>>>>>>>> particularly
>>>>>>>>>> true at the Germany meeting when this came up. This is why I 
>>>>>>>>>> prefer
>>>>>>>>>> the client tell the service provider what it intends to do 
>>>>>>>>>> and the
>>>>>>>>>> service provider can fail that request immediately if 
>>>>>>>>>> necessary. We
>>>>>>>>>> don’t have to depend on the developer getting the spec 
>>>>>>>>>> correct to
>>>>>>>>>> fail the correct way.
>>>>>>>>>>
>>>>>>>>>> I worry that adding more parameters to the authz and token 
>>>>>>>>>> protocol
>>>>>>>>>> flows increases complexity and attack surface. It also means per
>>>>>>>>>> authorization validation has to take place vs. a one-time
>>>>>>>>>> validation at config time. Placing it in the configuration 
>>>>>>>>>> lookup
>>>>>>>>>> phase (whether via web finger or just a special OAuth endpoint)
>>>>>>>>>> seems more appropriate and far less complex - as the request 
>>>>>>>>>> itself
>>>>>>>>>> is simple and has only one parameter. Here we are not considered
>>>>>>>>>> about legitimacy of the client. we’re just concerned with the 
>>>>>>>>>> issue
>>>>>>>>>> "has the client been correctly informed?â€
>>>>>>>>>>
>>>>>>>>>> That said, it may be that when we consider all the use cases, 
>>>>>>>>>> some
>>>>>>>>>> combination of AS protocol and discovery may be both needed. I’m
>>>>>>>>>> not ready to make conclusions about this.  The current
>>>>>>>>>> oauth-discovery spec seems to put future generic clients at risk
>>>>>>>>>> and that is my primary concern.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> @independentid
>>>>>>>>>> www.independentid.com 
>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>>>> >>>>>>>>>> >
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete 
>>>>>>>>>>> example of
>>>>>>>>>>> a way that protected resource discovery could be added to
>>>>>>>>>>> authorization server metadata discovery, and as such, should
>>>>>>>>>>> provide useful input for working group discussions on this 
>>>>>>>>>>> topic.
>>>>>>>>>>> It’s always great when someone takes the time to write an 
>>>>>>>>>>> actual
>>>>>>>>>>> draft that can be examined and implemented, and I appreciate 
>>>>>>>>>>> you
>>>>>>>>>>> doing that.
>>>>>>>>>>> The content of your draft points out that there appears to be
>>>>>>>>>>> complete agreement on what the authorization server metadata
>>>>>>>>>>> format should be, which is great!  I’ll note that Section 3 of
>>>>>>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server
>>>>>>>>>>> Metadata†is an exact copy of Section 2 of
>>>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>>>>>>>>>>> applying a correction suggested by the working group.  To me 
>>>>>>>>>>> this
>>>>>>>>>>> suggests that the authorization server metadata definitions in
>>>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole normative
>>>>>>>>>>> content of the draft) are clearly ready for standardization, 
>>>>>>>>>>> since
>>>>>>>>>>> even your alternative proposal includes them verbatim.
>>>>>>>>>>> Reading your draft, the problem I have with it is that you are
>>>>>>>>>>> returning the AS metadata only as a WebFinger response, rather
>>>>>>>>>>> than as an https-protected resource published by the 
>>>>>>>>>>> authorization
>>>>>>>>>>> server.  The choice to only return this via WebFinger makes 
>>>>>>>>>>> your
>>>>>>>>>>> draft incompatible with most deployed implementations of OAuth
>>>>>>>>>>> metadata, including the 22 implementations using it listed
>>>>>>>>>>> athttp://openid.net/certification/(see the “OP Config†
>>>>>>>>>>> column in
>>>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft’s “ADALâ€
>>>>>>>>>>> library, which uses the metadata path for client configuration.
>>>>>>>>>>> Without having ASs provide the metadata as an https-protected
>>>>>>>>>>> resource, implementations such as ADAL can’t use it for client
>>>>>>>>>>> configuration as the currently do.
>>>>>>>>>>> Therefore, I would request that you make these minor 
>>>>>>>>>>> revisions to
>>>>>>>>>>> your draft and republish, so as to provide a unified way 
>>>>>>>>>>> forward
>>>>>>>>>>> that is compatible with all known existing OAuth Discovery
>>>>>>>>>>> deployments:
>>>>>>>>>>> 1.Modify your section 2 “Authorization Server WebFinger 
>>>>>>>>>>> Discoveryâ€
>>>>>>>>>>> to have the WebFinger request return the issuer identifier 
>>>>>>>>>>> for the
>>>>>>>>>>> AS as the “WebFinger “rel†value, rather than returning the
>>>>>>>>>>> metadata values by value as the “properties†value.
>>>>>>>>>>> 2.Reference the metadata definitions from Section 2 of
>>>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in 
>>>>>>>>>>> your
>>>>>>>>>>> Section 3.
>>>>>>>>>>> That would have the advantage of paring your draft down to only
>>>>>>>>>>> the new things that it proposes, enabling them to be more 
>>>>>>>>>>> clearly
>>>>>>>>>>> understood and evaluated on their own merits.  I look 
>>>>>>>>>>> forward to
>>>>>>>>>>> the discussions of ways of performing additional kinds of OAuth
>>>>>>>>>>> discovery, and consider your draft a valuable input to those
>>>>>>>>>>> discussions.
>>>>>>>>>>> Best wishes,
>>>>>>>>>>> -- Mike
>>>>>>>>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf 
>>>>>>>>>>> Of*John Bradley
>>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>>>> *To:*Phil Hunt >>>>>>>>>> >
>>>>>>>>>>> *Cc:*oauth >
>>>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>> As I have told Phil off list.
>>>>>>>>>>> Discovery is the wrong place to try and provide security 
>>>>>>>>>>> against
>>>>>>>>>>> man in the middle attacks on the RS.
>>>>>>>>>>> This requires the client to know what the RS URI is before
>>>>>>>>>>> retrieving the information on the AS Configuration.
>>>>>>>>>>> The proposal Mike and I have been working on requires the 
>>>>>>>>>>> client
>>>>>>>>>>> to have a notion of what API it is looking for and retrieve the
>>>>>>>>>>> .well-known file for that API from the issuer.   That allows a
>>>>>>>>>>> protocol like Connect to register its own config file that can
>>>>>>>>>>> point to the RS.
>>>>>>>>>>> If the API specific well known is not available the client 
>>>>>>>>>>> can try
>>>>>>>>>>> the default oauth-server one.
>>>>>>>>>>> That then allows us to deal with restricting where AT are
>>>>>>>>>>> presented as part of the protocol rather then dragging 
>>>>>>>>>>> discovery
>>>>>>>>>>> in as a requirement.
>>>>>>>>>>> In my opinion the resource the token is targeted to should be
>>>>>>>>>>> separated from the scope and returned as part of the meta-data
>>>>>>>>>>> about the AT along with scopes granted and expiry time.   We
>>>>>>>>>>> should also have a input parameter for resources so that a 
>>>>>>>>>>> client
>>>>>>>>>>> can restrict tokens issued to a subset of the ones granted 
>>>>>>>>>>> by the
>>>>>>>>>>> refresh token.   It would then also be possible to ask a AS 
>>>>>>>>>>> for a
>>>>>>>>>>> token for a unregistered RS and have the AS produce a JWT 
>>>>>>>>>>> access
>>>>>>>>>>> token with the resource as an audience if policy allows.
>>>>>>>>>>> That however was supposed to be dealt with as part of the 
>>>>>>>>>>> mixed up
>>>>>>>>>>> client set of mitigations.
>>>>>>>>>>> In that the goal was to mitigate the attacks by returning
>>>>>>>>>>> meta-data about the tokens, and not to require discovery.
>>>>>>>>>>> We intend to return “iss†and “cleint_id†for the code, and I
>>>>>>>>>>> intend to discuss at the F2F returning resource for AT as well.
>>>>>>>>>>> Those mitigate the attack.
>>>>>>>>>>> I will continue to resist mixing up discovery of configuration
>>>>>>>>>>> meta-data with mitigation of the attacks.
>>>>>>>>>>> We return meta-data about the tokens now, because AT are 
>>>>>>>>>>> opaque to
>>>>>>>>>>> the client, we neglected to include some of the information for
>>>>>>>>>>> the client needs to be secure.   We just need to add that in to
>>>>>>>>>>> the existing flows.
>>>>>>>>>>> While Phil’s proposal is easier for the AS to implement as 
>>>>>>>>>>> an add
>>>>>>>>>>> on, it puts more of a burden on the client needing to 
>>>>>>>>>>> potentially
>>>>>>>>>>> change how it stores the relationships between AS and RS to
>>>>>>>>>>> prevent compromise, I think the solution should be biased 
>>>>>>>>>>> towards
>>>>>>>>>>> simplicity on the client side.
>>>>>>>>>>> If we return the resources as part of the existing meta data 
>>>>>>>>>>> the
>>>>>>>>>>> client checks that against the resource it intends to send the
>>>>>>>>>>> token to and if it is not in the list then it can’t send the
>>>>>>>>>>> token.  Simple check every time it gets a new AT, no 
>>>>>>>>>>> optionality.
>>>>>>>>>>> I am not saying anything new Nat has been advocating basically
>>>>>>>>>>> this for some time, and dis submit a draft.   I prefer to 
>>>>>>>>>>> return
>>>>>>>>>>> the info in the existing format rather than as link 
>>>>>>>>>>> headers,  but
>>>>>>>>>>> that is the largest difference between what Nat and I are 
>>>>>>>>>>> saying
>>>>>>>>>>> with respect to resource.
>>>>>>>>>>> That is the core of my problem with Phil’s draft.
>>>>>>>>>>> I guess we will need to have a long conversation in BA.
>>>>>>>>>>> Regards
>>>>>>>>>>> John B.
>>>>>>>>>>>
>>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt 
>>>>>>>>>>> >>>>>>>>>> > wrote:
>>>>>>>>>>>     This draft is a proposed alternate proposal for
>>>>>>>>>>> draft-ietf-oauth-discovery. As such, it contains the same
>>>>>>>>>>>     registry for OAuth Config Metadata as the authors 
>>>>>>>>>>> believe that
>>>>>>>>>>>     both solutions are not required, or depending on WG 
>>>>>>>>>>> discussion
>>>>>>>>>>>     they will be merged. The intent is to provide a simple
>>>>>>>>>>>     complete draft for consideration.
>>>>>>>>>>>     How it works...
>>>>>>>>>>>     Given that a client has previously discovered an OAuth
>>>>>>>>>>>     protected resource, the bound configuration method allows a
>>>>>>>>>>>     client to return the configuration for an oauth 
>>>>>>>>>>> authorization
>>>>>>>>>>>     server that can issue tokens for the resource URI 
>>>>>>>>>>> specified by
>>>>>>>>>>>     the client.  The AS is not required to be in the same 
>>>>>>>>>>> domain.
>>>>>>>>>>>      The AS is however required to know if it can issue 
>>>>>>>>>>> tokens for
>>>>>>>>>>>     a resource service (which presumes some agreement exists on
>>>>>>>>>>>     tokens etc).
>>>>>>>>>>>     The draft does not require that the resource exist (e.g. 
>>>>>>>>>>> for
>>>>>>>>>>>     unconfigured or new user based resources). It only requires
>>>>>>>>>>>     that the AS service provider agrees it can issue tokens.
>>>>>>>>>>>     From a security perspective, returning the OAuth service
>>>>>>>>>>>     configuration for a specified resource URI serves to 
>>>>>>>>>>> confirm
>>>>>>>>>>>     the client is in possession of a valid resource URI 
>>>>>>>>>>> ensuring
>>>>>>>>>>>     the client has received a valid set of endpoints for the
>>>>>>>>>>>     resource and the associated oauth services.
>>>>>>>>>>>     I propose that the WG consider the alternate draft 
>>>>>>>>>>> carefully
>>>>>>>>>>>     as well as other submissions and evaluate the broader
>>>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth 
>>>>>>>>>>> Discovery.
>>>>>>>>>>>     Thanks!
>>>>>>>>>>>     Phil
>>>>>>>>>>>     @independentid
>>>>>>>>>>> www.independentid.com 
>>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Begin forwarded message:
>>>>>>>>>>>         *From:*internet-drafts@ietf.org 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>         *Subject: New Version Notification for
>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt*
>>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>>>> >, "Anthony Nadalin"
>>>>>>>>>>>         >,
>>>>>>>>>>>         "Tony Nadalin" >>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         A new version of I-D, 
>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>         has been successfully submitted by Phil Hunt and 
>>>>>>>>>>> posted to the
>>>>>>>>>>>         IETF repository.
>>>>>>>>>>>
>>>>>>>>>>> Name:draft-hunt-oauth-bound-config
>>>>>>>>>>>         Revision:00
>>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>>>>>         Document date:2016-03-13
>>>>>>>>>>>         Group:Individual Submission
>>>>>>>>>>>         Pages:22
>>>>>>>>>>>         URL:
>>>>>>>>>>> https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>         Status:
>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>>>>>         Htmlized:
>>>>>>>>>>> https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Abstract:
>>>>>>>>>>>           This specification defines a mechanism for the 
>>>>>>>>>>> client of
>>>>>>>>>>>         an OAuth 2.0
>>>>>>>>>>>           protected resource service to obtain the 
>>>>>>>>>>> configuration
>>>>>>>>>>>         details of an
>>>>>>>>>>>           OAuth 2.0 authorization server that is capable of
>>>>>>>>>>>         authorizing access
>>>>>>>>>>>           to a specific resource service.  The information
>>>>>>>>>>>         includes the OAuth
>>>>>>>>>>>           2.0 component endpoint location URIs and as well as
>>>>>>>>>>>         authorization
>>>>>>>>>>>           server capabilities.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Please note that it may take a couple of minutes 
>>>>>>>>>>> from the
>>>>>>>>>>>         time of submission
>>>>>>>>>>>         until the htmlized version and diff are available
>>>>>>>>>>> attools.ietf.org  
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>>         The IETF Secretariat
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>     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
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>
>>>
>>


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


  
    
  
  
    Yes, I agree the level of
      indirection starts us down the road to discovery... but if we want
      the audience binding it's a road I feel we have to traverse. The
      other option creates too tight a coupling in my mind.
    
    
    
    
    On 3/15/16 1:43 PM, John Bradley wrote:
    
    
    
    
    
      
      I am trying to support multiple audiences in a token.   We are
      agreed on that.
      

    
      
    
      
    The problem with having a abstract audience is how a
        client would verify the RS URI is correct.  
    
      

    
      
    
      
    If we wanted abstract Audience could be a HTTPS URI
        with only host component,  or a Fully qualified URI that can be
        retrieved by the client to get the concrete resource endpoints.
         
    
      
    That however starts down the road to resource
        discovery.
    
      

    
      
    
      
    John B.
    
        
    
          
    
            
    On Mar 15, 2016, at 12:54 PM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
              
              
     I'm not
                  against binding audiences to a token. (Note that in
                  many deployments today, a single access token can be
                  used at many endpoints representing different
                  services. It's not uncommon for a client to request a
                  token to access the mail endpoints, messaging
                  endpoints, contacts endpoints, etc. This requires the
                  ability to associate multiple audiences to a single
                  token.)
    
                  
    
                  The issue is whether it's possible to represent the RS
                  with an abstract audience identifier (e.g. URN?)
                  rather than a specific endpoint. Taking this approach
                  provides a level of indirection that is much easier to
                  configure. The AS likely knows (or can be configured)
                  that it supports a Instant-Messaging RS. The client
                  can then use some other mechanism to determine the
                  exact endpoint of that abstract audience identifier.
                  This keeps the relationships defined without the
                  tight-coupling of registering endpoints (even with
                  wild cards).
    
                  
    
                  Now if the direction is to move to a token can only
                  have one audience, to me that isn't OAuth2. It's a
                  perfectly fine model, but we should be addressing that
                  as the next gen spec, not trying to layer it on the
                  existing one that has different deployment semantics.
    
                  
    
                  Thanks,
    
                  George
    
                
    
                
    On 3/15/16 11:37 AM, John
                  Bradley wrote:
    
                
    
                
    
                  
                  Yes,  I think bearer tokens with no audience are a bad
                  idea.
                  

    
                  
    
                  
    The AS needs to infer an audience from
                    the scopes snd/or have the client specify the
                    desired audience.
    
                  

    
                  
    
                  
    If the AT has a audience or audiences
                    then as long as the endpoint URI are provided as
                    meta-data with the token, the client can determine
                    if it is sending the token to the correct place.
    
                  

    
                  
    
                  
    I think Phil would prefer the server
                    rather than the client do the check, but the client
                    always needs to take some responsibility to not leak
                    tokens giving them to the wrong RS or the code to
                    the wrong token endpoint is leaking.
    
                  

    
                  
    
                  
    I imagine that claims based access
                    tokens are going to become more popular and the
                    static relationship between one RS and one AS will
                    not be the majority of deployments over time. 
    
                  

    
                  
    
                  
    In any case where the client is
                    configured up front to know the RS and the AS it
                    seems like that would not require Phil’s Solution,
                    but that is the only case supported by that
                    discovery.
    
                  
      
    
                  
    If the client itself is bad there is not
                    much you can do to stop it from passing on the AT in
                    way way it wants.  That however is a different
                    problem and needs claimed URI or attestations to
                    prevent client spoofing.
    
                  
    William and I are working on that in the
                    mobile best practices draft.
    
                  

    
                  
    
                  
    John B.
    
                  

    
                  
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 12:09 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        
    
                          
                          
    
                            I worry about two directions I
                              see in this thread...
    
                              
    
                              1. Client's accessing resources
                              dynamically so that discovery is required
                              to know the correct AS, etc. This is
                              pretty much the classic use case for UMA
                              and I'd rather not re-invent the wheel.
    
                              
    
                              2. Creating a tight coupling between RS
                              and AS such that RS endpoint changes must
                              be continually communicated to the AS. If
                              an RS supports multiple AS's then the RS
                              has to deal with "guaranteed" delivery.
                              The AS needs an endpoint to receive such
                              communications. If not dynamic via APIs,
                              then deployment of the new RS is bound by
                              the associated AS's getting and deploying
                              the new endpoints. Can both endpoints of
                              the RS be supported within the AS for some
                              period of time, etc. This is an operation
                              nightmare and almost assuredly going to go
                              wrong in production.
    
                              
    
                              Maybe an OAuth2 "audience binding" spec is
                              what's needed for those deployments that
                              require this. I believe that is what John
                              Bradley is suggesting.
    
                              
    
                              Thanks,
    
                              George
    
                            
    
                            
    On 3/14/16 7:29
                              PM, Hans Zandbelt wrote:
    
                            
    
                            
    +1, I've found the
                              very same in OAuth deployments that I was
                              involved in; the hard part is to give
                              names and descriptions to these concepts
                              so that they cover all use cases and can
                              be applied unambiguously 
    
                              
    
                              Hans. 
    
                              
    
                              On 3/14/16 10:44 PM, Justin Richer wrote:
                              
    
                              
    I agree
                                that this is valuable, and not just for
                                PoP. In all honesty, 
    
                                it’s not even really required for PoP to
                                function in many cases — it’s 
    
                                just an optimization for one particular
                                kind of key distribution 
    
                                mechanism in that case. 
    
                                
    
                                In the years of deployment experience
                                with OAuth 2, I think we’ve really 
    
                                got three different kinds of things that
                                currently get folded into 
    
                                “scope†that we might want to try
                                separating out better: 
    
                                
    
                                
    
                                  - What things do I want to access?
                                (photos, profile) 
    
                                  - What actions do I want to take on
                                these things? (read, write, delete) 
    
                                  - How long do I want these tokens to
                                work? 
    
                                (offline_access/refresh_token, one time
                                use, next hour, etc) 
    
                                
    
                                
    
                                I think the first one is close to the
                                audience/resource parameters that 
    
                                have been bandied about a few times,
                                including in the current token 
    
                                exchange document. We should be
                                consistent across drafts in that regard.
                                
    
                                The second is more traditional
                                scope-ish. The third has been patched in
                                
    
                                with things like “offline_access†in
                                certain APIs. 
    
                                
    
                                Just another vector to think about if
                                we’re going to be adding things 
    
                                like “audience†or “resource†or both to
                                the token requests. 
    
                                
    
                                  — Justin 
    
                                
    
                                
    
                                
    On Mar
                                  14, 2016, at 6:26 PM, John Bradley
                                  <ve7jtb@ve7jtb.com
                                  
    
                                  <mailto:ve7jtb@ve7jtb.com>>

                                  wrote: 
    
                                  
    
                                  Yes I will work on another proposal
                                  for allowing clients to specify 
    
                                  what resource they want a token for
                                  and providing the meta-data to the 
    
                                  client about the resources that a
                                  token is valid for. 
    
                                  
    
                                  We have part of it in the POP key
                                  distribution spec and talked about 
    
                                  separating it, as it is used more
                                  places than just for assigning keys. 
    
                                  I know some AS use different token
                                  formats for different RS so are 
    
                                  all-ready needing to pass the resource
                                  in the request to avoid making 
    
                                  a mess of scopes. 
    
                                  
    
                                  John B. 
    
                                  
    
                                  
    
                                  
    
                                  
    
                                  
    
                                  
    On
                                    Mar 14, 2016, at 7:17 PM, Phil Hunt
                                    (IDM) <phil.hunt@oracle.com
                                    
    
                                    <mailto:phil.hunt@oracle.com>>

                                    wrote: 
    
                                    
    
                                    Inline 
    
                                    
    
                                    Phil 
    
                                    
    
                                    On Mar 14, 2016, at 14:13, John
                                    Bradley <ve7jtb@ve7jtb.com
                                    
    
                                    <mailto:ve7jtb@ve7jtb.com>>

                                    wrote: 
    
                                    
    
                                    
    We
                                      had two mandates.  One was to
                                      provide a spec for AS metadata. 
    
                                      The other was to mitigate the
                                      client mixup attack.  The request
                                      was 
    
                                      to do the latter without requiring
                                      the former for clients that don’t
                                      
    
                                      otherwise need discovery. 
    
                                    
    
                                    There is no mandate for any of this.
                                    See 
    
                                    http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
                                    
    
                                    
     
    
                                      Returning the issuer and client_id
                                      from the authorization endpoint 
    
                                      and the client checking them can
                                      be done by the client without 
    
                                      discovery. 
    
                                    
    
                                    
    
                                    How does this address the issue of
                                    whether the client is talking to 
    
                                    the wrong endpoint? 
    
                                    
     
    
                                      Any client that has the resource
                                      and issuer hard coded probably 
    
                                      doesn’t need discovery. 
    
                                    
    
                                    We agree 
    
                                    
    
                                    
    
                                    
    One
                                      of the things that a client will
                                      need discovery for is to find 
    
                                      the RS, so requiring the client to
                                      know the RS URI before getting 
    
                                      the AS config seems backwards to
                                      me. 
    
                                    
    
                                    How can you make an assumption on
                                    order? You seem to be conflating 
    
                                    authentication with authorization by
                                    assuming the identity drives 
    
                                    what the resource is. 
    
                                    
    
                                    There are lots of applications that
                                    require user rights but are not 
    
                                    identify centric. For example a
                                    document service. 
    
                                    
     
    
                                      Unless the client tells the AS
                                      where it intends to use the token
                                      we 
    
                                      will be leaving a security hole
                                      because the bearer tokens will
                                      have 
    
                                      too loose an audience if they have
                                      one at all. 
    
                                    
    
                                    This is the biggest risk we have
                                    IMHO. 
    
                                    
     
    
                                      True you are telling the AS
                                      (Webfinger service) what the RS is
                                      but 
    
                                      that is not at a place that is
                                      useful in the token production
                                      process. 
    
                                    
    
                                    
    
                                    This has nothing to do with token
                                    production. 
    
                                    
    
                                    What we want to ensure is whether an
                                    honest client is correctly 
    
                                    configured and has not been mislead
                                    - eg by a phishing page. 
    
                                    
     
    
                                      I also think there are use cases
                                      where the AS doesn’t know all the
                                      
    
                                      possible RS.   That is not
                                      something that a out of band check
                                      can 
    
                                      address. 
    
                                    
    
                                    
    
                                    May be. Lets identify them. 
    
                                    
    
                                    
    There
                                      are also cases where a token might
                                      be good at multiple RS 
    
                                      endpoints intentionally. 
    
                                    
    
                                    
    
                                    
     In
                                      your solution the client would
                                      need to make a discovery request 
    
                                      for each endpoint. 
    
                                    
    
                                    Sure. Otherwise how would it know if
                                    there is one AS or a pool of AS 
    
                                    servers assigned to each instance? 
    
                                    
    Those
                                      requests lack the context of who
                                      the client and resource owner 
    
                                      are.  I think that will be a
                                      problem in some use cases. 
    
                                    
    
                                    
    
                                    Not sure I agree. This is about
                                    discovering a valid set of
                                    endpoints. 
    
                                    For mitm, we mainly want to check
                                    the hostname is correct. If a 
    
                                    client chooses evil.com
                                    <http://evil.com/>
                                    the cert can be valid and 
    
                                    TLS will pass. How does it otherwise
                                    know it is supposed to talk to 
    
                                    res.example.com <http://res.example.com/>?
                                    
    
                                    
     
    
                                      If this is added to the token
                                      endpoint it would be checked when
                                      code 
    
                                      or refresh are exchanged, not
                                      every time the token is used. 
    
                                    
    
                                    Your proposal requires rhe client to
                                    check. I am not clear how the AS 
    
                                    can know the exact uri. It is far
                                    easier to validate than to lookup 
    
                                    since as you say the client may be
                                    authorized to use multiple ASs. 
    
                                    
    With
                                      a out of band check the client
                                      would never know if a RS was 
    
                                      removed/revoked. 
    
                                    
    
                                    
    
                                    Not sure that is in scope. 
    
                                    
    
                                    None of the current proposals
                                    address this issue. 
    
                                    
     
    
                                      I don’t see checking when
                                      refreshing a token as something
                                      that is a 
    
                                      huge burden. 
    
                                    
    
                                    
    
                                    Still its a lot more than once. 
    
                                    
    
                                    Why don't you draft another
                                    alternative? 
    
                                    
     
    
                                      If the server wants to do the
                                      check on it’s side then we could 
    
                                      require the client to send the RS
                                      URI in the token request. that way
                                      
    
                                      you really know the client is not
                                      going to get a token for the wrong
                                      
    
                                      RS endpoint. 
    
                                      If you check out of band in
                                      discovery you really have no idea
                                      if the 
    
                                      client is checking. 
    
                                    
    
                                    
    
                                    In the new webfinger draft, the
                                    client isn't checking. The service 
    
                                    provider simply does not disclose
                                    oauth information to misconfigured 
    
                                    clients. 
    
                                    
     
    
                                      John B. 
    
                                      
    
                                      
    
                                      
    On
                                        Mar 14, 2016, at 3:56 PM, Phil
                                        Hunt <phil.hunt@oracle.com 
    
                                        <mailto:phil.hunt@oracle.com>>

                                        wrote: 
    
                                        
    
                                        Thanks to Mike and John for
                                        their feedback.  I’ll take each
                                        in turn: 
    
                                        
    
                                        Mike, 
    
                                        
    
                                        Regarding your suggested
                                        amendments 
    
                                        
    
                                        Item 1: Returning the config URL
                                        would create two problems.
                                        One,it 
    
                                        makes bound discovery a two-step
                                        process - that adds complexity.
                                        
    
                                         It seems far simpler to mandate
                                        TLS (which I think it already
                                        does 
    
                                        in the security considerations).
                                        
    
                                        
    
                                        The two-step process allows the
                                        current discovery process to 
    
                                        continue. I disagree with this.
                                        This is why I put forward an 
    
                                        “alternate" draft that is almost
                                        the same but simply adds the
                                        check 
    
                                        before returning the
                                        configuration data.  I worry
                                        that  developers 
    
                                        would have no incentive to do
                                        the two-step approach. They
                                        would 
    
                                        just start at step 2 which in
                                        turn puts AS’s at risk of
                                        exposing 
    
                                        tokens because it works. This
                                        makes OAuth promiscuous. 
    
                                        
    
                                        Regarding existing
                                        implementations. Most of those
                                        implementations 
    
                                        are for OIDC.  I think it makes
                                        sense for OIDF to continue use
                                        of 
    
                                        OIDC's discovery spec because
                                        the UserInfo endpoint is well
                                        defined 
    
                                        and the likelihood of a client
                                        mis-informed about the resource
                                        
    
                                        endpoint is not there.  IMO This
                                        does not apply to the broader 
    
                                        OAuth community. 
    
                                        
    
                                        Item 2:  It may be appropriate
                                        to have a separate configuration
                                        
    
                                        registry specification, but I
                                        think we should hold off until
                                        we 
    
                                        have a complete solution and
                                        then make the decision what
                                        drafts 
    
                                        should exist and how many
                                        pieces.  A big concern is the
                                        perceived 
    
                                        complexity of multiple solutions
                                        and multiple drafts. 
    
                                        
    
                                        As to John Bradley’s comments: 
    
                                        
    
                                        Re: Discovery is the wrong place
                                        to mitigate threats. 
    
                                        I’m confused by this.  Our
                                        mandate was to solve a security
                                        threat 
    
                                        by having a discovery
                                        specification to prevent clients
                                        being 
    
                                        mis-lead about endpoints (of
                                        which resource service is one)
                                        in an 
    
                                        oauth protected exchange.  Maybe
                                        what you mean is we should not
                                        use 
    
                                        .well-known of any kind and we
                                        should just create a “/Config†
    
                                        endpoint to OAuth? 
    
                                        
    
                                        Re: Your proposal for MITM
                                        mitigation 
    
                                        You propose that instead the
                                        resource endpoint check should
                                        be in 
    
                                        the oauth protocol itself.  The
                                        difference is that validation is
                                        
    
                                        transferred back to the client
                                        to get it right. As well,
                                        without 
    
                                        the client informing the AS, I
                                        can’t see a way for the AS to
                                        know 
    
                                        what endpoint the client is
                                        using.  The webfinger approach
                                        does 
    
                                        this once and only requires that
                                        the host name be checked in many
                                        
    
                                        cases. 
    
                                        
    
                                        As a principle, the members have
                                        discussed many times that the AS
                                        
    
                                        service should do validation
                                        when possible — this was
                                        particularly 
    
                                        true at the Germany meeting when
                                        this came up. This is why I
                                        prefer 
    
                                        the client tell the service
                                        provider what it intends to do
                                        and the 
    
                                        service provider can fail that
                                        request immediately if
                                        necessary. We 
    
                                        don’t have to depend on the
                                        developer getting the spec
                                        correct to 
    
                                        fail the correct way. 
    
                                        
    
                                        I worry that adding more
                                        parameters to the authz and
                                        token protocol 
    
                                        flows increases complexity and
                                        attack surface. It also means
                                        per 
    
                                        authorization validation has to
                                        take place vs. a one-time 
    
                                        validation at config time. 
                                        Placing it in the configuration
                                        lookup 
    
                                        phase (whether via web finger or
                                        just a special OAuth endpoint) 
    
                                        seems more appropriate and far
                                        less complex - as the request
                                        itself 
    
                                        is simple and has only one
                                        parameter. Here we are not
                                        considered 
    
                                        about legitimacy of the client.
                                        we’re just concerned with the
                                        issue 
    
                                        "has the client been correctly
                                        informed?†
    
                                        
    
                                        That said, it may be that when
                                        we consider all the use cases,
                                        some 
    
                                        combination of AS protocol and
                                        discovery may be both needed.
                                        I’m 
    
                                        not ready to make conclusions
                                        about this.  The current 
    
                                        oauth-discovery spec seems to
                                        put future generic clients at
                                        risk 
    
                                        and that is my primary concern.
                                        
    
                                        
    
                                        Best Regards, 
    
                                        
    
                                        Phil 
    
                                        
    
                                        @independentid 
    
                                        www.independentid.com <http://www.independentid.com/>
                                        
    
                                        phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
                                        
    
                                        
    
                                        
    
                                        
    
                                        
    
                                        
    
                                        
    On
                                          Mar 13, 2016, at 10:28 PM,
                                          Mike Jones 
    
                                          <Michael.Jones@microsoft.com
                                          <mailto:Michael.Jones@microsoft.com>>


                                          
    
                                          wrote: 
    
                                          
    
                                          Thanks for posting this,
                                          Phil.  It provides a concrete
                                          example of 
    
                                          a way that protected resource
                                          discovery could be added to 
    
                                          authorization server metadata
                                          discovery, and as such, should
                                          
    
                                          provide useful input for
                                          working group discussions on
                                          this topic. 
    
                                          It’s always great when someone
                                          takes the time to write an
                                          actual 
    
                                          draft that can be examined and
                                          implemented, and I appreciate
                                          you 
    
                                          doing that. 
    
                                          The content of your draft
                                          points out that there appears
                                          to be 
    
                                          complete agreement on what the
                                          authorization server metadata
                                          
    
                                          format should be, which is
                                          great!  I’ll note that Section
                                          3 of 
    
                                          draft-hunt-oauth-bound-config-00
                                          titled “Authorization Server 
    
                                          Metadata†is an exact copy of
                                          Section 2 of 
    
                                          draft-ietf-oauth-discovery-01
                                          (with the same title), modulo
                                          
    
                                          applying a correction
                                          suggested by the working
                                          group.  To me this 
    
                                          suggests that the
                                          authorization server metadata
                                          definitions in 
    
                                          draft-ietf-oauth-discovery
                                          (which is now the whole
                                          normative 
    
                                          content of the draft) are
                                          clearly ready for
                                          standardization, since 
    
                                          even your alternative proposal
                                          includes them verbatim. 
    
                                          Reading your draft, the
                                          problem I have with it is that
                                          you are 
    
                                          returning the AS metadata only
                                          as a WebFinger response,
                                          rather 
    
                                          than as an https-protected
                                          resource published by the
                                          authorization 
    
                                          server.  The choice to only
                                          return this via WebFinger
                                          makes your 
    
                                          draft incompatible with most
                                          deployed implementations of
                                          OAuth 
    
                                          metadata, including the 22
                                          implementations using it
                                          listed 
    
                                          athttp://openid.net/certification/(see

                                          the “OP Config†column in 
    
                                          the table) andOAuth 2.0
                                          libraries such as Microsoft’s
                                          “ADAL†
    
                                          library, which uses the
                                          metadata path for client
                                          configuration. 
    
                                          Without having ASs provide the
                                          metadata as an https-protected
                                          
    
                                          resource, implementations such
                                          as ADAL can’t use it for
                                          client 
    
                                          configuration as the currently
                                          do. 
    
                                          Therefore, I would request
                                          that you make these minor
                                          revisions to 
    
                                          your draft and republish, so
                                          as to provide a unified way
                                          forward 
    
                                          that is compatible with all
                                          known existing OAuth Discovery
                                          
    
                                          deployments: 
    
                                          1.Modify your section 2
                                          “Authorization Server
                                          WebFinger Discovery†
    
                                          to have the WebFinger request
                                          return the issuer identifier
                                          for the 
    
                                          AS as the “WebFinger “relâ€
                                          value, rather than returning
                                          the 
    
                                          metadata values by value as
                                          the “properties†value. 
    
                                          2.Reference the metadata
                                          definitions from Section 2 of
                                          
    
                                          draft-ietf-oauth-discovery,
                                          rather than duplicating them
                                          in your 
    
                                          Section 3. 
    
                                          That would have the advantage
                                          of paring your draft down to
                                          only 
    
                                          the new things that it
                                          proposes, enabling them to be
                                          more clearly 
    
                                          understood and evaluated on
                                          their own merits.  I look
                                          forward to 
    
                                          the discussions of ways of
                                          performing additional kinds of
                                          OAuth 
    
                                          discovery, and consider your
                                          draft a valuable input to
                                          those 
    
                                          discussions. 
    
                                                                                                   


                                          Best wishes, 
    
                                                                                                   


                                          -- Mike 
    
                                          *From:*OAuth [mailto:oauth-bounces@ietf.org]*On

                                          Behalf Of*John Bradley 
    
                                          *Sent:*Sunday, March 13, 2016
                                          6:45 PM 
    
                                          *To:*Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>


                                          
    
                                          *Cc:*oauth <oauth@ietf.org
                                          <mailto:oauth@ietf.org>>


                                          
    
                                          *Subject:*Re: [OAUTH-WG] New
                                          Version Notification for 
    
                                          draft-hunt-oauth-bound-config-00.txt
                                          
    
                                          As I have told Phil off list.
                                          
    
                                          Discovery is the wrong place
                                          to try and provide security
                                          against 
    
                                          man in the middle attacks on
                                          the RS. 
    
                                          This requires the client to
                                          know what the RS URI is before
                                          
    
                                          retrieving the information on
                                          the AS Configuration. 
    
                                          The proposal Mike and I have
                                          been working on requires the
                                          client 
    
                                          to have a notion of what API
                                          it is looking for and retrieve
                                          the 
    
                                          .well-known file for that API
                                          from the issuer.   That allows
                                          a 
    
                                          protocol like Connect to
                                          register its own config file
                                          that can 
    
                                          point to the RS. 
    
                                          If the API specific well known
                                          is not available the client
                                          can try 
    
                                          the default oauth-server one.
                                          
    
                                          That then allows us to deal
                                          with restricting where AT are
                                          
    
                                          presented as part of the
                                          protocol rather then dragging
                                          discovery 
    
                                          in as a requirement. 
    
                                          In my opinion the resource the
                                          token is targeted to should be
                                          
    
                                          separated from the scope and
                                          returned as part of the
                                          meta-data 
    
                                          about the AT along with scopes
                                          granted and expiry time.   We
                                          
    
                                          should also have a input
                                          parameter for resources so
                                          that a client 
    
                                          can restrict tokens issued to
                                          a subset of the ones granted
                                          by the 
    
                                          refresh token.   It would then
                                          also be possible to ask a AS
                                          for a 
    
                                          token for a unregistered RS
                                          and have the AS produce a JWT
                                          access 
    
                                          token with the resource as an
                                          audience if policy allows. 
    
                                          That however was supposed to
                                          be dealt with as part of the
                                          mixed up 
    
                                          client set of mitigations. 
    
                                          In that the goal was to
                                          mitigate the attacks by
                                          returning 
    
                                          meta-data about the tokens,
                                          and not to require discovery.
                                          
    
                                          We intend to return “iss†and
                                          “cleint_id†for the code, and
                                          I 
    
                                          intend to discuss at the F2F
                                          returning resource for AT as
                                          well. 
    
                                          Those mitigate the attack. 
    
                                          I will continue to resist
                                          mixing up discovery of
                                          configuration 
    
                                          meta-data with mitigation of
                                          the attacks. 
    
                                          We return meta-data about the
                                          tokens now, because AT are
                                          opaque to 
    
                                          the client, we neglected to
                                          include some of the
                                          information for 
    
                                          the client needs to be
                                          secure.   We just need to add
                                          that in to 
    
                                          the existing flows. 
    
                                          While Phil’s proposal is
                                          easier for the AS to implement
                                          as an add 
    
                                          on, it puts more of a burden
                                          on the client needing to
                                          potentially 
    
                                          change how it stores the
                                          relationships between AS and
                                          RS to 
    
                                          prevent compromise, I think
                                          the solution should be biased
                                          towards 
    
                                          simplicity on the client side.
                                          
    
                                          If we return the resources as
                                          part of the existing meta data
                                          the 
    
                                          client checks that against the
                                          resource it intends to send
                                          the 
    
                                          token to and if it is not in
                                          the list then it can’t send
                                          the 
    
                                          token.  Simple check every
                                          time it gets a new AT, no
                                          optionality. 
    
                                          I am not saying anything new
                                          Nat has been advocating
                                          basically 
    
                                          this for some time, and dis
                                          submit a draft.   I prefer to
                                          return 
    
                                          the info in the existing
                                          format rather than as link
                                          headers,  but 
    
                                          that is the largest difference
                                          between what Nat and I are
                                          saying 
    
                                          with respect to resource. 
    
                                          That is the core of my problem
                                          with Phil’s draft. 
    
                                          I guess we will need to have a
                                          long conversation in BA. 
    
                                          Regards 
    
                                          John B. 
    
                                          
    
                                              On Mar 13, 2016, at 8:12
                                          PM, Phil Hunt <phil.hunt@oracle.com 
    
                                              <mailto:phil.hunt@oracle.com>>

                                          wrote: 
    
                                              This draft is a proposed
                                          alternate proposal for 
    
                                             
                                          draft-ietf-oauth-discovery. 
                                          As such, it contains the same
                                          
    
                                              registry for OAuth Config
                                          Metadata as the authors
                                          believe that 
    
                                              both solutions are not
                                          required, or depending on WG
                                          discussion 
    
                                              they will be merged. The
                                          intent is to provide a simple
                                          
    
                                              complete draft for
                                          consideration. 
    
                                              How it works... 
    
                                              Given that a client has
                                          previously discovered an OAuth
                                          
    
                                              protected resource, the
                                          bound configuration method
                                          allows a 
    
                                              client to return the
                                          configuration for an oauth
                                          authorization 
    
                                              server that can issue
                                          tokens for the resource URI
                                          specified by 
    
                                              the client.  The AS is not
                                          required to be in the same
                                          domain. 
    
                                               The AS is however
                                          required to know if it can
                                          issue tokens for 
    
                                              a resource service (which
                                          presumes some agreement exists
                                          on 
    
                                              tokens etc). 
    
                                              The draft does not require
                                          that the resource exist (e.g.
                                          for 
    
                                              unconfigured or new user
                                          based resources). It only
                                          requires 
    
                                              that the AS service
                                          provider agrees it can issue
                                          tokens. 
    
                                              From a security
                                          perspective, returning the
                                          OAuth service 
    
                                              configuration for a
                                          specified resource URI serves
                                          to confirm 
    
                                              the client is in
                                          possession of a valid resource
                                          URI ensuring 
    
                                              the client has received a
                                          valid set of endpoints for the
                                          
    
                                              resource and the
                                          associated oauth services. 
    
                                              I propose that the WG
                                          consider the alternate draft
                                          carefully 
    
                                              as well as other
                                          submissions and evaluate the
                                          broader 
    
                                              discovery problem before
                                          proceeding with WGLC on OAuth
                                          Discovery. 
    
                                              Thanks! 
    
                                              Phil 
    
                                              @independentid 
    
                                              www.independentid.com
                                          <http://www.independentid.com/>
                                          
    
                                              phil.hunt@oracle.com
                                          <mailto:phil.hunt@oracle.com>
                                          
    
                                          
    
                                          
    
                                                  Begin forwarded
                                          message: 
    
                                                  *From:*internet-drafts@ietf.org
                                          
    
                                                  <mailto:internet-drafts@ietf.org>
                                          
    
                                                  *Subject: New Version
                                          Notification for 
    
                                                 
                                          draft-hunt-oauth-bound-config-00.txt*
                                          
    
                                                  *Date:*March 13, 2016
                                          at 3:53:37 PM PDT 
    
                                                  *To:*"Phil Hunt" <phil.hunt@yahoo.com 
    
                                                  <mailto:phil.hunt@yahoo.com>>,


                                          "Anthony Nadalin" 
    
                                                  <tonynad@microsoft.com <mailto:tonynad@microsoft.com>>,


                                          
    
                                                  "Tony Nadalin" <tonynad@microsoft.com 
    
                                                  <mailto:tonynad@microsoft.com>>


                                          
    
                                          
    
                                          
    
                                                  A new version of I-D,
                                          draft-hunt-oauth-bound-config-00.txt
                                          
    
                                                  has been successfully
                                          submitted by Phil Hunt and
                                          posted to the 
    
                                                  IETF repository. 
    
                                          
    
                                                 
                                          Name:draft-hunt-oauth-bound-config
                                          
    
                                                  Revision:00 
    
                                                  Title:OAuth 2.0 Bound
                                          Configuration Lookup 
    
                                                  Document
                                          date:2016-03-13 
    
                                                  Group:Individual
                                          Submission 
    
                                                  Pages:22 
    
                                                  URL: 
    
                                                  https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                                                  Status: 
    
                                                  https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                                          
    
                                                  Htmlized: 
    
                                                  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                                          
    
                                          
    
                                          
    
                                                  Abstract: 
    
                                                    This specification
                                          defines a mechanism for the
                                          client of 
    
                                                  an OAuth 2.0 
    
                                                    protected resource
                                          service to obtain the
                                          configuration 
    
                                                  details of an 
    
                                                    OAuth 2.0
                                          authorization server that is
                                          capable of 
    
                                                  authorizing access 
    
                                                    to a specific
                                          resource service.  The
                                          information 
    
                                                  includes the OAuth 
    
                                                    2.0 component
                                          endpoint location URIs and as
                                          well as 
    
                                                  authorization 
    
                                                    server capabilities.
                                          
    
                                          
    
                                          
    
                                          
    
                                          
    
                                                  Please note that it
                                          may take a couple of minutes
                                          from the 
    
                                                  time of submission 
    
                                                  until the htmlized
                                          version and diff are available
                                          
    
                                                  attools.ietf.org
                                          <http://tools.ietf.org/>. 
    
                                          
    
                                                  The IETF Secretariat 
    
                                          
    
                                             
                                          _______________________________________________
                                          
    
                                              OAuth mailing list 
    
                                              OAuth@ietf.org
                                          <mailto:OAuth@ietf.org>
                                          
    
                                              https://www.ietf.org/mailman/listinfo/oauth
                                          
    
                                        
    
                                        
    
                                      
    
                                      
    
                                    
    
                                  
    
                                  
    
                                  _______________________________________________
                                  
    
                                  OAuth mailing list 
    
                                  OAuth@ietf.org
                                  <mailto:OAuth@ietf.org>
                                  
    
                                  https://www.ietf.org/mailman/listinfo/oauth
                                  
    
                                
    
                                
    
                                
    
                                
    
                                _______________________________________________
                                
    
                                OAuth mailing list 
    
                                OAuth@ietf.org
                                
    
                                https://www.ietf.org/mailman/listinfo/oauth
                                
    
                                
    
                              
    
                              
    
                            
    
                            
    
                          
    
                        
    
                      
    
                    
    
                    
    
                  
    
                
    
                
    
              
    
            
    
          
    
        
    
      
    
    
    
    
    
  


--------------070902050405030904070201--


From nobody Tue Mar 15 11:14:53 2016
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 74F9B12D5EE for ; Tue, 15 Mar 2016 11:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 F3weMxnqWOXb for ; Tue, 15 Mar 2016 11:14:45 -0700 (PDT)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633B212D68A for ; Tue, 15 Mar 2016 11:14:43 -0700 (PDT)
Received: from mtaout-aac01.mx.aol.com (mtaout-aac01.mx.aol.com [172.27.2.33]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 388B9380013A; Tue, 15 Mar 2016 14:14:42 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5FBCB3800009B; Tue, 15 Mar 2016 14:14:41 -0400 (EDT)
To: John Bradley , Brian Campbell 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E85111.9030308@aol.com>
Date: Tue, 15 Mar 2016 14:14:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070407080608070106030609"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458065682; bh=kWoKIAXUfDGHK+bTD3PHhKMBO65hZRg+IbMEan+LD5E=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=rIcdR9Mp0ZLaHCKArMCrRyOAz5WitDhAIAK8CjLQBs6atioVKmX5n/XuvZZPSGdsU bbTx3Ua4BbBXISTIcUhJQVY8us4w0/T3TKVTdXWG2Cg7rPxiq/Dm63ZKe5YVmtrDdn bc9V87KT3o5nS8faa11XhIsL64TID1IrQV3wg+5E=
x-aol-sid: 3039ac1b022156e85111298b
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 18:14:51 -0000

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



I think Justin provided a good break down of the different aspects a 
client wants to specify about the requested token. (my paraphrase)
   1. what RS's the token will be used at
   2. authorization privilege requests
   3. token-timing adjustments

I'm not sure passing the full endpoint to the AS will help with my 
concerns... The AS could potentially do a webfinger on the resource URI 
and determine if it's an RS that it supports... though that requires all 
RS's to support webfinger. What I really want to avoid is the AS having 
this list of URIs to RS that is almost assuredly to get out of sync.



On 3/15/16 1:56 PM, John Bradley wrote:
> I think it is a AS policy decision if it should error or take the 
> requested resource and issue a token audianced for that resource.
Actually, the error cases are interesting. What if the passed in 
resource/audience doesn't actually match a requested scope? Or some 
match and some don't? Is it better to send back a token with less 
capability? or error the entire request?
>
> I guess the question is how to transition from now to a future state. 
>   If you cannot upgrade all the clients at once.
>
> A processing rule on the AS that allowed some clients to not send the 
> requested resource , but would error out for other upgraded clients 
>  with a "resource not allowed†oauth error would work and not require 
> the return of the resources.
>
> If you return the resources and let the client error if it is trying 
> to send to the wrong endpoint that make upgrading easier, but gives 
> less control to the AS.
>
> I could live with it ether way.
>
> The advantage of always sending it in the token request is that it 
> allows the AS to do the mapping from a resource URI to one or more 
> abstract audience for the token.
I thought Justin provided a good break down of the different aspects a 
client wants to specify about the requested token. (my paraphrase)
   1. what RS's the token will be used at
   2. authorization privilege requests
   3. token-timing adjustments

The question is how does a client internally reference a resource 
server? If it's a fixed RS endpoint, then it sort of doesn't matter, the 
client isn't going to send the token to the wrong endpoint anyway and it 
can easily reference the audience by an abstract URI.

If the client can dynamically find new RS's to interact with. How does 
that happen? Does the client get handed an endpoint to use? or does it 
do some sort of discovery to determine the endpoint? I suppose both are 
possible.

Could we prescribe that the realm value of RFC 6750 error response be 
effectively a resource-service-id (like issuer for the AS). The client 
would then need to do discovery on that value to find the valid 
endpoints of the RS. This could be done once and the resource-service-id 
could be used as the "abstract" RS identifier. This requires no more 
discovery than adding an AS to the client.
>
> That might help address George’s concern.
I'm not sure passing the full endpoint to the AS will help with my 
concerns... The AS could potentially do a webfinger on the resource URI 
and determine if it's an RS that it supports... though that requires all 
RS's to support webfinger. What I really want to avoid is the AS having 
this map of URIs to RS that is almost assuredly to get out of sync.
>
> John B.
>
>
>> On Mar 15, 2016, at 2:44 PM, Brian Campbell 
>> > wrote:
>>
>> I was thinking it'd be simpler to error, if the requested resource(s) 
>> weren't okay. That puts the burden of checking in the AS. And doesn't 
>> add anything to the token or authorization response. I see the 
>> potential similarity to scope but not sure it's worth it.
>>
>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley > > wrote:
>>
>>     If the client specifies the resource it wants the token for, then
>>     the meta-data would not be required unless the resources the
>>     token is good at are different from the request.
>>     Lat is the same logic as scopes.
>>
>>     For backwards compatibility if the client is happy with the
>>     default resources based on scopes then I think it is a good idea
>>     to tell the client what the resources are in the response.
>>
>>     I suspect that it is simpler with less optionality and always
>>     return the resources, even if they are not required.
>>
>>     John B.
>>
>>>     On Mar 15, 2016, at 12:46 PM, Brian Campbell
>>>     >
>>>     wrote:
>>>
>>>     If the client specifies the desired audience(s)/resource(s), is
>>>     that metadata to the client needed? The AS can audience restrict
>>>     the token as needed or respond with an error if it can't or wont
>>>     issue a token for the resource the client asked for.
>>>
>>>     On Tue, Mar 15, 2016 at 9:37 AM, John Bradley >>     > wrote:
>>>
>>>         Yes,  I think bearer tokens with no audience are a bad idea.
>>>
>>>         The AS needs to infer an audience from the scopes snd/or
>>>         have the client specify the desired audience.
>>>
>>>         If the AT has a audience or audiences then as long as the
>>>         endpoint URI are provided as meta-data with the token, the
>>>         client can determine if it is sending the token to the
>>>         correct place.
>>>
>>>         I think Phil would prefer the server rather than the client
>>>         do the check, but the client always needs to take some
>>>         responsibility to not leak tokens giving them to the wrong
>>>         RS or the code to the wrong token endpoint is leaking.
>>>
>>>         I imagine that claims based access tokens are going to
>>>         become more popular and the static relationship between one
>>>         RS and one AS will not be the majority of deployments over
>>>         time.
>>>
>>>         In any case where the client is configured up front to know
>>>         the RS and the AS it seems like that would not require
>>>         Phil’s Solution, but that is the only case supported by that
>>>         discovery.
>>>         If the client itself is bad there is not much you can do to
>>>         stop it from passing on the AT in way way it wants. That
>>>         however is a different problem and needs claimed URI or
>>>         attestations to prevent client spoofing.
>>>         William and I are working on that in the mobile best
>>>         practices draft.
>>>
>>>         John B.
>>>
>>>
>>>>         On Mar 15, 2016, at 12:09 PM, George Fletcher
>>>>         > wrote:
>>>>
>>>>         I worry about two directions I see in this thread...
>>>>
>>>>         1. Client's accessing resources dynamically so that
>>>>         discovery is required to know the correct AS, etc. This is
>>>>         pretty much the classic use case for UMA and I'd rather not
>>>>         re-invent the wheel.
>>>>
>>>>         2. Creating a tight coupling between RS and AS such that RS
>>>>         endpoint changes must be continually communicated to the
>>>>         AS. If an RS supports multiple AS's then the RS has to deal
>>>>         with "guaranteed" delivery. The AS needs an endpoint to
>>>>         receive such communications. If not dynamic via APIs, then
>>>>         deployment of the new RS is bound by the associated AS's
>>>>         getting and deploying the new endpoints. Can both endpoints
>>>>         of the RS be supported within the AS for some period of
>>>>         time, etc. This is an operation nightmare and almost
>>>>         assuredly going to go wrong in production.
>>>>
>>>>         Maybe an OAuth2 "audience binding" spec is what's needed
>>>>         for those deployments that require this. I believe that is
>>>>         what John Bradley is suggesting.
>>>>
>>>>         Thanks,
>>>>         George
>>>>
>>>>         On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>         +1, I've found the very same in OAuth deployments that I
>>>>>         was involved in; the hard part is to give names and
>>>>>         descriptions to these concepts so that they cover all use
>>>>>         cases and can be applied unambiguously
>>>>>
>>>>>         Hans.
>>>>>
>>>>>         On 3/14/16 10:44 PM, Justin Richer wrote:
>>>>>>         I agree that this is valuable, and not just for PoP. In
>>>>>>         all honesty,
>>>>>>         it’s not even really required for PoP to function in many
>>>>>>         cases — it’s
>>>>>>         just an optimization for one particular kind of key
>>>>>>         distribution
>>>>>>         mechanism in that case.
>>>>>>
>>>>>>         In the years of deployment experience with OAuth 2, I
>>>>>>         think we’ve really
>>>>>>         got three different kinds of things that currently get
>>>>>>         folded into
>>>>>>         “scope†that we might want to try separating out better:
>>>>>>
>>>>>>
>>>>>>           - What things do I want to access? (photos, profile)
>>>>>>           - What actions do I want to take on these things?
>>>>>>         (read, write, delete)
>>>>>>           - How long do I want these tokens to work?
>>>>>>         (offline_access/refresh_token, one time use, next hour, etc)
>>>>>>
>>>>>>
>>>>>>         I think the first one is close to the audience/resource
>>>>>>         parameters that
>>>>>>         have been bandied about a few times, including in the
>>>>>>         current token
>>>>>>         exchange document. We should be consistent across drafts
>>>>>>         in that regard.
>>>>>>         The second is more traditional scope-ish. The third has
>>>>>>         been patched in
>>>>>>         with things like “offline_access†in certain APIs.
>>>>>>
>>>>>>         Just another vector to think about if we’re going to be
>>>>>>         adding things
>>>>>>         like “audience†or “resource†or both to the token requests.
>>>>>>
>>>>>>           — Justin
>>>>>>
>>>>>>
>>>>>>>         On Mar 14, 2016, at 6:26 PM, John Bradley
>>>>>>>         
>>>>>>>          >
>>>>>>>         wrote:
>>>>>>>
>>>>>>>         Yes I will work on another proposal for allowing clients
>>>>>>>         to specify
>>>>>>>         what resource they want a token for and providing the
>>>>>>>         meta-data to the
>>>>>>>         client about the resources that a token is valid for.
>>>>>>>
>>>>>>>         We have part of it in the POP key distribution spec and
>>>>>>>         talked about
>>>>>>>         separating it, as it is used more places than just for
>>>>>>>         assigning keys.
>>>>>>>         I know some AS use different token formats for different
>>>>>>>         RS so are
>>>>>>>         all-ready needing to pass the resource in the request to
>>>>>>>         avoid making
>>>>>>>         a mess of scopes.
>>>>>>>
>>>>>>>         John B.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>         On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)
>>>>>>>>         
>>>>>>>>         
>>>>>>>>         > wrote:
>>>>>>>>
>>>>>>>>         Inline
>>>>>>>>
>>>>>>>>         Phil
>>>>>>>>
>>>>>>>>         On Mar 14, 2016, at 14:13, John Bradley
>>>>>>>>         
>>>>>>>>          >
>>>>>>>>         wrote:
>>>>>>>>
>>>>>>>>>         We had two mandates.  One was to provide a spec for AS
>>>>>>>>>         metadata.
>>>>>>>>>         The other was to mitigate the client mixup attack. The
>>>>>>>>>         request was
>>>>>>>>>         to do the latter without requiring the former for
>>>>>>>>>         clients that don’t
>>>>>>>>>         otherwise need discovery.
>>>>>>>>         There is no mandate for any of this. See
>>>>>>>>         http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Returning the issuer and client_id from the
>>>>>>>>>         authorization endpoint
>>>>>>>>>         and the client checking them can be done by the client
>>>>>>>>>         without
>>>>>>>>>         discovery.
>>>>>>>>
>>>>>>>>         How does this address the issue of whether the client
>>>>>>>>         is talking to
>>>>>>>>         the wrong endpoint?
>>>>>>>>>
>>>>>>>>>         Any client that has the resource and issuer hard coded
>>>>>>>>>         probably
>>>>>>>>>         doesn’t need discovery.
>>>>>>>>         We agree
>>>>>>>>
>>>>>>>>
>>>>>>>>>         One of the things that a client will need discovery
>>>>>>>>>         for is to find
>>>>>>>>>         the RS, so requiring the client to know the RS URI
>>>>>>>>>         before getting
>>>>>>>>>         the AS config seems backwards to me.
>>>>>>>>         How can you make an assumption on order? You seem to be
>>>>>>>>         conflating
>>>>>>>>         authentication with authorization by assuming the
>>>>>>>>         identity drives
>>>>>>>>         what the resource is.
>>>>>>>>
>>>>>>>>         There are lots of applications that require user rights
>>>>>>>>         but are not
>>>>>>>>         identify centric. For example a document service.
>>>>>>>>>
>>>>>>>>>         Unless the client tells the AS where it intends to use
>>>>>>>>>         the token we
>>>>>>>>>         will be leaving a security hole because the bearer
>>>>>>>>>         tokens will have
>>>>>>>>>         too loose an audience if they have one at all.
>>>>>>>>         This is the biggest risk we have IMHO.
>>>>>>>>>
>>>>>>>>>         True you are telling the AS (Webfinger service) what
>>>>>>>>>         the RS is but
>>>>>>>>>         that is not at a place that is useful in the token
>>>>>>>>>         production process.
>>>>>>>>
>>>>>>>>         This has nothing to do with token production.
>>>>>>>>
>>>>>>>>         What we want to ensure is whether an honest client is
>>>>>>>>         correctly
>>>>>>>>         configured and has not been mislead - eg by a phishing
>>>>>>>>         page.
>>>>>>>>>
>>>>>>>>>         I also think there are use cases where the AS doesn’t
>>>>>>>>>         know all the
>>>>>>>>>         possible RS. That is not something that a out of band
>>>>>>>>>         check can
>>>>>>>>>         address.
>>>>>>>>
>>>>>>>>         May be. Lets identify them.
>>>>>>>>
>>>>>>>>>         There are also cases where a token might be good at
>>>>>>>>>         multiple RS
>>>>>>>>>         endpoints intentionally.
>>>>>>>>
>>>>>>>>>          In your solution the client would need to make a
>>>>>>>>>         discovery request
>>>>>>>>>         for each endpoint.
>>>>>>>>         Sure. Otherwise how would it know if there is one AS or
>>>>>>>>         a pool of AS
>>>>>>>>         servers assigned to each instance?
>>>>>>>>>         Those requests lack the context of who the client and
>>>>>>>>>         resource owner
>>>>>>>>>         are.  I think that will be a problem in some use cases.
>>>>>>>>
>>>>>>>>         Not sure I agree. This is about discovering a valid set
>>>>>>>>         of endpoints.
>>>>>>>>         For mitm, we mainly want to check the hostname is
>>>>>>>>         correct. If a
>>>>>>>>         client chooses evil.com 
>>>>>>>>           the cert can be
>>>>>>>>         valid and
>>>>>>>>         TLS will pass. How does it otherwise know it is
>>>>>>>>         supposed to talk to
>>>>>>>>         res.example.com 
>>>>>>>>          ?
>>>>>>>>>
>>>>>>>>>         If this is added to the token endpoint it would be
>>>>>>>>>         checked when code
>>>>>>>>>         or refresh are exchanged, not every time the token is
>>>>>>>>>         used.
>>>>>>>>         Your proposal requires rhe client to check. I am not
>>>>>>>>         clear how the AS
>>>>>>>>         can know the exact uri. It is far easier to validate
>>>>>>>>         than to lookup
>>>>>>>>         since as you say the client may be authorized to use
>>>>>>>>         multiple ASs.
>>>>>>>>>         With a out of band check the client would never know
>>>>>>>>>         if a RS was
>>>>>>>>>         removed/revoked.
>>>>>>>>
>>>>>>>>         Not sure that is in scope.
>>>>>>>>
>>>>>>>>         None of the current proposals address this issue.
>>>>>>>>>
>>>>>>>>>         I don’t see checking when refreshing a token as
>>>>>>>>>         something that is a
>>>>>>>>>         huge burden.
>>>>>>>>
>>>>>>>>         Still its a lot more than once.
>>>>>>>>
>>>>>>>>         Why don't you draft another alternative?
>>>>>>>>>
>>>>>>>>>         If the server wants to do the check on it’s side then
>>>>>>>>>         we could
>>>>>>>>>         require the client to send the RS URI in the token
>>>>>>>>>         request. that way
>>>>>>>>>         you really know the client is not going to get a token
>>>>>>>>>         for the wrong
>>>>>>>>>         RS endpoint.
>>>>>>>>>         If you check out of band in discovery you really have
>>>>>>>>>         no idea if the
>>>>>>>>>         client is checking.
>>>>>>>>
>>>>>>>>         In the new webfinger draft, the client isn't checking.
>>>>>>>>         The service
>>>>>>>>         provider simply does not disclose oauth information to
>>>>>>>>         misconfigured
>>>>>>>>         clients.
>>>>>>>>>
>>>>>>>>>         John B.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>         On Mar 14, 2016, at 3:56 PM, Phil Hunt
>>>>>>>>>>         
>>>>>>>>>>         
>>>>>>>>>>         > wrote:
>>>>>>>>>>
>>>>>>>>>>         Thanks to Mike and John for their feedback. I’ll take
>>>>>>>>>>         each in turn:
>>>>>>>>>>
>>>>>>>>>>         Mike,
>>>>>>>>>>
>>>>>>>>>>         Regarding your suggested amendments
>>>>>>>>>>
>>>>>>>>>>         Item 1: Returning the config URL would create two
>>>>>>>>>>         problems. One,it
>>>>>>>>>>         makes bound discovery a two-step process - that adds
>>>>>>>>>>         complexity.
>>>>>>>>>>          It seems far simpler to mandate TLS (which I think
>>>>>>>>>>         it already does
>>>>>>>>>>         in the security considerations).
>>>>>>>>>>
>>>>>>>>>>         The two-step process allows the current discovery
>>>>>>>>>>         process to
>>>>>>>>>>         continue. I disagree with this. This is why I put
>>>>>>>>>>         forward an
>>>>>>>>>>         “alternate" draft that is almost the same but simply
>>>>>>>>>>         adds the check
>>>>>>>>>>         before returning the configuration data.  I worry
>>>>>>>>>>         that developers
>>>>>>>>>>         would have no incentive to do the two-step approach.
>>>>>>>>>>         They would
>>>>>>>>>>         just start at step 2 which in turn puts AS’s at risk
>>>>>>>>>>         of exposing
>>>>>>>>>>         tokens because it works. This makes OAuth promiscuous.
>>>>>>>>>>
>>>>>>>>>>         Regarding existing implementations. Most of those
>>>>>>>>>>         implementations
>>>>>>>>>>         are for OIDC. I think it makes sense for OIDF to
>>>>>>>>>>         continue use of
>>>>>>>>>>         OIDC's discovery spec because the UserInfo endpoint
>>>>>>>>>>         is well defined
>>>>>>>>>>         and the likelihood of a client mis-informed about the
>>>>>>>>>>         resource
>>>>>>>>>>         endpoint is not there. IMO This does not apply to the
>>>>>>>>>>         broader
>>>>>>>>>>         OAuth community.
>>>>>>>>>>
>>>>>>>>>>         Item 2:  It may be appropriate to have a separate
>>>>>>>>>>         configuration
>>>>>>>>>>         registry specification, but I think we should hold
>>>>>>>>>>         off until we
>>>>>>>>>>         have a complete solution and then make the decision
>>>>>>>>>>         what drafts
>>>>>>>>>>         should exist and how many pieces.  A big concern is
>>>>>>>>>>         the perceived
>>>>>>>>>>         complexity of multiple solutions and multiple drafts.
>>>>>>>>>>
>>>>>>>>>>         As to John Bradley’s comments:
>>>>>>>>>>
>>>>>>>>>>         Re: Discovery is the wrong place to mitigate threats.
>>>>>>>>>>         I’m confused by this.  Our mandate was to solve a
>>>>>>>>>>         security threat
>>>>>>>>>>         by having a discovery specification to prevent
>>>>>>>>>>         clients being
>>>>>>>>>>         mis-lead about endpoints (of which resource service
>>>>>>>>>>         is one) in an
>>>>>>>>>>         oauth protected exchange. Maybe what you mean is we
>>>>>>>>>>         should not use
>>>>>>>>>>         .well-known of any kind and we should just create a
>>>>>>>>>>         “/Configâ€
>>>>>>>>>>         endpoint to OAuth?
>>>>>>>>>>
>>>>>>>>>>         Re: Your proposal for MITM mitigation
>>>>>>>>>>         You propose that instead the resource endpoint check
>>>>>>>>>>         should be in
>>>>>>>>>>         the oauth protocol itself.  The difference is that
>>>>>>>>>>         validation is
>>>>>>>>>>         transferred back to the client to get it right. As
>>>>>>>>>>         well, without
>>>>>>>>>>         the client informing the AS, I can’t see a way for
>>>>>>>>>>         the AS to know
>>>>>>>>>>         what endpoint the client is using.  The webfinger
>>>>>>>>>>         approach does
>>>>>>>>>>         this once and only requires that the host name be
>>>>>>>>>>         checked in many
>>>>>>>>>>         cases.
>>>>>>>>>>
>>>>>>>>>>         As a principle, the members have discussed many times
>>>>>>>>>>         that the AS
>>>>>>>>>>         service should do validation when possible — this was
>>>>>>>>>>         particularly
>>>>>>>>>>         true at the Germany meeting when this came up. This
>>>>>>>>>>         is why I prefer
>>>>>>>>>>         the client tell the service provider what it intends
>>>>>>>>>>         to do and the
>>>>>>>>>>         service provider can fail that request immediately if
>>>>>>>>>>         necessary. We
>>>>>>>>>>         don’t have to depend on the developer getting the
>>>>>>>>>>         spec correct to
>>>>>>>>>>         fail the correct way.
>>>>>>>>>>
>>>>>>>>>>         I worry that adding more parameters to the authz and
>>>>>>>>>>         token protocol
>>>>>>>>>>         flows increases complexity and attack surface. It
>>>>>>>>>>         also means per
>>>>>>>>>>         authorization validation has to take place vs. a
>>>>>>>>>>         one-time
>>>>>>>>>>         validation at config time. Placing it in the
>>>>>>>>>>         configuration lookup
>>>>>>>>>>         phase (whether via web finger or just a special OAuth
>>>>>>>>>>         endpoint)
>>>>>>>>>>         seems more appropriate and far less complex - as the
>>>>>>>>>>         request itself
>>>>>>>>>>         is simple and has only one parameter. Here we are not
>>>>>>>>>>         considered
>>>>>>>>>>         about legitimacy of the client. we’re just concerned
>>>>>>>>>>         with the issue
>>>>>>>>>>         "has the client been correctly informed?â€
>>>>>>>>>>
>>>>>>>>>>         That said, it may be that when we consider all the
>>>>>>>>>>         use cases, some
>>>>>>>>>>         combination of AS protocol and discovery may be both
>>>>>>>>>>         needed. I’m
>>>>>>>>>>         not ready to make conclusions about this. The current
>>>>>>>>>>         oauth-discovery spec seems to put future generic
>>>>>>>>>>         clients at risk
>>>>>>>>>>         and that is my primary concern.
>>>>>>>>>>
>>>>>>>>>>         Best Regards,
>>>>>>>>>>
>>>>>>>>>>         Phil
>>>>>>>>>>
>>>>>>>>>>         @independentid
>>>>>>>>>>         www.independentid.com 
>>>>>>>>>>         
>>>>>>>>>>         
>>>>>>>>>>         phil.hunt@oracle.com 
>>>>>>>>>>         
>>>>>>>>>>         
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>         On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>>>>         >>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         >
>>>>>>>>>>>         wrote:
>>>>>>>>>>>
>>>>>>>>>>>         Thanks for posting this, Phil.  It provides a
>>>>>>>>>>>         concrete example of
>>>>>>>>>>>         a way that protected resource discovery could be
>>>>>>>>>>>         added to
>>>>>>>>>>>         authorization server metadata discovery, and as
>>>>>>>>>>>         such, should
>>>>>>>>>>>         provide useful input for working group discussions
>>>>>>>>>>>         on this topic.
>>>>>>>>>>>         It’s always great when someone takes the time to
>>>>>>>>>>>         write an actual
>>>>>>>>>>>         draft that can be examined and implemented, and I
>>>>>>>>>>>         appreciate you
>>>>>>>>>>>         doing that.
>>>>>>>>>>>         The content of your draft points out that there
>>>>>>>>>>>         appears to be
>>>>>>>>>>>         complete agreement on what the authorization server
>>>>>>>>>>>         metadata
>>>>>>>>>>>         format should be, which is great!  I’ll note that
>>>>>>>>>>>         Section 3 of
>>>>>>>>>>>         draft-hunt-oauth-bound-config-00 titled
>>>>>>>>>>>         “Authorization Server
>>>>>>>>>>>         Metadata†is an exact copy of Section 2 of
>>>>>>>>>>>         draft-ietf-oauth-discovery-01 (with the same title),
>>>>>>>>>>>         modulo
>>>>>>>>>>>         applying a correction suggested by the working
>>>>>>>>>>>         group.  To me this
>>>>>>>>>>>         suggests that the authorization server metadata
>>>>>>>>>>>         definitions in
>>>>>>>>>>>         draft-ietf-oauth-discovery (which is now the whole
>>>>>>>>>>>         normative
>>>>>>>>>>>         content of the draft) are clearly ready for
>>>>>>>>>>>         standardization, since
>>>>>>>>>>>         even your alternative proposal includes them verbatim.
>>>>>>>>>>>         Reading your draft, the problem I have with it is
>>>>>>>>>>>         that you are
>>>>>>>>>>>         returning the AS metadata only as a WebFinger
>>>>>>>>>>>         response, rather
>>>>>>>>>>>         than as an https-protected resource published by the
>>>>>>>>>>>         authorization
>>>>>>>>>>>         server.  The choice to only return this via
>>>>>>>>>>>         WebFinger makes your
>>>>>>>>>>>         draft incompatible with most deployed
>>>>>>>>>>>         implementations of OAuth
>>>>>>>>>>>         metadata, including the 22 implementations using it
>>>>>>>>>>>         listed
>>>>>>>>>>>         athttp://openid.net/certification/(see the “OP
>>>>>>>>>>>         Config†column in
>>>>>>>>>>>         the table) andOAuth 2.0 libraries such as
>>>>>>>>>>>         Microsoft’s “ADALâ€
>>>>>>>>>>>         library, which uses the metadata path for client
>>>>>>>>>>>         configuration.
>>>>>>>>>>>         Without having ASs provide the metadata as an
>>>>>>>>>>>         https-protected
>>>>>>>>>>>         resource, implementations such as ADAL can’t use it
>>>>>>>>>>>         for client
>>>>>>>>>>>         configuration as the currently do.
>>>>>>>>>>>         Therefore, I would request that you make these minor
>>>>>>>>>>>         revisions to
>>>>>>>>>>>         your draft and republish, so as to provide a unified
>>>>>>>>>>>         way forward
>>>>>>>>>>>         that is compatible with all known existing OAuth
>>>>>>>>>>>         Discovery
>>>>>>>>>>>         deployments:
>>>>>>>>>>>         1.Modify your section 2 “Authorization Server
>>>>>>>>>>>         WebFinger Discoveryâ€
>>>>>>>>>>>         to have the WebFinger request return the issuer
>>>>>>>>>>>         identifier for the
>>>>>>>>>>>         AS as the “WebFinger “rel†value, rather than
>>>>>>>>>>>         returning the
>>>>>>>>>>>         metadata values by value as the “properties†value.
>>>>>>>>>>>         2.Reference the metadata definitions from Section 2 of
>>>>>>>>>>>         draft-ietf-oauth-discovery, rather than duplicating
>>>>>>>>>>>         them in your
>>>>>>>>>>>         Section 3.
>>>>>>>>>>>         That would have the advantage of paring your draft
>>>>>>>>>>>         down to only
>>>>>>>>>>>         the new things that it proposes, enabling them to be
>>>>>>>>>>>         more clearly
>>>>>>>>>>>         understood and evaluated on their own merits.  I
>>>>>>>>>>>         look forward to
>>>>>>>>>>>         the discussions of ways of performing additional
>>>>>>>>>>>         kinds of OAuth
>>>>>>>>>>>         discovery, and consider your draft a valuable input
>>>>>>>>>>>         to those
>>>>>>>>>>>         discussions.
>>>>>>>>>>>         Best wishes,
>>>>>>>>>>>         -- Mike
>>>>>>>>>>>         *From:*OAuth [mailto:oauth-bounces@ietf.org]*On
>>>>>>>>>>>         Behalf Of*John Bradley
>>>>>>>>>>>         *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>>>>         *To:*Phil Hunt >>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         >
>>>>>>>>>>>         *Cc:*oauth 
>>>>>>>>>>>          >
>>>>>>>>>>>         *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>         As I have told Phil off list.
>>>>>>>>>>>         Discovery is the wrong place to try and provide
>>>>>>>>>>>         security against
>>>>>>>>>>>         man in the middle attacks on the RS.
>>>>>>>>>>>         This requires the client to know what the RS URI is
>>>>>>>>>>>         before
>>>>>>>>>>>         retrieving the information on the AS Configuration.
>>>>>>>>>>>         The proposal Mike and I have been working on
>>>>>>>>>>>         requires the client
>>>>>>>>>>>         to have a notion of what API it is looking for and
>>>>>>>>>>>         retrieve the
>>>>>>>>>>>         .well-known file for that API from the issuer.  
>>>>>>>>>>>         That allows a
>>>>>>>>>>>         protocol like Connect to register its own config
>>>>>>>>>>>         file that can
>>>>>>>>>>>         point to the RS.
>>>>>>>>>>>         If the API specific well known is not available the
>>>>>>>>>>>         client can try
>>>>>>>>>>>         the default oauth-server one.
>>>>>>>>>>>         That then allows us to deal with restricting where
>>>>>>>>>>>         AT are
>>>>>>>>>>>         presented as part of the protocol rather then
>>>>>>>>>>>         dragging discovery
>>>>>>>>>>>         in as a requirement.
>>>>>>>>>>>         In my opinion the resource the token is targeted to
>>>>>>>>>>>         should be
>>>>>>>>>>>         separated from the scope and returned as part of the
>>>>>>>>>>>         meta-data
>>>>>>>>>>>         about the AT along with scopes granted and expiry
>>>>>>>>>>>         time.   We
>>>>>>>>>>>         should also have a input parameter for resources so
>>>>>>>>>>>         that a client
>>>>>>>>>>>         can restrict tokens issued to a subset of the ones
>>>>>>>>>>>         granted by the
>>>>>>>>>>>         refresh token.   It would then also be possible to
>>>>>>>>>>>         ask a AS for a
>>>>>>>>>>>         token for a unregistered RS and have the AS produce
>>>>>>>>>>>         a JWT access
>>>>>>>>>>>         token with the resource as an audience if policy
>>>>>>>>>>>         allows.
>>>>>>>>>>>         That however was supposed to be dealt with as part
>>>>>>>>>>>         of the mixed up
>>>>>>>>>>>         client set of mitigations.
>>>>>>>>>>>         In that the goal was to mitigate the attacks by
>>>>>>>>>>>         returning
>>>>>>>>>>>         meta-data about the tokens, and not to require
>>>>>>>>>>>         discovery.
>>>>>>>>>>>         We intend to return “iss†and “cleint_id†for the
>>>>>>>>>>>         code, and I
>>>>>>>>>>>         intend to discuss at the F2F returning resource for
>>>>>>>>>>>         AT as well.
>>>>>>>>>>>         Those mitigate the attack.
>>>>>>>>>>>         I will continue to resist mixing up discovery of
>>>>>>>>>>>         configuration
>>>>>>>>>>>         meta-data with mitigation of the attacks.
>>>>>>>>>>>         We return meta-data about the tokens now, because AT
>>>>>>>>>>>         are opaque to
>>>>>>>>>>>         the client, we neglected to include some of the
>>>>>>>>>>>         information for
>>>>>>>>>>>         the client needs to be secure.   We just need to add
>>>>>>>>>>>         that in to
>>>>>>>>>>>         the existing flows.
>>>>>>>>>>>         While Phil’s proposal is easier for the AS to
>>>>>>>>>>>         implement as an add
>>>>>>>>>>>         on, it puts more of a burden on the client needing
>>>>>>>>>>>         to potentially
>>>>>>>>>>>         change how it stores the relationships between AS
>>>>>>>>>>>         and RS to
>>>>>>>>>>>         prevent compromise, I think the solution should be
>>>>>>>>>>>         biased towards
>>>>>>>>>>>         simplicity on the client side.
>>>>>>>>>>>         If we return the resources as part of the existing
>>>>>>>>>>>         meta data the
>>>>>>>>>>>         client checks that against the resource it intends
>>>>>>>>>>>         to send the
>>>>>>>>>>>         token to and if it is not in the list then it can’t
>>>>>>>>>>>         send the
>>>>>>>>>>>         token.  Simple check every time it gets a new AT, no
>>>>>>>>>>>         optionality.
>>>>>>>>>>>         I am not saying anything new Nat has been advocating
>>>>>>>>>>>         basically
>>>>>>>>>>>         this for some time, and dis submit a draft.   I
>>>>>>>>>>>         prefer to return
>>>>>>>>>>>         the info in the existing format rather than as link
>>>>>>>>>>>         headers,  but
>>>>>>>>>>>         that is the largest difference between what Nat and
>>>>>>>>>>>         I are saying
>>>>>>>>>>>         with respect to resource.
>>>>>>>>>>>         That is the core of my problem with Phil’s draft.
>>>>>>>>>>>         I guess we will need to have a long conversation in BA.
>>>>>>>>>>>         Regards
>>>>>>>>>>>         John B.
>>>>>>>>>>>
>>>>>>>>>>>             On Mar 13, 2016, at 8:12 PM, Phil Hunt
>>>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         > wrote:
>>>>>>>>>>>             This draft is a proposed alternate proposal for
>>>>>>>>>>>         draft-ietf-oauth-discovery. As such, it contains the
>>>>>>>>>>>         same
>>>>>>>>>>>             registry for OAuth Config Metadata as the
>>>>>>>>>>>         authors believe that
>>>>>>>>>>>             both solutions are not required, or depending on
>>>>>>>>>>>         WG discussion
>>>>>>>>>>>             they will be merged. The intent is to provide a
>>>>>>>>>>>         simple
>>>>>>>>>>>             complete draft for consideration.
>>>>>>>>>>>             How it works...
>>>>>>>>>>>             Given that a client has previously discovered an
>>>>>>>>>>>         OAuth
>>>>>>>>>>>             protected resource, the bound configuration
>>>>>>>>>>>         method allows a
>>>>>>>>>>>             client to return the configuration for an oauth
>>>>>>>>>>>         authorization
>>>>>>>>>>>             server that can issue tokens for the resource
>>>>>>>>>>>         URI specified by
>>>>>>>>>>>             the client.  The AS is not required to be in the
>>>>>>>>>>>         same domain.
>>>>>>>>>>>              The AS is however required to know if it can
>>>>>>>>>>>         issue tokens for
>>>>>>>>>>>             a resource service (which presumes some
>>>>>>>>>>>         agreement exists on
>>>>>>>>>>>             tokens etc).
>>>>>>>>>>>             The draft does not require that the resource
>>>>>>>>>>>         exist (e.g. for
>>>>>>>>>>>         unconfigured or new user based resources). It only
>>>>>>>>>>>         requires
>>>>>>>>>>>             that the AS service provider agrees it can issue
>>>>>>>>>>>         tokens.
>>>>>>>>>>>             From a security perspective, returning the OAuth
>>>>>>>>>>>         service
>>>>>>>>>>>         configuration for a specified resource URI serves to
>>>>>>>>>>>         confirm
>>>>>>>>>>>             the client is in possession of a valid resource
>>>>>>>>>>>         URI ensuring
>>>>>>>>>>>             the client has received a valid set of endpoints
>>>>>>>>>>>         for the
>>>>>>>>>>>             resource and the associated oauth services.
>>>>>>>>>>>             I propose that the WG consider the alternate
>>>>>>>>>>>         draft carefully
>>>>>>>>>>>             as well as other submissions and evaluate the
>>>>>>>>>>>         broader
>>>>>>>>>>>             discovery problem before proceeding with WGLC on
>>>>>>>>>>>         OAuth Discovery.
>>>>>>>>>>>             Thanks!
>>>>>>>>>>>             Phil
>>>>>>>>>>>         @independentid
>>>>>>>>>>>         www.independentid.com
>>>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         phil.hunt@oracle.com 
>>>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 Begin forwarded message:
>>>>>>>>>>>         *From:*internet-drafts@ietf.org
>>>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         *Subject: New Version Notification for
>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*
>>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         >, "Anthony Nadalin"
>>>>>>>>>>>                 >>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         >,
>>>>>>>>>>>                 "Tony Nadalin" >>>>>>>>>>         
>>>>>>>>>>>         
>>>>>>>>>>>         >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 A new version of I-D,
>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>                 has been successfully submitted by Phil Hunt
>>>>>>>>>>>         and posted to the
>>>>>>>>>>>                 IETF repository.
>>>>>>>>>>>
>>>>>>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>>>>>>         Revision:00
>>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>>>>>         Document date:2016-03-13
>>>>>>>>>>>         Group:Individual Submission
>>>>>>>>>>>         Pages:22
>>>>>>>>>>>                 URL:
>>>>>>>>>>>         https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>         Status:
>>>>>>>>>>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>>>>>
>>>>>>>>>>>         Htmlized:
>>>>>>>>>>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>         Abstract:
>>>>>>>>>>>                   This specification defines a mechanism for
>>>>>>>>>>>         the client of
>>>>>>>>>>>                 an OAuth 2.0
>>>>>>>>>>>         protected resource service to obtain the configuration
>>>>>>>>>>>         details of an
>>>>>>>>>>>         OAuth 2.0 authorization server that is capable of
>>>>>>>>>>>         authorizing access
>>>>>>>>>>>                   to a specific resource service.  The
>>>>>>>>>>>         information
>>>>>>>>>>>         includes the OAuth
>>>>>>>>>>>                   2.0 component endpoint location URIs and
>>>>>>>>>>>         as well as
>>>>>>>>>>>         authorization
>>>>>>>>>>>         server capabilities.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 Please note that it may take a couple of
>>>>>>>>>>>         minutes from the
>>>>>>>>>>>                 time of submission
>>>>>>>>>>>                 until the htmlized version and diff are
>>>>>>>>>>>         available
>>>>>>>>>>>         attools.ietf.org 
>>>>>>>>>>>          .
>>>>>>>>>>>
>>>>>>>>>>>                 The IETF Secretariat
>>>>>>>>>>>
>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>             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
>>>>>>
>>>>>>
>>>>>>
>>>>>>         _______________________________________________
>>>>>>         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
>>>
>>>
>>
>>
>

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    
    
      
    
      I think Justin provided a good break down of the different aspects
      a client wants to specify about the requested token. (my
      paraphrase)
    
        1. what RS's the token will be used at
    
        2. authorization privilege requests
    
        3. token-timing adjustments
    
      
    
      I'm not sure passing the full endpoint to the AS will help with my
      concerns... The AS could potentially do a webfinger on the
      resource URI and determine if it's an RS that it supports...
      though that requires all RS's to support webfinger. What I really
      want to avoid is the AS having this list of URIs to RS that is
      almost assuredly to get out of sync.
    
      
    
      
    
    
    
    
    On 3/15/16 1:56 PM, John Bradley wrote:
    
    
    
    
    
      
      I think it is a AS policy decision if it should error or take the
      requested resource and issue a token audianced for that resource.
    
    Actually, the error cases
      are interesting. What if the passed in resource/audience doesn't
      actually match a requested scope? Or some match and some don't? Is
      it better to send back a token with less capability? or error the
      entire request?
    
    
      

    
      
    
      
    I guess the question is how to transition from now
        to a future state.   If you cannot upgrade all the clients at
        once.
    
      

    
      
    
      
    A processing rule on the AS that allowed some
        clients to not send the requested resource , but would error out
        for other upgraded clients  with a "resource not allowed†oauth
        error would work and not require the return of the resources.  
    
      

    
      
    
      
    If you return the resources and let the client error
        if it is trying to send to the wrong endpoint that make
        upgrading easier, but gives less control to the AS.
    
      

    
      
    
      
    
        
    
          
    I could live with
              it ether way.
    
          

    
          
    
          The advantage of always sending it in the token request is
          that it allows the AS to do the mapping from a resource URI to
          one or more abstract audience for the token.
    
      
    
    
    
    I thought Justin provided
      a good break down of the different aspects a client wants to
      specify about the requested token. (my paraphrase)
    
        1. what RS's the token will be used at
    
        2. authorization privilege requests
    
        3. token-timing adjustments
    
      
    
      The question is how does a client internally reference a resource
      server? If it's a fixed RS endpoint, then it sort of doesn't
      matter, the client isn't going to send the token to the wrong
      endpoint anyway and it can easily reference the audience by an
      abstract URI.
    
      
    
      If the client can dynamically find new RS's to interact with. How
      does that happen? Does the client get handed an endpoint to use?
      or does it do some sort of discovery to determine the endpoint? I
      suppose both are possible.
    
      
    
      Could we prescribe that the realm value of RFC 6750 error response
      be effectively a resource-service-id (like issuer for the AS). The
      client would then need to do discovery on that value to find the
      valid endpoints of the RS. This could be done once and the
      resource-service-id could be used as the "abstract" RS identifier.
      This requires no more discovery than adding an AS to the client.
    
        
    
    
      
    
        

    
        
    
        
    That might help address George’s concern.
    
      
    
    
    
    I'm not sure passing the
      full endpoint to the AS will help with my concerns... The AS could
      potentially do a webfinger on the resource URI and determine if
      it's an RS that it supports... though that requires all RS's to
      support webfinger. What I really want to avoid is the AS having
      this map of URIs to RS that is almost assuredly to get out of
      sync.
    
    
      
    
        

    
        
    
        
    John B.
    
        

    
        
    
        

    
          
    
            
    On Mar 15, 2016, at 2:44 PM, Brian Campbell
              <bcampbell@pingidentity.com>
              wrote:
    
            
    
            
    
              
    I was thinking it'd be simpler to
                error, if the requested resource(s) weren't okay. That
                puts the burden of checking in the AS. And doesn't add
                anything to the token or authorization response. I see
                the potential similarity to scope but not sure it's
                worth it.    
    
              

    
                
    On Tue, Mar 15, 2016 at 11:37
                  AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    
                  
    
                    
    If the
                      client specifies the resource it wants the token
                      for, then the meta-data would not be required
                      unless the resources the token is good at are
                      different from the request.  
                      
    Lat is the same logic as scopes.
    
                      

    
                      
    
                      
    For backwards compatibility if the
                        client is happy with the default resources based
                        on scopes then I think it is a good idea to tell
                        the client what the resources are in the
                        response.
    
                      

    
                      
    
                      
    I suspect that it is simpler with
                        less optionality and always return the
                        resources, even if they are not required.
    
                      

    
                      
    
                      
    John B.
    
                      
    
                        
    
                          

    
                          
    
                          
    
                            
    
                              
    
                                
    On Mar 15, 2016, at 12:46
                                  PM, Brian Campbell <bcampbell@pingidentity.com>
                                  wrote:
    
                                
    
                                
    
                                  
    If the client
                                    specifies the desired
                                    audience(s)/resource(s), is that
                                    metadata to the client needed? The
                                    AS can audience restrict the token
                                    as needed or respond with an error
                                    if it can't or wont issue a token
                                    for the resource the client asked
                                    for. 
    
                                    
    
                                      
    
                                        

    
                                          
    On
                                            Tue, Mar 15, 2016 at 9:37
                                            AM, John Bradley <ve7jtb@ve7jtb.com>
                                            wrote:
    
                                            
    
                                              
    Yes,  I think
                                                bearer tokens with no
                                                audience are a bad idea.
                                                

    
                                                
    
                                                
    The AS
                                                  needs to infer an
                                                  audience from the
                                                  scopes snd/or have the
                                                  client specify the
                                                  desired audience.
    
                                                

    
                                                
    
                                                
    If the AT
                                                  has a audience or
                                                  audiences then as long
                                                  as the endpoint URI
                                                  are provided as
                                                  meta-data with the
                                                  token, the client can
                                                  determine if it is
                                                  sending the token to
                                                  the correct place.
    
                                                

    
                                                
    
                                                
    I think
                                                  Phil would prefer the
                                                  server rather than the
                                                  client do the check,
                                                  but the client always
                                                  needs to take some
                                                  responsibility to not
                                                  leak tokens giving
                                                  them to the wrong RS
                                                  or the code to the
                                                  wrong token endpoint
                                                  is leaking.
    
                                                

    
                                                
    
                                                
    I imagine
                                                  that claims based
                                                  access tokens are
                                                  going to become more
                                                  popular and the static
                                                  relationship between
                                                  one RS and one AS will
                                                  not be the majority of
                                                  deployments over
                                                  time. 
    
                                                

    
                                                
    
                                                
    In any
                                                  case where the client
                                                  is configured up front
                                                  to know the RS and the
                                                  AS it seems like that
                                                  would not require
                                                  Phil’s Solution, but
                                                  that is the only case
                                                  supported by that
                                                  discovery.
    
                                                
      
    
                                                
    If the
                                                  client itself is bad
                                                  there is not much you
                                                  can do to stop it from
                                                  passing on the AT in
                                                  way way it wants. 
                                                  That however is a
                                                  different problem and
                                                  needs claimed URI or
                                                  attestations to
                                                  prevent client
                                                  spoofing.
    
                                                
    William
                                                  and I are working on
                                                  that in the mobile
                                                  best practices draft.
    
                                                

    
                                                
    
                                                
    John B.
    
                                                

    
                                                
    
                                                

    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:09 PM, George
                                                        Fletcher <gffletch@aol.com>
                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
     I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On
                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously
                                                          
    
                                                          
    
                                                          Hans. 
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: 
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty, 
    
                                                          it’s not even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases —
                                                          it’s 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution 
    
                                                          mechanism in
                                                          that case. 
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we’ve
                                                          really 
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into 
    
                                                          “scope†that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: 
    
                                                          
    
                                                          
    
                                                            - What
                                                          things do I
                                                          want to
                                                          access?
                                                          (photos,
                                                          profile) 
    
                                                            - What
                                                          actions do I
                                                          want to take
                                                          on these
                                                          things? (read,
                                                          write, delete)
                                                          
    
                                                            - How long
                                                          do I want
                                                          these tokens
                                                          to work? 
    
                                                          (offline_access/refresh_token,
                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token 
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. 
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in 
    
                                                          with things
                                                          like
                                                          “offline_accessâ€
                                                          in certain
                                                          APIs. 
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we’re going to
                                                          be adding
                                                          things 
    
                                                          like
                                                          “audience†or
                                                          “resource†or
                                                          both to the
                                                          token
                                                          requests. 
    
                                                          
    
                                                            — Justin 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com
                                                          
    
                                                          <mailto:ve7jtb@ve7jtb.com>>
                                                          wrote: 
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify 
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for.
                                                          
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. 
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are 
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making 
    
                                                          a mess of
                                                          scopes. 
    
                                                          
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com
                                                          
    
                                                          <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                          
    
                                                          Inline 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com
                                                          
    
                                                          <mailto:ve7jtb@ve7jtb.com>>
                                                          wrote: 
    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.  One
                                                          was to provide
                                                          a spec for AS
                                                          metadata. 
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack. 
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don’t 
    
                                                          otherwise need
                                                          discovery. 
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
                                                          
    
                                                          
     
    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint 
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without 
    
                                                          discovery. 
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to 
    
                                                          the wrong
                                                          endpoint? 
    
                                                          
     
    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably
                                                          
    
                                                          doesn’t need
                                                          discovery. 
    
                                                          
    
                                                          We agree 
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find 
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting
                                                          
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating 
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives 
    
                                                          what the
                                                          resource is. 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not 
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service. 
    
                                                          
     
    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have 
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. 
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO.
                                                          
    
                                                          
     
    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but
                                                          
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process. 
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production. 
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. 
    
                                                          
     
    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn’t
                                                          know all the 
    
                                                          possible RS.  
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can 
    
                                                          address. 
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them.
                                                          
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS
                                                          
    
                                                          endpoints
                                                          intentionally.
                                                          
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request 
    
                                                          for each
                                                          endpoint. 
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS 
    
                                                          servers
                                                          assigned to
                                                          each instance?
                                                          
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner 
    
                                                          are.  I think
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. 
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints. 
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a
                                                          
    
                                                          client chooses
                                                          evil.com <http://evil.com/>
                                                          the cert can
                                                          be valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to 
    
                                                          res.example.com
                                                          <http://res.example.com/>?
                                                          
    
                                                          
     
    
                                                          If this is
                                                          added to the
                                                          token endpoint
                                                          it would be
                                                          checked when
                                                          code 
    
                                                          or refresh are
                                                          exchanged, not
                                                          every time the
                                                          token is used.
                                                          
    
                                                          
    
                                                          Your proposal
                                                          requires rhe
                                                          client to
                                                          check. I am
                                                          not clear how
                                                          the AS 
    
                                                          can know the
                                                          exact uri. It
                                                          is far easier
                                                          to validate
                                                          than to lookup
                                                          
    
                                                          since as you
                                                          say the client
                                                          may be
                                                          authorized to
                                                          use multiple
                                                          ASs. 
    
                                                          
    With
                                                          a out of band
                                                          check the
                                                          client would
                                                          never know if
                                                          a RS was 
    
                                                          removed/revoked.

                                                          
    
                                                          
    
                                                          
    
                                                          Not sure that
                                                          is in scope. 
    
                                                          
    
                                                          None of the
                                                          current
                                                          proposals
                                                          address this
                                                          issue. 
    
                                                          
     
    
                                                          I don’t see
                                                          checking when
                                                          refreshing a
                                                          token as
                                                          something that
                                                          is a 
    
                                                          huge burden. 
    
                                                          
    
                                                          
    
                                                          Still its a
                                                          lot more than
                                                          once. 
    
                                                          
    
                                                          Why don't you
                                                          draft another
                                                          alternative? 
    
                                                          
     
    
                                                          If the server
                                                          wants to do
                                                          the check on
                                                          it’s side then
                                                          we could 
    
                                                          require the
                                                          client to send
                                                          the RS URI in
                                                          the token
                                                          request. that
                                                          way 
    
                                                          you really
                                                          know the
                                                          client is not
                                                          going to get a
                                                          token for the
                                                          wrong 
    
                                                          RS endpoint. 
    
                                                          If you check
                                                          out of band in
                                                          discovery you
                                                          really have no
                                                          idea if the 
    
                                                          client is
                                                          checking. 
    
                                                          
    
                                                          
    
                                                          In the new
                                                          webfinger
                                                          draft, the
                                                          client isn't
                                                          checking. The
                                                          service 
    
                                                          provider
                                                          simply does
                                                          not disclose
                                                          oauth
                                                          information to
                                                          misconfigured
                                                          
    
                                                          clients. 
    
                                                          
     
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 3:56 PM,
                                                          Phil Hunt <phil.hunt@oracle.com
                                                          
    
                                                          <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                          
    
                                                          Thanks to Mike
                                                          and John for
                                                          their
                                                          feedback. 
                                                          I’ll take each
                                                          in turn: 
    
                                                          
    
                                                          Mike, 
    
                                                          
    
                                                          Regarding your
                                                          suggested
                                                          amendments 
    
                                                          
    
                                                          Item 1:
                                                          Returning the
                                                          config URL
                                                          would create
                                                          two problems.
                                                          One,it 
    
                                                          makes bound
                                                          discovery a
                                                          two-step
                                                          process - that
                                                          adds
                                                          complexity. 
    
                                                           It seems far
                                                          simpler to
                                                          mandate TLS
                                                          (which I think
                                                          it already
                                                          does 
    
                                                          in the
                                                          security
                                                          considerations).
                                                          
    
                                                          
    
                                                          The two-step
                                                          process allows
                                                          the current
                                                          discovery
                                                          process to 
    
                                                          continue. I
                                                          disagree with
                                                          this. This is
                                                          why I put
                                                          forward an 
    
                                                          “alternate"
                                                          draft that is
                                                          almost the
                                                          same but
                                                          simply adds
                                                          the check 
    
                                                          before
                                                          returning the
                                                          configuration
                                                          data.  I worry
                                                          that 
                                                          developers 
    
                                                          would have no
                                                          incentive to
                                                          do the
                                                          two-step
                                                          approach. They
                                                          would 
    
                                                          just start at
                                                          step 2 which
                                                          in turn puts
                                                          AS’s at risk
                                                          of exposing 
    
                                                          tokens because
                                                          it works. This
                                                          makes OAuth
                                                          promiscuous. 
    
                                                          
    
                                                          Regarding
                                                          existing
                                                          implementations.
                                                          Most of those
                                                          implementations

                                                          
    
                                                          are for OIDC. 
                                                          I think it
                                                          makes sense
                                                          for OIDF to
                                                          continue use
                                                          of 
    
                                                          OIDC's
                                                          discovery spec
                                                          because the
                                                          UserInfo
                                                          endpoint is
                                                          well defined 
    
                                                          and the
                                                          likelihood of
                                                          a client
                                                          mis-informed
                                                          about the
                                                          resource 
    
                                                          endpoint is
                                                          not there. 
                                                          IMO This does
                                                          not apply to
                                                          the broader 
    
                                                          OAuth
                                                          community. 
    
                                                          
    
                                                          Item 2:  It
                                                          may be
                                                          appropriate to
                                                          have a
                                                          separate
                                                          configuration
                                                          
    
                                                          registry
                                                          specification,
                                                          but I think we
                                                          should hold
                                                          off until we 
    
                                                          have a
                                                          complete
                                                          solution and
                                                          then make the
                                                          decision what
                                                          drafts 
    
                                                          should exist
                                                          and how many
                                                          pieces.  A big
                                                          concern is the
                                                          perceived 
    
                                                          complexity of
                                                          multiple
                                                          solutions and
                                                          multiple
                                                          drafts. 
    
                                                          
    
                                                          As to John
                                                          Bradley’s
                                                          comments: 
    
                                                          
    
                                                          Re: Discovery
                                                          is the wrong
                                                          place to
                                                          mitigate
                                                          threats. 
    
                                                          I’m confused
                                                          by this.  Our
                                                          mandate was to
                                                          solve a
                                                          security
                                                          threat 
    
                                                          by having a
                                                          discovery
                                                          specification
                                                          to prevent
                                                          clients being
                                                          
    
                                                          mis-lead about
                                                          endpoints (of
                                                          which resource
                                                          service is
                                                          one) in an 
    
                                                          oauth
                                                          protected
                                                          exchange. 
                                                          Maybe what you
                                                          mean is we
                                                          should not use
                                                          
    
                                                          .well-known of
                                                          any kind and
                                                          we should just
                                                          create a
                                                          “/Config†
    
                                                          endpoint to
                                                          OAuth? 
    
                                                          
    
                                                          Re: Your
                                                          proposal for
                                                          MITM
                                                          mitigation 
    
                                                          You propose
                                                          that instead
                                                          the resource
                                                          endpoint check
                                                          should be in 
    
                                                          the oauth
                                                          protocol
                                                          itself.  The
                                                          difference is
                                                          that
                                                          validation is
                                                          
    
                                                          transferred
                                                          back to the
                                                          client to get
                                                          it right. As
                                                          well, without
                                                          
    
                                                          the client
                                                          informing the
                                                          AS, I can’t
                                                          see a way for
                                                          the AS to know
                                                          
    
                                                          what endpoint
                                                          the client is
                                                          using.  The
                                                          webfinger
                                                          approach does
                                                          
    
                                                          this once and
                                                          only requires
                                                          that the host
                                                          name be
                                                          checked in
                                                          many 
    
                                                          cases. 
    
                                                          
    
                                                          As a
                                                          principle, the
                                                          members have
                                                          discussed many
                                                          times that the
                                                          AS 
    
                                                          service should
                                                          do validation
                                                          when possible
                                                          — this was
                                                          particularly 
    
                                                          true at the
                                                          Germany
                                                          meeting when
                                                          this came up.
                                                          This is why I
                                                          prefer 
    
                                                          the client
                                                          tell the
                                                          service
                                                          provider what
                                                          it intends to
                                                          do and the 
    
                                                          service
                                                          provider can
                                                          fail that
                                                          request
                                                          immediately if
                                                          necessary. We
                                                          
    
                                                          don’t have to
                                                          depend on the
                                                          developer
                                                          getting the
                                                          spec correct
                                                          to 
    
                                                          fail the
                                                          correct way. 
    
                                                          
    
                                                          I worry that
                                                          adding more
                                                          parameters to
                                                          the authz and
                                                          token protocol
                                                          
    
                                                          flows
                                                          increases
                                                          complexity and
                                                          attack
                                                          surface. It
                                                          also means per
                                                          
    
                                                          authorization
                                                          validation has
                                                          to take place
                                                          vs. a one-time
                                                          
    
                                                          validation at
                                                          config time. 
                                                          Placing it in
                                                          the
                                                          configuration
                                                          lookup 
    
                                                          phase (whether
                                                          via web finger
                                                          or just a
                                                          special OAuth
                                                          endpoint) 
    
                                                          seems more
                                                          appropriate
                                                          and far less
                                                          complex - as
                                                          the request
                                                          itself 
    
                                                          is simple and
                                                          has only one
                                                          parameter.
                                                          Here we are
                                                          not considered
                                                          
    
                                                          about
                                                          legitimacy of
                                                          the client.
                                                          we’re just
                                                          concerned with
                                                          the issue 
    
                                                          "has the
                                                          client been
                                                          correctly
                                                          informed?†
    
                                                          
    
                                                          That said, it
                                                          may be that
                                                          when we
                                                          consider all
                                                          the use cases,
                                                          some 
    
                                                          combination of
                                                          AS protocol
                                                          and discovery
                                                          may be both
                                                          needed. I’m 
    
                                                          not ready to
                                                          make
                                                          conclusions
                                                          about this. 
                                                          The current 
    
                                                          oauth-discovery
                                                          spec seems to
                                                          put future
                                                          generic
                                                          clients at
                                                          risk 
    
                                                          and that is my
                                                          primary
                                                          concern. 
    
                                                          
    
                                                          Best Regards,
                                                          
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          @independentid
                                                          
    
                                                          www.independentid.com
                                                          <http://www.independentid.com/>
                                                          
    
                                                          phil.hunt@oracle.com
                                                          <mailto:phil.hunt@oracle.com>
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 13, 2016,
                                                          at 10:28 PM,
                                                          Mike Jones 
    
                                                          <Michael.Jones@microsoft.com
                                                          <mailto:Michael.Jones@microsoft.com>>

                                                          
    
                                                          wrote: 
    
                                                          
    
                                                          Thanks for
                                                          posting this,
                                                          Phil.  It
                                                          provides a
                                                          concrete
                                                          example of 
    
                                                          a way that
                                                          protected
                                                          resource
                                                          discovery
                                                          could be added
                                                          to 
    
                                                          authorization
                                                          server
                                                          metadata
                                                          discovery, and
                                                          as such,
                                                          should 
    
                                                          provide useful
                                                          input for
                                                          working group
                                                          discussions on
                                                          this topic. 
    
                                                          It’s always
                                                          great when
                                                          someone takes
                                                          the time to
                                                          write an
                                                          actual 
    
                                                          draft that can
                                                          be examined
                                                          and
                                                          implemented,
                                                          and I
                                                          appreciate you
                                                          
    
                                                          doing that. 
    
                                                          The content of
                                                          your draft
                                                          points out
                                                          that there
                                                          appears to be
                                                          
    
                                                          complete
                                                          agreement on
                                                          what the
                                                          authorization
                                                          server
                                                          metadata 
    
                                                          format should
                                                          be, which is
                                                          great!  I’ll
                                                          note that
                                                          Section 3 of 
    
                                                          draft-hunt-oauth-bound-config-00
                                                          titled
                                                          “Authorization
                                                          Server 
    
                                                          Metadata†is
                                                          an exact copy
                                                          of Section 2
                                                          of 
    
                                                          draft-ietf-oauth-discovery-01
                                                          (with the same
                                                          title), modulo
                                                          
    
                                                          applying a
                                                          correction
                                                          suggested by
                                                          the working
                                                          group.  To me
                                                          this 
    
                                                          suggests that
                                                          the
                                                          authorization
                                                          server
                                                          metadata
                                                          definitions in
                                                          
    
                                                          draft-ietf-oauth-discovery
                                                          (which is now
                                                          the whole
                                                          normative 
    
                                                          content of the
                                                          draft) are
                                                          clearly ready
                                                          for
                                                          standardization,
                                                          since 
    
                                                          even your
                                                          alternative
                                                          proposal
                                                          includes them
                                                          verbatim. 
    
                                                          Reading your
                                                          draft, the
                                                          problem I have
                                                          with it is
                                                          that you are 
    
                                                          returning the
                                                          AS metadata
                                                          only as a
                                                          WebFinger
                                                          response,
                                                          rather 
    
                                                          than as an
                                                          https-protected
                                                          resource
                                                          published by
                                                          the
                                                          authorization
                                                          
    
                                                          server.  The
                                                          choice to only
                                                          return this
                                                          via WebFinger
                                                          makes your 
    
                                                          draft
                                                          incompatible
                                                          with most
                                                          deployed
                                                          implementations
                                                          of OAuth 
    
                                                          metadata,
                                                          including the
                                                          22
                                                          implementations
                                                          using it
                                                          listed 
    
                                                          athttp://openid.net/certification/(see
                                                          the “OP
                                                          Config†column
                                                          in 
    
                                                          the table)
                                                          andOAuth 2.0
                                                          libraries such
                                                          as Microsoft’s
                                                          “ADAL†
    
                                                          library, which
                                                          uses the
                                                          metadata path
                                                          for client
                                                          configuration.
                                                          
    
                                                          Without having
                                                          ASs provide
                                                          the metadata
                                                          as an
                                                          https-protected
                                                          
    
                                                          resource,
                                                          implementations
                                                          such as ADAL
                                                          can’t use it
                                                          for client 
    
                                                          configuration
                                                          as the
                                                          currently do.
                                                          
    
                                                          Therefore, I
                                                          would request
                                                          that you make
                                                          these minor
                                                          revisions to 
    
                                                          your draft and
                                                          republish, so
                                                          as to provide
                                                          a unified way
                                                          forward 
    
                                                          that is
                                                          compatible
                                                          with all known
                                                          existing OAuth
                                                          Discovery 
    
                                                          deployments: 
    
                                                          1.Modify your
                                                          section 2
                                                          “Authorization
                                                          Server
                                                          WebFinger
                                                          Discovery†
    
                                                          to have the
                                                          WebFinger
                                                          request return
                                                          the issuer
                                                          identifier for
                                                          the 
    
                                                          AS as the
                                                          “WebFinger
                                                          “rel†value,
                                                          rather than
                                                          returning the
                                                          
    
                                                          metadata
                                                          values by
                                                          value as the
                                                          “propertiesâ€
                                                          value. 
    
                                                          2.Reference
                                                          the metadata
                                                          definitions
                                                          from Section 2
                                                          of 
    
                                                          draft-ietf-oauth-discovery,
                                                          rather than
                                                          duplicating
                                                          them in your 
    
                                                          Section 3. 
    
                                                          That would
                                                          have the
                                                          advantage of
                                                          paring your
                                                          draft down to
                                                          only 
    
                                                          the new things
                                                          that it
                                                          proposes,
                                                          enabling them
                                                          to be more
                                                          clearly 
    
                                                          understood and
                                                          evaluated on
                                                          their own
                                                          merits.  I
                                                          look forward
                                                          to 
    
                                                          the
                                                          discussions of
                                                          ways of
                                                          performing
                                                          additional
                                                          kinds of OAuth
                                                          
    
                                                          discovery, and
                                                          consider your
                                                          draft a
                                                          valuable input
                                                          to those 
    
                                                          discussions. 
    
                                                                                                                   

                                                          Best wishes, 
    
                                                                                                                   

                                                          -- Mike 
    
                                                          *From:*OAuth [mailto:oauth-bounces@ietf.org]*On
                                                          Behalf Of*John
                                                          Bradley 
    
                                                          *Sent:*Sunday,
                                                          March 13, 2016
                                                          6:45 PM 
    
                                                          *To:*Phil Hunt
                                                          <phil.hunt@oracle.com
                                                          <mailto:phil.hunt@oracle.com>>

                                                          
    
                                                          *Cc:*oauth
                                                          <oauth@ietf.org
                                                          <mailto:oauth@ietf.org>>

                                                          
    
                                                          *Subject:*Re:
                                                          [OAUTH-WG] New
                                                          Version
                                                          Notification
                                                          for 
    
                                                          draft-hunt-oauth-bound-config-00.txt

                                                          
    
                                                          As I have told
                                                          Phil off list.
                                                          
    
                                                          Discovery is
                                                          the wrong
                                                          place to try
                                                          and provide
                                                          security
                                                          against 
    
                                                          man in the
                                                          middle attacks
                                                          on the RS. 
    
                                                          This requires
                                                          the client to
                                                          know what the
                                                          RS URI is
                                                          before 
    
                                                          retrieving the
                                                          information on
                                                          the AS
                                                          Configuration.
                                                          
    
                                                          The proposal
                                                          Mike and I
                                                          have been
                                                          working on
                                                          requires the
                                                          client 
    
                                                          to have a
                                                          notion of what
                                                          API it is
                                                          looking for
                                                          and retrieve
                                                          the 
    
                                                          .well-known
                                                          file for that
                                                          API from the
                                                          issuer.   That
                                                          allows a 
    
                                                          protocol like
                                                          Connect to
                                                          register its
                                                          own config
                                                          file that can
                                                          
    
                                                          point to the
                                                          RS. 
    
                                                          If the API
                                                          specific well
                                                          known is not
                                                          available the
                                                          client can try
                                                          
    
                                                          the default
                                                          oauth-server
                                                          one. 
    
                                                          That then
                                                          allows us to
                                                          deal with
                                                          restricting
                                                          where AT are 
    
                                                          presented as
                                                          part of the
                                                          protocol
                                                          rather then
                                                          dragging
                                                          discovery 
    
                                                          in as a
                                                          requirement. 
    
                                                          In my opinion
                                                          the resource
                                                          the token is
                                                          targeted to
                                                          should be 
    
                                                          separated from
                                                          the scope and
                                                          returned as
                                                          part of the
                                                          meta-data 
    
                                                          about the AT
                                                          along with
                                                          scopes granted
                                                          and expiry
                                                          time.   We 
    
                                                          should also
                                                          have a input
                                                          parameter for
                                                          resources so
                                                          that a client
                                                          
    
                                                          can restrict
                                                          tokens issued
                                                          to a subset of
                                                          the ones
                                                          granted by the
                                                          
    
                                                          refresh
                                                          token.   It
                                                          would then
                                                          also be
                                                          possible to
                                                          ask a AS for a
                                                          
    
                                                          token for a
                                                          unregistered
                                                          RS and have
                                                          the AS produce
                                                          a JWT access 
    
                                                          token with the
                                                          resource as an
                                                          audience if
                                                          policy allows.
                                                          
    
                                                          That however
                                                          was supposed
                                                          to be dealt
                                                          with as part
                                                          of the mixed
                                                          up 
    
                                                          client set of
                                                          mitigations. 
    
                                                          In that the
                                                          goal was to
                                                          mitigate the
                                                          attacks by
                                                          returning 
    
                                                          meta-data
                                                          about the
                                                          tokens, and
                                                          not to require
                                                          discovery. 
    
                                                          We intend to
                                                          return “issâ€
                                                          and
                                                          “cleint_idâ€
                                                          for the code,
                                                          and I 
    
                                                          intend to
                                                          discuss at the
                                                          F2F returning
                                                          resource for
                                                          AT as well. 
    
                                                          Those mitigate
                                                          the attack. 
    
                                                          I will
                                                          continue to
                                                          resist mixing
                                                          up discovery
                                                          of
                                                          configuration
                                                          
    
                                                          meta-data with
                                                          mitigation of
                                                          the attacks. 
    
                                                          We return
                                                          meta-data
                                                          about the
                                                          tokens now,
                                                          because AT are
                                                          opaque to 
    
                                                          the client, we
                                                          neglected to
                                                          include some
                                                          of the
                                                          information
                                                          for 
    
                                                          the client
                                                          needs to be
                                                          secure.   We
                                                          just need to
                                                          add that in to
                                                          
    
                                                          the existing
                                                          flows. 
    
                                                          While Phil’s
                                                          proposal is
                                                          easier for the
                                                          AS to
                                                          implement as
                                                          an add 
    
                                                          on, it puts
                                                          more of a
                                                          burden on the
                                                          client needing
                                                          to potentially
                                                          
    
                                                          change how it
                                                          stores the
                                                          relationships
                                                          between AS and
                                                          RS to 
    
                                                          prevent
                                                          compromise, I
                                                          think the
                                                          solution
                                                          should be
                                                          biased towards
                                                          
    
                                                          simplicity on
                                                          the client
                                                          side. 
    
                                                          If we return
                                                          the resources
                                                          as part of the
                                                          existing meta
                                                          data the 
    
                                                          client checks
                                                          that against
                                                          the resource
                                                          it intends to
                                                          send the 
    
                                                          token to and
                                                          if it is not
                                                          in the list
                                                          then it can’t
                                                          send the 
    
                                                          token.  Simple
                                                          check every
                                                          time it gets a
                                                          new AT, no
                                                          optionality. 
    
                                                          I am not
                                                          saying
                                                          anything new
                                                          Nat has been
                                                          advocating
                                                          basically 
    
                                                          this for some
                                                          time, and dis
                                                          submit a
                                                          draft.   I
                                                          prefer to
                                                          return 
    
                                                          the info in
                                                          the existing
                                                          format rather
                                                          than as link
                                                          headers,  but
                                                          
    
                                                          that is the
                                                          largest
                                                          difference
                                                          between what
                                                          Nat and I are
                                                          saying 
    
                                                          with respect
                                                          to resource. 
    
                                                          That is the
                                                          core of my
                                                          problem with
                                                          Phil’s draft.
                                                          
    
                                                          I guess we
                                                          will need to
                                                          have a long
                                                          conversation
                                                          in BA. 
    
                                                          Regards 
    
                                                          John B. 
    
                                                          
    
                                                              On Mar 13,
                                                          2016, at 8:12
                                                          PM, Phil Hunt
                                                          <phil.hunt@oracle.com
                                                          
    
                                                              <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                              This draft
                                                          is a proposed
                                                          alternate
                                                          proposal for 
    
                                                             
                                                          draft-ietf-oauth-discovery. 
                                                          As such, it
                                                          contains the
                                                          same 
    
                                                              registry
                                                          for OAuth
                                                          Config
                                                          Metadata as
                                                          the authors
                                                          believe that 
    
                                                              both
                                                          solutions are
                                                          not required,
                                                          or depending
                                                          on WG
                                                          discussion 
    
                                                              they will
                                                          be merged. The
                                                          intent is to
                                                          provide a
                                                          simple 
    
                                                              complete
                                                          draft for
                                                          consideration.
                                                          
    
                                                              How it
                                                          works... 
    
                                                              Given that
                                                          a client has
                                                          previously
                                                          discovered an
                                                          OAuth 
    
                                                              protected
                                                          resource, the
                                                          bound
                                                          configuration
                                                          method allows
                                                          a 
    
                                                              client to
                                                          return the
                                                          configuration
                                                          for an oauth
                                                          authorization
                                                          
    
                                                              server
                                                          that can issue
                                                          tokens for the
                                                          resource URI
                                                          specified by 
    
                                                              the
                                                          client.  The
                                                          AS is not
                                                          required to be
                                                          in the same
                                                          domain. 
    
                                                               The AS is
                                                          however
                                                          required to
                                                          know if it can
                                                          issue tokens
                                                          for 
    
                                                              a resource
                                                          service (which
                                                          presumes some
                                                          agreement
                                                          exists on 
    
                                                              tokens
                                                          etc). 
    
                                                              The draft
                                                          does not
                                                          require that
                                                          the resource
                                                          exist (e.g.
                                                          for 
    
                                                             
                                                          unconfigured
                                                          or new user
                                                          based
                                                          resources). It
                                                          only requires
                                                          
    
                                                              that the
                                                          AS service
                                                          provider
                                                          agrees it can
                                                          issue tokens.
                                                          
    
                                                              From a
                                                          security
                                                          perspective,
                                                          returning the
                                                          OAuth service
                                                          
    
                                                             
                                                          configuration
                                                          for a
                                                          specified
                                                          resource URI
                                                          serves to
                                                          confirm 
    
                                                              the client
                                                          is in
                                                          possession of
                                                          a valid
                                                          resource URI
                                                          ensuring 
    
                                                              the client
                                                          has received a
                                                          valid set of
                                                          endpoints for
                                                          the 
    
                                                              resource
                                                          and the
                                                          associated
                                                          oauth
                                                          services. 
    
                                                              I propose
                                                          that the WG
                                                          consider the
                                                          alternate
                                                          draft
                                                          carefully 
    
                                                              as well as
                                                          other
                                                          submissions
                                                          and evaluate
                                                          the broader 
    
                                                              discovery
                                                          problem before
                                                          proceeding
                                                          with WGLC on
                                                          OAuth
                                                          Discovery. 
    
                                                              Thanks! 
    
                                                              Phil 
    
                                                             
                                                          @independentid
                                                          
    
                                                              www.independentid.com
                                                          <http://www.independentid.com/>
                                                          
    
                                                              phil.hunt@oracle.com
                                                          <mailto:phil.hunt@oracle.com>
                                                          
    
                                                          
    
                                                          
    
                                                                  Begin
                                                          forwarded
                                                          message: 
    
                                                                 
                                                          *From:*internet-drafts@ietf.org
                                                          
    
                                                                  <mailto:internet-drafts@ietf.org>
                                                          
    
                                                                 
                                                          *Subject: New
                                                          Version
                                                          Notification
                                                          for 
    
                                                                 
                                                          draft-hunt-oauth-bound-config-00.txt*
                                                          
    
                                                                 
                                                          *Date:*March
                                                          13, 2016 at
                                                          3:53:37 PM PDT
                                                          
    
                                                                 
                                                          *To:*"Phil
                                                          Hunt" <phil.hunt@yahoo.com
                                                          
    
                                                                  <mailto:phil.hunt@yahoo.com>>,

                                                          "Anthony
                                                          Nadalin" 
    
                                                                  <tonynad@microsoft.com
                                                          <mailto:tonynad@microsoft.com>>,

                                                          
    
                                                                  "Tony
                                                          Nadalin" <tonynad@microsoft.com
                                                          
    
                                                                  <mailto:tonynad@microsoft.com>>

                                                          
    
                                                          
    
                                                          
    
                                                                  A new
                                                          version of
                                                          I-D,
                                                          draft-hunt-oauth-bound-config-00.txt
                                                          
    
                                                                  has
                                                          been
                                                          successfully
                                                          submitted by
                                                          Phil Hunt and
                                                          posted to the
                                                          
    
                                                                  IETF
                                                          repository. 
    
                                                          
    
                                                                 
                                                          Name:draft-hunt-oauth-bound-config
                                                          
    
                                                                 
                                                          Revision:00 
    
                                                                 
                                                          Title:OAuth
                                                          2.0 Bound
                                                          Configuration
                                                          Lookup 
    
                                                                 
                                                          Document
                                                          date:2016-03-13
                                                          
    
                                                                 
                                                          Group:Individual
                                                          Submission 
    
                                                                 
                                                          Pages:22 
    
                                                                  URL: 
    
                                                                 
                                                          https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                                                                 
                                                          Status: 
    
                                                                  https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
                                                          
    
                                                                 
                                                          Htmlized: 
    
                                                                  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
                                                          
    
                                                          
    
                                                          
    
                                                                 
                                                          Abstract: 
    
                                                                    This
                                                          specification
                                                          defines a
                                                          mechanism for
                                                          the client of
                                                          
    
                                                                  an
                                                          OAuth 2.0 
    
                                                                   
                                                          protected
                                                          resource
                                                          service to
                                                          obtain the
                                                          configuration
                                                          
    
                                                                 
                                                          details of an
                                                          
    
                                                                   
                                                          OAuth 2.0
                                                          authorization
                                                          server that is
                                                          capable of 
    
                                                                 
                                                          authorizing
                                                          access 
    
                                                                    to a
                                                          specific
                                                          resource
                                                          service.  The
                                                          information 
    
                                                                 
                                                          includes the
                                                          OAuth 
    
                                                                    2.0
                                                          component
                                                          endpoint
                                                          location URIs
                                                          and as well as
                                                          
    
                                                                 
                                                          authorization
                                                          
    
                                                                   
                                                          server
                                                          capabilities.
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                                  Please
                                                          note that it
                                                          may take a
                                                          couple of
                                                          minutes from
                                                          the 
    
                                                                  time
                                                          of submission
                                                          
    
                                                                  until
                                                          the htmlized
                                                          version and
                                                          diff are
                                                          available 
    
                                                                  attools.ietf.org
                                                          <http://tools.ietf.org/>.
                                                          
    
                                                          
    
                                                                  The
                                                          IETF
                                                          Secretariat 
    
                                                          
    
                                                             
                                                          _______________________________________________
                                                          
    
                                                              OAuth
                                                          mailing list 
    
                                                              OAuth@ietf.org
                                                          <mailto:OAuth@ietf.org>
                                                          
    
                                                              https://www.ietf.org/mailman/listinfo/oauth
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          _______________________________________________

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

                                                          
    
                                                          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
    
                                              
    
                                            
    
                                          
    
                                          
    
                                        
    
                                      
    
                                    
    
                                  
    
                                
    
                              
    
                            
    
                            
    
                          
    
                        
    
                      
    
                    
    
                  
    
                
    
                
    
              
    
            
    
          
    
        
    
        
    
      
    
    
    
    
    
    
    -- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

    
  


--------------070407080608070106030609--


From nobody Tue Mar 15 12:26:32 2016
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 642A312DC6A for ; Tue, 15 Mar 2016 12:26:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 tBHd1hURe9dn for ; Tue, 15 Mar 2016 12:26:25 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 6277112DC52 for ; Tue, 15 Mar 2016 12:26:25 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id o6so11537736qkc.2 for ; Tue, 15 Mar 2016 12:26:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=JVuirKqDUsBTCrh8CAuE3MGeodGPLxgZB8alRxutpEA=; b=ZIAm3V8WYgnTxc1UuYHKmFB1ePMsMJI0/RAaS8xEaV8HlfhazAncFIabl6w9lI+gAL +azUU5iwrVKQlbWjoMXSRnRPBJse47wsd10YF/tEeppRCe/3XKXKgrjXJsaYC2GRdJoE cY9uQkffv8mQqMH9rmu1F5FldSaKSqX+i2I3AN6I8SjqZSc8pmO5eATh3ms5zQiQ/NYf 3LNcm34R2NLm3VrWVy06BNUi/Y98DcN6a2dwO3zyRFZOGd96NeBB3mC073rEAY8gBM1g tb/73YaeW8tl90iT+GR5o4+bJqqsGh4vFvO37Vdqf33V0ZO7EbUa1sW5PYhN1BhBJdsz /BrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JVuirKqDUsBTCrh8CAuE3MGeodGPLxgZB8alRxutpEA=; b=EfsTTp8EiWGvfs/k4jF2ED+/aivMitozu9+r7GDtGNUdvKGyxqlica8mKI1UMuNT8N XMdHTR7aQFJ3bIJ9N4hq8NLbmM0NyggNzu0bysjfx78Mm1O23MhrjHDX2N9B4oLXB7jb QYggwzIF7vk1OmCTDmGRHe62to/DSq7xGUu8mXhLQHKXxKFGuGDPWWGQcokag6RQ1s98 SpTBxqyESDIhJVEoEStj/qJd6jp7VaTRSI8rWvCFxbN6PHVGVT8Q1SqCnL8+jq8Z0/Ex koBalMHVSccwppT0RrCKRZ1E83nknbrhV4yrFIjEzv1/iqHoBpzDHRUKJxo21mhAap8j N54A==
X-Gm-Message-State: AD7BkJJMW5w+oz8xrwe9Ki3RZdyUyiFIuspSF1gi/ohohb7e8YYDPrbLKy/otcenq8r0fQ==
X-Received: by 10.55.76.84 with SMTP id z81mr40106198qka.17.1458069984071; Tue, 15 Mar 2016 12:26:24 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.31.112]) by smtp.gmail.com with ESMTPSA id f128sm13270174qhf.30.2016.03.15.12.26.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 12:26:22 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_134DDDDB-C4F0-4AD0-AD1C-16327E0DD7E7"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56E85111.9030308@aol.com>
Date: Tue, 15 Mar 2016 16:26:18 -0300
Message-Id: <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 19:26:30 -0000

--Apple-Mail=_134DDDDB-C4F0-4AD0-AD1C-16327E0DD7E7
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C08FE2D0-A615-4290-805D-0C31331E3A77"


--Apple-Mail=_C08FE2D0-A615-4290-805D-0C31331E3A77
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think Phil and others are concerned that a developer might get bad =
info to put in the client , some out of band discovery goes wrong or the =
user is somehow tricked into specifying a bad resource to the client.

So getting a bad resource is a touch hypothetical.=20

For Connect we could suppose that someone publishes a malicious =
discovery document listing themselves as the RS but all the other =
endpoints are at the good AS so the client registers, authorizes the =
user and gives the AT to the bad guy.  The confused client mitigation by =
returning client_id_and issuer from the authorization endpoint will stop =
the attack before the token can be given to the token endpoint or RS.

So protecting the AT at this point is more for a unknown attack that =
would confuse whatever protocol/API that is using OAuth about what RS to =
use.

In reality this is what PoP is supposed to be for.

I guess the question is what short of PoP can we do to prevent the =
client leaking tokens to bad RS that confuse it via the application =
protocol.

If we want to del with this in OAuth then we need to tell the AS where =
the token is going to be used or tel the client where the token can be =
used.=20

I think letting the client tell the AS where it wants the token used =
having the AS construct a audience out of that is probably the best =
thing.  to get around having a pre-established relationship between the =
AS and RS.

John B.

> On Mar 15, 2016, at 3:14 PM, George Fletcher  wrote:
>=20
>=20
>=20
> I think Justin provided a good break down of the different aspects a =
client wants to specify about the requested token. (my paraphrase)
>   1. what RS's the token will be used at
>   2. authorization privilege requests
>   3. token-timing adjustments
>=20
> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.
>=20
>=20
>=20
> On 3/15/16 1:56 PM, John Bradley wrote:
>> I think it is a AS policy decision if it should error or take the =
requested resource and issue a token audianced for that resource.
> Actually, the error cases are interesting. What if the passed in =
resource/audience doesn't actually match a requested scope? Or some =
match and some don't? Is it better to send back a token with less =
capability? or error the entire request?
>>=20
>>=20
>> I guess the question is how to transition from now to a future state. =
  If you cannot upgrade all the clients at once.
>>=20
>> A processing rule on the AS that allowed some clients to not send the =
requested resource , but would error out for other upgraded clients  =
with a "resource not allowed=E2=80=9D oauth error would work and not =
require the return of the resources. =20
>>=20
>> If you return the resources and let the client error if it is trying =
to send to the wrong endpoint that make upgrading easier, but gives less =
control to the AS.
>>=20
>> I could live with it ether way.
>>=20
>> The advantage of always sending it in the token request is that it =
allows the AS to do the mapping from a resource URI to one or more =
abstract audience for the token.
> I thought Justin provided a good break down of the different aspects a =
client wants to specify about the requested token. (my paraphrase)
>   1. what RS's the token will be used at
>   2. authorization privilege requests
>   3. token-timing adjustments
>=20
> The question is how does a client internally reference a resource =
server? If it's a fixed RS endpoint, then it sort of doesn't matter, the =
client isn't going to send the token to the wrong endpoint anyway and it =
can easily reference the audience by an abstract URI.
>=20
> If the client can dynamically find new RS's to interact with. How does =
that happen? Does the client get handed an endpoint to use? or does it =
do some sort of discovery to determine the endpoint? I suppose both are =
possible.
>=20
> Could we prescribe that the realm value of RFC 6750 error response be =
effectively a resource-service-id (like issuer for the AS). The client =
would then need to do discovery on that value to find the valid =
endpoints of the RS. This could be done once and the resource-service-id =
could be used as the "abstract" RS identifier. This requires no more =
discovery than adding an AS to the client.
>>=20
>> That might help address George=E2=80=99s concern.
> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this map of URIs to RS that is almost assuredly to get out of sync.
>>=20
>>=20
>> John B.
>>=20
>>=20
>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell =
> wrote:
>>>=20
>>> I was thinking it'd be simpler to error, if the requested =
resource(s) weren't okay. That puts the burden of checking in the AS. =
And doesn't add anything to the token or authorization response. I see =
the potential similarity to scope but not sure it's worth it.   =20
>>>=20
>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>> If the client specifies the resource it wants the token for, then =
the meta-data would not be required unless the resources the token is =
good at are different from the request. =20
>>> Lat is the same logic as scopes.
>>>=20
>>> For backwards compatibility if the client is happy with the default =
resources based on scopes then I think it is a good idea to tell the =
client what the resources are in the response.
>>>=20
>>> I suspect that it is simpler with less optionality and always return =
the resources, even if they are not required.
>>>=20
>>> John B.
>>>=20
>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell < =
bcampbell@pingidentity.com =
> wrote:
>>>>=20
>>>> If the client specifies the desired audience(s)/resource(s), is =
that metadata to the client needed? The AS can audience restrict the =
token as needed or respond with an error if it can't or wont issue a =
token for the resource the client asked for.=20
>>>>=20
>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>=20
>>>> The AS needs to infer an audience from the scopes snd/or have the =
client specify the desired audience.
>>>>=20
>>>> If the AT has a audience or audiences then as long as the endpoint =
URI are provided as meta-data with the token, the client can determine =
if it is sending the token to the correct place.
>>>>=20
>>>> I think Phil would prefer the server rather than the client do the =
check, but the client always needs to take some responsibility to not =
leak tokens giving them to the wrong RS or the code to the wrong token =
endpoint is leaking.
>>>>=20
>>>> I imagine that claims based access tokens are going to become more =
popular and the static relationship between one RS and one AS will not =
be the majority of deployments over time.=20
>>>>=20
>>>> In any case where the client is configured up front to know the RS =
and the AS it seems like that would not require Phil=E2=80=99s Solution, =
but that is the only case supported by that discovery.
>>>>  =20
>>>> If the client itself is bad there is not much you can do to stop it =
from passing on the AT in way way it wants.  That however is a different =
problem and needs claimed URI or attestations to prevent client =
spoofing.
>>>> William and I are working on that in the mobile best practices =
draft.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>=20
>>>>> I worry about two directions I see in this thread...
>>>>>=20
>>>>> 1. Client's accessing resources dynamically so that discovery is =
required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>>>>>=20
>>>>> 2. Creating a tight coupling between RS and AS such that RS =
endpoint changes must be continually communicated to the AS. If an RS =
supports multiple AS's then the RS has to deal with "guaranteed" =
delivery. The AS needs an endpoint to receive such communications. If =
not dynamic via APIs, then deployment of the new RS is bound by the =
associated AS's getting and deploying the new endpoints. Can both =
endpoints of the RS be supported within the AS for some period of time, =
etc. This is an operation nightmare and almost assuredly going to go =
wrong in production.
>>>>>=20
>>>>> Maybe an OAuth2 "audience binding" spec is what's needed for those =
deployments that require this. I believe that is what John Bradley is =
suggesting.
>>>>>=20
>>>>> Thanks,
>>>>> George
>>>>>=20
>>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>> +1, I've found the very same in OAuth deployments that I was =
involved in; the hard part is to give names and descriptions to these =
concepts so that they cover all use cases and can be applied =
unambiguously=20
>>>>>>=20
>>>>>> Hans.=20
>>>>>>=20
>>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>>>> I agree that this is valuable, and not just for PoP. In all =
honesty,=20
>>>>>>> it=E2=80=99s not even really required for PoP to function in =
many cases =E2=80=94 it=E2=80=99s=20
>>>>>>> just an optimization for one particular kind of key distribution=20=

>>>>>>> mechanism in that case.=20
>>>>>>>=20
>>>>>>> In the years of deployment experience with OAuth 2, I think =
we=E2=80=99ve really=20
>>>>>>> got three different kinds of things that currently get folded =
into=20
>>>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out =
better:=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>>>   - What actions do I want to take on these things? (read, =
write, delete)=20
>>>>>>>   - How long do I want these tokens to work?=20
>>>>>>> (offline_access/refresh_token, one time use, next hour, etc)=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> I think the first one is close to the audience/resource =
parameters that=20
>>>>>>> have been bandied about a few times, including in the current =
token=20
>>>>>>> exchange document. We should be consistent across drafts in that =
regard.=20
>>>>>>> The second is more traditional scope-ish. The third has been =
patched in=20
>>>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain =
APIs.=20
>>>>>>>=20
>>>>>>> Just another vector to think about if we=E2=80=99re going to be =
adding things=20
>>>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or =
both to the token requests.=20
>>>>>>>=20
>>>>>>>   =E2=80=94 Justin=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>>>   =
> wrote:=20
>>>>>>>>=20
>>>>>>>> Yes I will work on another proposal for allowing clients to =
specify=20
>>>>>>>> what resource they want a token for and providing the meta-data =
to the=20
>>>>>>>> client about the resources that a token is valid for.=20
>>>>>>>>=20
>>>>>>>> We have part of it in the POP key distribution spec and talked =
about=20
>>>>>>>> separating it, as it is used more places than just for =
assigning keys.=20
>>>>>>>> I know some AS use different token formats for different RS so =
are=20
>>>>>>>> all-ready needing to pass the resource in the request to avoid =
making=20
>>>>>>>> a mess of scopes.=20
>>>>>>>>=20
>>>>>>>> John B.=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) < =
phil.hunt@oracle.com =
=20
>>>>>>>>>   =
> wrote:=20
>>>>>>>>>=20
>>>>>>>>> Inline=20
>>>>>>>>>=20
>>>>>>>>> Phil=20
>>>>>>>>>=20
>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>>>>   =
> wrote:=20
>>>>>>>>>=20
>>>>>>>>>> We had two mandates.  One was to provide a spec for AS =
metadata.=20
>>>>>>>>>> The other was to mitigate the client mixup attack.  The =
request was=20
>>>>>>>>>> to do the latter without requiring the former for clients =
that don=E2=80=99t=20
>>>>>>>>>> otherwise need discovery.=20
>>>>>>>>> There is no mandate for any of this. See=20
>>>>>>>>>  =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22=
.txt =
=20
>>>>>>>>>>=20
>>>>>>>>>> Returning the issuer and client_id from the authorization =
endpoint=20
>>>>>>>>>> and the client checking them can be done by the client =
without=20
>>>>>>>>>> discovery.=20
>>>>>>>>>=20
>>>>>>>>> How does this address the issue of whether the client is =
talking to=20
>>>>>>>>> the wrong endpoint?=20
>>>>>>>>>>=20
>>>>>>>>>> Any client that has the resource and issuer hard coded =
probably=20
>>>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>>>> We agree=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> One of the things that a client will need discovery for is to =
find=20
>>>>>>>>>> the RS, so requiring the client to know the RS URI before =
getting=20
>>>>>>>>>> the AS config seems backwards to me.=20
>>>>>>>>> How can you make an assumption on order? You seem to be =
conflating=20
>>>>>>>>> authentication with authorization by assuming the identity =
drives=20
>>>>>>>>> what the resource is.=20
>>>>>>>>>=20
>>>>>>>>> There are lots of applications that require user rights but =
are not=20
>>>>>>>>> identify centric. For example a document service.=20
>>>>>>>>>>=20
>>>>>>>>>> Unless the client tells the AS where it intends to use the =
token we=20
>>>>>>>>>> will be leaving a security hole because the bearer tokens =
will have=20
>>>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>>>=20
>>>>>>>>>> True you are telling the AS (Webfinger service) what the RS =
is but=20
>>>>>>>>>> that is not at a place that is useful in the token production =
process.=20
>>>>>>>>>=20
>>>>>>>>> This has nothing to do with token production.=20
>>>>>>>>>=20
>>>>>>>>> What we want to ensure is whether an honest client is =
correctly=20
>>>>>>>>> configured and has not been mislead - eg by a phishing page.=20=

>>>>>>>>>>=20
>>>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99t =
know all the=20
>>>>>>>>>> possible RS.   That is not something that a out of band check =
can=20
>>>>>>>>>> address.=20
>>>>>>>>>=20
>>>>>>>>> May be. Lets identify them.=20
>>>>>>>>>=20
>>>>>>>>>> There are also cases where a token might be good at multiple =
RS=20
>>>>>>>>>> endpoints intentionally.=20
>>>>>>>>>=20
>>>>>>>>>>  In your solution the client would need to make a discovery =
request=20
>>>>>>>>>> for each endpoint.=20
>>>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool =
of AS=20
>>>>>>>>> servers assigned to each instance?=20
>>>>>>>>>> Those requests lack the context of who the client and =
resource owner=20
>>>>>>>>>> are.  I think that will be a problem in some use cases.=20
>>>>>>>>>=20
>>>>>>>>> Not sure I agree. This is about discovering a valid set of =
endpoints.=20
>>>>>>>>> For mitm, we mainly want to check the hostname is correct. If =
a=20
>>>>>>>>> client chooses evil.com   =
  the cert can be =
valid and=20
>>>>>>>>> TLS will pass. How does it otherwise know it is supposed to =
talk to=20
>>>>>>>>> res.example.com   =
 =
?=20
>>>>>>>>>>=20
>>>>>>>>>> If this is added to the token endpoint it would be checked =
when code=20
>>>>>>>>>> or refresh are exchanged, not every time the token is used.=20=

>>>>>>>>> Your proposal requires rhe client to check. I am not clear how =
the AS=20
>>>>>>>>> can know the exact uri. It is far easier to validate than to =
lookup=20
>>>>>>>>> since as you say the client may be authorized to use multiple =
ASs.=20
>>>>>>>>>> With a out of band check the client would never know if a RS =
was=20
>>>>>>>>>> removed/revoked.=20
>>>>>>>>>=20
>>>>>>>>> Not sure that is in scope.=20
>>>>>>>>>=20
>>>>>>>>> None of the current proposals address this issue.=20
>>>>>>>>>>=20
>>>>>>>>>> I don=E2=80=99t see checking when refreshing a token as =
something that is a=20
>>>>>>>>>> huge burden.=20
>>>>>>>>>=20
>>>>>>>>> Still its a lot more than once.=20
>>>>>>>>>=20
>>>>>>>>> Why don't you draft another alternative?=20
>>>>>>>>>>=20
>>>>>>>>>> If the server wants to do the check on it=E2=80=99s side then =
we could=20
>>>>>>>>>> require the client to send the RS URI in the token request. =
that way=20
>>>>>>>>>> you really know the client is not going to get a token for =
the wrong=20
>>>>>>>>>> RS endpoint.=20
>>>>>>>>>> If you check out of band in discovery you really have no idea =
if the=20
>>>>>>>>>> client is checking.=20
>>>>>>>>>=20
>>>>>>>>> In the new webfinger draft, the client isn't checking. The =
service=20
>>>>>>>>> provider simply does not disclose oauth information to =
misconfigured=20
>>>>>>>>> clients.=20
>>>>>>>>>>=20
>>>>>>>>>> John B.=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt < =
phil.hunt@oracle.com =
=20
>>>>>>>>>>>   =
> wrote:=20
>>>>>>>>>>>=20
>>>>>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll =
take each in turn:=20
>>>>>>>>>>>=20
>>>>>>>>>>> Mike,=20
>>>>>>>>>>>=20
>>>>>>>>>>> Regarding your suggested amendments=20
>>>>>>>>>>>=20
>>>>>>>>>>> Item 1: Returning the config URL would create two problems. =
One,it=20
>>>>>>>>>>> makes bound discovery a two-step process - that adds =
complexity.=20
>>>>>>>>>>>  It seems far simpler to mandate TLS (which I think it =
already does=20
>>>>>>>>>>> in the security considerations).=20
>>>>>>>>>>>=20
>>>>>>>>>>> The two-step process allows the current discovery process to=20=

>>>>>>>>>>> continue. I disagree with this. This is why I put forward an=20=

>>>>>>>>>>> =E2=80=9Calternate" draft that is almost the same but simply =
adds the check=20
>>>>>>>>>>> before returning the configuration data.  I worry that  =
developers=20
>>>>>>>>>>> would have no incentive to do the two-step approach. They =
would=20
>>>>>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at risk =
of exposing=20
>>>>>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Regarding existing implementations. Most of those =
implementations=20
>>>>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue =
use of=20
>>>>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is well =
defined=20
>>>>>>>>>>> and the likelihood of a client mis-informed about the =
resource=20
>>>>>>>>>>> endpoint is not there.  IMO This does not apply to the =
broader=20
>>>>>>>>>>> OAuth community.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Item 2:  It may be appropriate to have a separate =
configuration=20
>>>>>>>>>>> registry specification, but I think we should hold off until =
we=20
>>>>>>>>>>> have a complete solution and then make the decision what =
drafts=20
>>>>>>>>>>> should exist and how many pieces.  A big concern is the =
perceived=20
>>>>>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>>>>>=20
>>>>>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>>>>>=20
>>>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a =
security threat=20
>>>>>>>>>>> by having a discovery specification to prevent clients being=20=

>>>>>>>>>>> mis-lead about endpoints (of which resource service is one) =
in an=20
>>>>>>>>>>> oauth protected exchange.  Maybe what you mean is we should =
not use=20
>>>>>>>>>>> .well-known of any kind and we should just create a =
=E2=80=9C/Config=E2=80=9D=20
>>>>>>>>>>> endpoint to OAuth?=20
>>>>>>>>>>>=20
>>>>>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>>>>>> You propose that instead the resource endpoint check should =
be in=20
>>>>>>>>>>> the oauth protocol itself.  The difference is that =
validation is=20
>>>>>>>>>>> transferred back to the client to get it right. As well, =
without=20
>>>>>>>>>>> the client informing the AS, I can=E2=80=99t see a way for =
the AS to know=20
>>>>>>>>>>> what endpoint the client is using.  The webfinger approach =
does=20
>>>>>>>>>>> this once and only requires that the host name be checked in =
many=20
>>>>>>>>>>> cases.=20
>>>>>>>>>>>=20
>>>>>>>>>>> As a principle, the members have discussed many times that =
the AS=20
>>>>>>>>>>> service should do validation when possible =E2=80=94 this =
was particularly=20
>>>>>>>>>>> true at the Germany meeting when this came up. This is why I =
prefer=20
>>>>>>>>>>> the client tell the service provider what it intends to do =
and the=20
>>>>>>>>>>> service provider can fail that request immediately if =
necessary. We=20
>>>>>>>>>>> don=E2=80=99t have to depend on the developer getting the =
spec correct to=20
>>>>>>>>>>> fail the correct way.=20
>>>>>>>>>>>=20
>>>>>>>>>>> I worry that adding more parameters to the authz and token =
protocol=20
>>>>>>>>>>> flows increases complexity and attack surface. It also means =
per=20
>>>>>>>>>>> authorization validation has to take place vs. a one-time=20
>>>>>>>>>>> validation at config time.  Placing it in the configuration =
lookup=20
>>>>>>>>>>> phase (whether via web finger or just a special OAuth =
endpoint)=20
>>>>>>>>>>> seems more appropriate and far less complex - as the request =
itself=20
>>>>>>>>>>> is simple and has only one parameter. Here we are not =
considered=20
>>>>>>>>>>> about legitimacy of the client. we=E2=80=99re just concerned =
with the issue=20
>>>>>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>>>>>=20
>>>>>>>>>>> That said, it may be that when we consider all the use =
cases, some=20
>>>>>>>>>>> combination of AS protocol and discovery may be both needed. =
I=E2=80=99m=20
>>>>>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>>>>>> oauth-discovery spec seems to put future generic clients at =
risk=20
>>>>>>>>>>> and that is my primary concern.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Best Regards,=20
>>>>>>>>>>>=20
>>>>>>>>>>> Phil=20
>>>>>>>>>>>=20
>>>>>>>>>>> @independentid=20
>>>>>>>>>>>  www.independentid.com =
  =
 =
=20
>>>>>>>>>>>  phil.hunt@oracle.com =
  =
 =
=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>>>>> < =
Michael.Jones@microsoft.com =
  =
 =
>=20
>>>>>>>>>>>> wrote:=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete =
example of=20
>>>>>>>>>>>> a way that protected resource discovery could be added to=20=

>>>>>>>>>>>> authorization server metadata discovery, and as such, =
should=20
>>>>>>>>>>>> provide useful input for working group discussions on this =
topic.=20
>>>>>>>>>>>> It=E2=80=99s always great when someone takes the time to =
write an actual=20
>>>>>>>>>>>> draft that can be examined and implemented, and I =
appreciate you=20
>>>>>>>>>>>> doing that.=20
>>>>>>>>>>>> The content of your draft points out that there appears to =
be=20
>>>>>>>>>>>> complete agreement on what the authorization server =
metadata=20
>>>>>>>>>>>> format should be, which is great!  I=E2=80=99ll note that =
Section 3 of=20
>>>>>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorizatio=
n Server=20
>>>>>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo=20=

>>>>>>>>>>>> applying a correction suggested by the working group.  To =
me this=20
>>>>>>>>>>>> suggests that the authorization server metadata definitions =
in=20
>>>>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole =
normative=20
>>>>>>>>>>>> content of the draft) are clearly ready for =
standardization, since=20
>>>>>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>>>>>> Reading your draft, the problem I have with it is that you =
are=20
>>>>>>>>>>>> returning the AS metadata only as a WebFinger response, =
rather=20
>>>>>>>>>>>> than as an https-protected resource published by the =
authorization=20
>>>>>>>>>>>> server.  The choice to only return this via WebFinger makes =
your=20
>>>>>>>>>>>> draft incompatible with most deployed implementations of =
OAuth=20
>>>>>>>>>>>> metadata, including the 22 implementations using it listed=20=

>>>>>>>>>>>> athttp://openid.net/certification/ <>(see the =E2=80=9COP =
Config=E2=80=9D column in=20
>>>>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99s=
 =E2=80=9CADAL=E2=80=9D=20
>>>>>>>>>>>> library, which uses the metadata path for client =
configuration.=20
>>>>>>>>>>>> Without having ASs provide the metadata as an =
https-protected=20
>>>>>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use it =
for client=20
>>>>>>>>>>>> configuration as the currently do.=20
>>>>>>>>>>>> Therefore, I would request that you make these minor =
revisions to=20
>>>>>>>>>>>> your draft and republish, so as to provide a unified way =
forward=20
>>>>>>>>>>>> that is compatible with all known existing OAuth Discovery=20=

>>>>>>>>>>>> deployments:=20
>>>>>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D=20
>>>>>>>>>>>> to have the WebFinger request return the issuer identifier =
for the=20
>>>>>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, =
rather than returning the=20
>>>>>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D =
value.=20
>>>>>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in =
your=20
>>>>>>>>>>>> Section 3.=20
>>>>>>>>>>>> That would have the advantage of paring your draft down to =
only=20
>>>>>>>>>>>> the new things that it proposes, enabling them to be more =
clearly=20
>>>>>>>>>>>> understood and evaluated on their own merits.  I look =
forward to=20
>>>>>>>>>>>> the discussions of ways of performing additional kinds of =
OAuth=20
>>>>>>>>>>>> discovery, and consider your draft a valuable input to =
those=20
>>>>>>>>>>>> discussions.=20
>>>>>>>>>>>>                                                           =
Best wishes,=20
>>>>>>>>>>>>                                                           =
-- Mike=20
>>>>>>>>>>>> *From:*OAuth [ =
mailto:oauth-bounces@ietf.org =
]*On Behalf Of*John Bradley=20
>>>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>>>>>> *To:*Phil Hunt < =
phil.hunt@oracle.com =
  =
 =
>=20
>>>>>>>>>>>> *Cc:*oauth < oauth@ietf.org =
   =
>=20
>>>>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>>>> As I have told Phil off list.=20
>>>>>>>>>>>> Discovery is the wrong place to try and provide security =
against=20
>>>>>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>>>>>> This requires the client to know what the RS URI is before=20=

>>>>>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>>>>>> The proposal Mike and I have been working on requires the =
client=20
>>>>>>>>>>>> to have a notion of what API it is looking for and retrieve =
the=20
>>>>>>>>>>>> .well-known file for that API from the issuer.   That =
allows a=20
>>>>>>>>>>>> protocol like Connect to register its own config file that =
can=20
>>>>>>>>>>>> point to the RS.=20
>>>>>>>>>>>> If the API specific well known is not available the client =
can try=20
>>>>>>>>>>>> the default oauth-server one.=20
>>>>>>>>>>>> That then allows us to deal with restricting where AT are=20=

>>>>>>>>>>>> presented as part of the protocol rather then dragging =
discovery=20
>>>>>>>>>>>> in as a requirement.=20
>>>>>>>>>>>> In my opinion the resource the token is targeted to should =
be=20
>>>>>>>>>>>> separated from the scope and returned as part of the =
meta-data=20
>>>>>>>>>>>> about the AT along with scopes granted and expiry time.   =
We=20
>>>>>>>>>>>> should also have a input parameter for resources so that a =
client=20
>>>>>>>>>>>> can restrict tokens issued to a subset of the ones granted =
by the=20
>>>>>>>>>>>> refresh token.   It would then also be possible to ask a AS =
for a=20
>>>>>>>>>>>> token for a unregistered RS and have the AS produce a JWT =
access=20
>>>>>>>>>>>> token with the resource as an audience if policy allows.=20
>>>>>>>>>>>> That however was supposed to be dealt with as part of the =
mixed up=20
>>>>>>>>>>>> client set of mitigations.=20
>>>>>>>>>>>> In that the goal was to mitigate the attacks by returning=20=

>>>>>>>>>>>> meta-data about the tokens, and not to require discovery.=20=

>>>>>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Ccleint_id=E2=80=9D for the code, and I=20
>>>>>>>>>>>> intend to discuss at the F2F returning resource for AT as =
well.=20
>>>>>>>>>>>> Those mitigate the attack.=20
>>>>>>>>>>>> I will continue to resist mixing up discovery of =
configuration=20
>>>>>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>>>>>> We return meta-data about the tokens now, because AT are =
opaque to=20
>>>>>>>>>>>> the client, we neglected to include some of the information =
for=20
>>>>>>>>>>>> the client needs to be secure.   We just need to add that =
in to=20
>>>>>>>>>>>> the existing flows.=20
>>>>>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add=20
>>>>>>>>>>>> on, it puts more of a burden on the client needing to =
potentially=20
>>>>>>>>>>>> change how it stores the relationships between AS and RS to=20=

>>>>>>>>>>>> prevent compromise, I think the solution should be biased =
towards=20
>>>>>>>>>>>> simplicity on the client side.=20
>>>>>>>>>>>> If we return the resources as part of the existing meta =
data the=20
>>>>>>>>>>>> client checks that against the resource it intends to send =
the=20
>>>>>>>>>>>> token to and if it is not in the list then it can=E2=80=99t =
send the=20
>>>>>>>>>>>> token.  Simple check every time it gets a new AT, no =
optionality.=20
>>>>>>>>>>>> I am not saying anything new Nat has been advocating =
basically=20
>>>>>>>>>>>> this for some time, and dis submit a draft.   I prefer to =
return=20
>>>>>>>>>>>> the info in the existing format rather than as link =
headers,  but=20
>>>>>>>>>>>> that is the largest difference between what Nat and I are =
saying=20
>>>>>>>>>>>> with respect to resource.=20
>>>>>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20=

>>>>>>>>>>>> I guess we will need to have a long conversation in BA.=20
>>>>>>>>>>>> Regards=20
>>>>>>>>>>>> John B.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt < =
phil.hunt@oracle.com =
=20
>>>>>>>>>>>>      =
 =
> wrote:=20
>>>>>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the =
same=20
>>>>>>>>>>>>     registry for OAuth Config Metadata as the authors =
believe that=20
>>>>>>>>>>>>     both solutions are not required, or depending on WG =
discussion=20
>>>>>>>>>>>>     they will be merged. The intent is to provide a simple=20=

>>>>>>>>>>>>     complete draft for consideration.=20
>>>>>>>>>>>>     How it works...=20
>>>>>>>>>>>>     Given that a client has previously discovered an OAuth=20=

>>>>>>>>>>>>     protected resource, the bound configuration method =
allows a=20
>>>>>>>>>>>>     client to return the configuration for an oauth =
authorization=20
>>>>>>>>>>>>     server that can issue tokens for the resource URI =
specified by=20
>>>>>>>>>>>>     the client.  The AS is not required to be in the same =
domain.=20
>>>>>>>>>>>>      The AS is however required to know if it can issue =
tokens for=20
>>>>>>>>>>>>     a resource service (which presumes some agreement =
exists on=20
>>>>>>>>>>>>     tokens etc).=20
>>>>>>>>>>>>     The draft does not require that the resource exist =
(e.g. for=20
>>>>>>>>>>>>     unconfigured or new user based resources). It only =
requires=20
>>>>>>>>>>>>     that the AS service provider agrees it can issue =
tokens.=20
>>>>>>>>>>>>     =46rom a security perspective, returning the OAuth =
service=20
>>>>>>>>>>>>     configuration for a specified resource URI serves to =
confirm=20
>>>>>>>>>>>>     the client is in possession of a valid resource URI =
ensuring=20
>>>>>>>>>>>>     the client has received a valid set of endpoints for =
the=20
>>>>>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>>>>>     I propose that the WG consider the alternate draft =
carefully=20
>>>>>>>>>>>>     as well as other submissions and evaluate the broader=20=

>>>>>>>>>>>>     discovery problem before proceeding with WGLC on OAuth =
Discovery.=20
>>>>>>>>>>>>     Thanks!=20
>>>>>>>>>>>>     Phil=20
>>>>>>>>>>>>     @independentid=20
>>>>>>>>>>>>      www.independentid.com =
  =
 =
=20
>>>>>>>>>>>>      phil.hunt@oracle.com =
  =
 =
=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>         Begin forwarded message:=20
>>>>>>>>>>>>         *From:* =
internet-drafts@ietf.org =
=20
>>>>>>>>>>>>          =
 =
=20
>>>>>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>>>>>         *To:*"Phil Hunt" < =
phil.hunt@yahoo.com =
=20
>>>>>>>>>>>>          =
 =
>, "Anthony Nadalin"=20
>>>>>>>>>>>>         < =
tonynad@microsoft.com =
  =
 =
>,=20
>>>>>>>>>>>>         "Tony Nadalin" < =
tonynad@microsoft.com =
=20
>>>>>>>>>>>>          =
 =
>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>         A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>>>>         has been successfully submitted by Phil Hunt and =
posted to the=20
>>>>>>>>>>>>         IETF repository.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>>>>>         Revision:00=20
>>>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>>>>>         Group:Individual Submission=20
>>>>>>>>>>>>         Pages:22=20
>>>>>>>>>>>>         URL:=20
>>>>>>>>>>>>          =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt=
 =

>>>>>>>>>>>>         Status:=20
>>>>>>>>>>>>          =
https://d=
atatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =
=20
>>>>>>>>>>>>         Htmlized:=20
>>>>>>>>>>>>          =
https://tool=
s.ietf.org/html/draft-hunt-oauth-bound-config-00 =
=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>         Abstract:=20
>>>>>>>>>>>>           This specification defines a mechanism for the =
client of=20
>>>>>>>>>>>>         an OAuth 2.0=20
>>>>>>>>>>>>           protected resource service to obtain the =
configuration=20
>>>>>>>>>>>>         details of an=20
>>>>>>>>>>>>           OAuth 2.0 authorization server that is capable of=20=

>>>>>>>>>>>>         authorizing access=20
>>>>>>>>>>>>           to a specific resource service.  The information=20=

>>>>>>>>>>>>         includes the OAuth=20
>>>>>>>>>>>>           2.0 component endpoint location URIs and as well =
as=20
>>>>>>>>>>>>         authorization=20
>>>>>>>>>>>>           server capabilities.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>         Please note that it may take a couple of minutes =
from the=20
>>>>>>>>>>>>         time of submission=20
>>>>>>>>>>>>         until the htmlized version and diff are available=20=

>>>>>>>>>>>>         attools.ietf.org   =
 =
.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>         The IETF Secretariat=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>     _______________________________________________=20
>>>>>>>>>>>>     OAuth mailing list=20
>>>>>>>>>>>>      OAuth@ietf.org =
   =
=20
>>>>>>>>>>>>      =
https://www.ietf.org/mailman/=
listinfo/oauth =20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________=20
>>>>>>>> OAuth mailing list=20
>>>>>>>>  OAuth@ietf.org   =
 =20=

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

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

>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 


--Apple-Mail=_C08FE2D0-A615-4290-805D-0C31331E3A77
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I think Phil and others are concerned that a developer might =
get bad info to put in the client , some out of band discovery goes =
wrong or the user is somehow tricked into specifying a bad resource to =
the client.

    So =
getting a bad resource is a touch hypothetical. 

    For Connect we could =
suppose that someone publishes a malicious discovery document listing =
themselves as the RS but all the other endpoints are at the good AS so =
the client registers, authorizes the user and gives the AT to the bad =
guy.  The confused client mitigation by returning client_id_and =
issuer from the authorization endpoint will stop the attack before the =
token can be given to the token endpoint or RS.

    So protecting the AT at this point is =
more for a unknown attack that would confuse whatever protocol/API that =
is using OAuth about what RS to use.

    In reality this is what PoP is supposed =
to be for.

    I =
guess the question is what short of PoP can we do to prevent the client =
leaking tokens to bad RS that confuse it via the application =
protocol.

    If =
we want to del with this in OAuth then we need to tell the AS where the =
token is going to be used or tel the client where the token can be =
used. 

    I =
think letting the client tell the AS where it wants the token used =
having the AS construct a audience out of that is probably the best =
thing.  to get around having a pre-established relationship between =
the AS and RS.

    John B.

    On Mar 15, 2016, at 3:14 PM, =
George Fletcher <gffletch@aol.com> wrote:



    I think =
Justin provided a good break down of the different aspects a client =
wants to specify about the requested token. (my paraphrase)
      1. what RS's the token will be used at
      2. authorization privilege requests
     =
 3. token-timing adjustments

    I'm not sure =
passing the full endpoint to the AS will help with my concerns... The AS =
could potentially do a webfinger on the resource URI and determine if =
it's an RS that it supports... though that requires all RS's to support =
webfinger. What I really want to avoid is the AS having this list of =
URIs to RS that is almost assuredly to get out of sync.



    On 3/15/16 1:56 PM, John Bradley wrote:
    I think it is a AS policy decision if it should error or take =
the requested resource and issue a token audianced for that =
resource.
    Actually, the error =
cases are interesting. What if the passed in resource/audience doesn't =
actually match a requested scope? Or some match and some don't? Is it =
better to send back a token with less capability? or error the entire =
request?

    I guess =
the question is how to transition from now to a future state.   If =
you cannot upgrade all the clients at once.

    A processing rule on the AS that =
allowed some clients to not send the requested resource , but would =
error out for other upgraded clients  with a "resource not =
allowed=E2=80=9D oauth error would work and not require the return of =
the resources.  

    If you return the resources and let the client error if it is =
trying to send to the wrong endpoint that make upgrading easier, but =
gives less control to the AS.

    I could live with it ether way.
    The advantage of always sending it in the token =
request is that it allows the AS to do the mapping from a resource URI =
to one or more abstract audience for the =
token.
    I thought Justin =
provided a good break down of the different aspects a client wants to =
specify about the requested token. (my paraphrase)
      =
1. what RS's the token will be used at
      2. =
authorization privilege requests
      3. token-timing =
adjustments

    The question is how does a =
client internally reference a resource server? If it's a fixed RS =
endpoint, then it sort of doesn't matter, the client isn't going to send =
the token to the wrong endpoint anyway and it can easily reference the =
audience by an abstract URI.

    If the client =
can dynamically find new RS's to interact with. How does that happen? =
Does the client get handed an endpoint to use? or does it do some sort =
of discovery to determine the endpoint? I suppose both are possible.

    Could we prescribe that the realm value of RFC =
6750 error response be effectively a resource-service-id (like issuer =
for the AS). The client would then need to do discovery on that value to =
find the valid endpoints of the RS. This could be done once and the =
resource-service-id could be used as the "abstract" RS identifier. This =
requires no more discovery than adding an AS to the client.

    That might help address George=E2=80=99s =
concern.
    I'm not sure passing =
the full endpoint to the AS will help with my concerns... The AS could =
potentially do a webfinger on the resource URI and determine if it's an =
RS that it supports... though that requires all RS's to support =
webfinger. What I really want to avoid is the AS having this map of URIs =
to RS that is almost assuredly to get out of sync.

    John B.


    On Mar 15, 2016, at 2:44 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

    I was thinking it'd be simpler to error, if the requested =
resource(s) weren't okay. That puts the burden of checking in the AS. =
And doesn't add anything to the token or authorization response. I see =
the potential similarity to scope but not sure it's worth it.  =
  

    On Tue, =
Mar 15, 2016 at 11:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    If the client specifies the resource it =
wants the token for, then the meta-data would not be required unless the =
resources the token is good at are different from the request. =
 
    Lat is the same logic as scopes.

    For backwards =
compatibility if the client is happy with the default resources based on =
scopes then I think it is a good idea to tell the client what the =
resources are in the response.

    I suspect that it is simpler with less =
optionality and always return the resources, even if they are not =
required.

    John =
B.

    On Mar 15, 2016, at 12:46 PM, Brian Campbell =
<bcampbell@pingidentity.com&=
gt; wrote:

    If the client specifies the desired audience(s)/resource(s), =
is that metadata to the client needed? The AS can audience restrict the =
token as needed or respond with an error if it can't or wont issue a =
token for the resource the client asked for. 

    On Tue, Mar 15, 2016 at 9:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    Yes,  I think bearer tokens with =
no audience are a bad idea.

    The AS needs to infer an audience from the scopes snd/or have =
the client specify the desired audience.

    If the AT has a audience or audiences =
then as long as the endpoint URI are provided as meta-data with the =
token, the client can determine if it is sending the token to the =
correct place.

    I=
 think Phil would prefer the server rather than the client do the check, =
but the client always needs to take some responsibility to not leak =
tokens giving them to the wrong RS or the code to the wrong token =
endpoint is leaking.

    I imagine that claims based access tokens are going to become =
more popular and the static relationship between one RS and one AS will =
not be the majority of deployments over time. 

    In any case where the =
client is configured up front to know the RS and the AS it seems like =
that would not require Phil=E2=80=99s Solution, but that is the only =
case supported by that discovery.
      
    If the client itself is bad =
there is not much you can do to stop it from passing on the AT in way =
way it wants.  That however is a different problem and needs =
claimed URI or attestations to prevent client spoofing.
    William and I are working on that in the mobile best =
practices draft.

    John B.


    On Mar 15, 2016, at 12:09 PM, George Fletcher =
<gffletch@aol.com> =
wrote:

    I =
worry about two directions I see in this thread...

    1. Client's accessing resources dynamically so that discovery =
is required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
    2. Creating a tight coupling between RS and AS such that RS =
endpoint changes must be continually communicated to the AS. If an RS =
supports multiple AS's then the RS has to deal with "guaranteed" =
delivery. The AS needs an endpoint to receive such communications. If =
not dynamic via APIs, then deployment of the new RS is bound by the =
associated AS's getting and deploying the new endpoints. Can both =
endpoints of the RS be supported within the AS for some period of time, =
etc. This is an operation nightmare and almost assuredly going to go =
wrong in production.

    Maybe an OAuth2 =
"audience binding" spec is what's needed for those deployments that =
require this. I believe that is what John Bradley is suggesting.

    Thanks,
    George

    On 3/14/16 7:29 PM, Hans Zandbelt wrote:
    +1, I've found the =
very same in OAuth deployments that I was involved in; the hard part is =
to give names and descriptions to these concepts so that they cover all =
use cases and can be applied unambiguously 

    Hans. 

    On 3/14/16 10:44 PM, Justin Richer wrote: 
    I agree that this is valuable, and not just for =
PoP. In all honesty, it=E2=80=99s not even really required for PoP to function in =
many cases =E2=80=94 it=E2=80=99s 
    just an =
optimization for one particular kind of key distribution 
    mechanism in =
that case. 

    In the years of deployment experience with =
OAuth 2, I think we=E2=80=99ve really 
    got three =
different kinds of things that currently get folded into 
    =E2=80=9Cscope=
=E2=80=9D that we might want to try separating out better: 


      - What things do I want to =
access? (photos, profile) 
      - What actions do I want to =
take on these things? (read, write, delete) 
      - How long do I want these =
tokens to work? 
    (offline_access/refresh_token, one time use, next hour, =
etc) 


    I think the first one is close to the =
audience/resource parameters that 
    have been =
bandied about a few times, including in the current token 
    exchange =
document. We should be consistent across drafts in that regard. 
    The second =
is more traditional scope-ish. The third has been patched in 
    with things =
like =E2=80=9Coffline_access=E2=80=9D in certain APIs. 

    Just another vector to think about if we=E2=80=99re going to =
be adding things 
    like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D =
or both to the token requests. 

      =E2=80=
=94 Justin 


    On Mar 14, 2016, at 6:26 PM, John Bradley <ve7jtb@ve7jtb.com 
    <mailto:ve7jtb@ve7jtb.com>>=
 wrote: 

    Yes I will work on another proposal for =
allowing clients to specify 
    what =
resource they want a token for and providing the meta-data to the 
    client about =
the resources that a token is valid for. 

    We have part of it in the POP key distribution spec and =
talked about 
    separating it, as it is used more places than just for =
assigning keys. 
    I know some AS use different token formats for different RS =
so are 
    all-ready needing to pass the resource in the request to =
avoid making 
    a mess of scopes. 

    John B. 




    On Mar 14, 2016, at =
7:17 PM, Phil Hunt (IDM) <phil.hunt@oracle.com 
    <mailto:phil.hunt@oracle.com>> wrote: 

    Inline 

    Phil 

    On Mar 14, 2016, at 14:13, John Bradley <    ve7jtb@ve7jtb.com 
    <mailto:ve7jtb@ve7jtb.com>>=
 wrote: 

    We had =
two mandates.  One was to provide a spec for AS metadata. 
    The other =
was to mitigate the client mixup attack.  The request was 
    to do the =
latter without requiring the former for clients that don=E2=80=99t 
    otherwise =
need discovery. 
    There is no mandate for any of this. See 
    http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt 

    Returning =
the issuer and client_id from the authorization endpoint 
    and the =
client checking them can be done by the client without 
    discovery. 

    How does this address the issue =
of whether the client is talking to 
    the wrong =
endpoint? 

    Any =
client that has the resource and issuer hard coded probably 
    doesn=E2=80=99=
t need discovery. 
    We agree 


    One of =
the things that a client will need discovery for is to find 
    the RS, so =
requiring the client to know the RS URI before getting 
    the AS =
config seems backwards to me. 
    How can you make an assumption on order? You =
seem to be conflating 
    authentication=
 with authorization by assuming the identity drives 
    what the =
resource is. 

    There are lots of applications that require =
user rights but are not 
    identify =
centric. For example a document service. 

    Unless the client tells the AS =
where it intends to use the token we 
    will be =
leaving a security hole because the bearer tokens will have 
    too loose an =
audience if they have one at all. 
    This is the biggest risk we have IMHO. 

    True you are telling the AS =
(Webfinger service) what the RS is but 
    that is not =
at a place that is useful in the token production process. 

    This has nothing to do with token =
production. 

    What we want to ensure is whether an honest =
client is correctly 
    configured and has not been mislead - eg by a phishing =
page. 

    I also =
think there are use cases where the AS doesn=E2=80=99t know all the 
    possible =
RS.   That is not something that a out of band check can 
    address. 

    May be. Lets identify them. 

    There are also cases =
where a token might be good at multiple RS 
    endpoints =
intentionally. 

     In your solution the client would need to make a =
discovery request 
    for each endpoint. 
    Sure. Otherwise how would it know if there is =
one AS or a pool of AS 
    servers =
assigned to each instance? 
    Those requests lack the context of who the =
client and resource owner 
    are.  I =
think that will be a problem in some use cases. 

    Not sure I agree. This is about =
discovering a valid set of endpoints. 
    For mitm, we =
mainly want to check the hostname is correct. If a 
    client =
chooses evil.com <http://evil.com/> the cert can be valid =
and 
    TLS =
will pass. How does it otherwise know it is supposed to talk to 
    res.example.com <http://res.example.com/>? 

    If this is added to the token =
endpoint it would be checked when code 
    or refresh =
are exchanged, not every time the token is used. 
    Your proposal requires rhe client to check. I am =
not clear how the AS can know the exact uri. It is far easier to validate than to =
lookup 
    since as you say the client may be authorized to use multiple =
ASs. 
    With a out of band check =
the client would never know if a RS was 
    removed/revoked. 

    Not sure that is in scope. 

    None of the current proposals address this issue. 

    I don=E2=80=99t see checking =
when refreshing a token as something that is a 
    huge =
burden. 

    Still its a lot more than =
once. 
    Why don't you draft another alternative? 

    If the server wants to do the =
check on it=E2=80=99s side then we could 
    require the =
client to send the RS URI in the token request. that way 
    you really =
know the client is not going to get a token for the wrong 
    RS =
endpoint. 
    If you check out of band in discovery you really have no idea =
if the 
    client is checking. 

    In the new webfinger draft, the =
client isn't checking. The service 
    provider =
simply does not disclose oauth information to misconfigured 
    clients. 

    John B. 


    On Mar =
14, 2016, at 3:56 PM, Phil Hunt <phil.hunt@oracle.com 
    <mailto:phil.hunt@oracle.com>> wrote: 

    Thanks to Mike and John for their =
feedback.  I=E2=80=99ll take each in turn: 

    Mike, 

    Regarding your suggested amendments 

    Item 1: Returning the config URL would create two problems. =
One,it 
    makes bound discovery a two-step process - that adds =
complexity. 
     It seems far simpler to mandate TLS (which I think it =
already does 
    in the security considerations). 

    The two-step process allows the current discovery process =
to 
    continue. I disagree with this. This is why I put forward =
an 
    =E2=80=9Calternate" draft that is almost the same but simply =
adds the check 
    before returning the configuration data.  I worry =
that  developers 
    would have =
no incentive to do the two-step approach. They would 
    just start =
at step 2 which in turn puts AS=E2=80=99s at risk of exposing 
    tokens =
because it works. This makes OAuth promiscuous. 

    Regarding existing implementations. Most of those =
implementations 
    are for OIDC.  I think it makes sense for OIDF to =
continue use of 
    OIDC's discovery spec because the UserInfo endpoint is well =
defined 
    and the likelihood of a client mis-informed about the =
resource 
    endpoint is not there.  IMO This does not apply to the =
broader 
    OAuth community. 

    Item 2:  It may be appropriate to have a separate =
configuration 
    registry specification, but I think we should hold off until =
we 
    have =
a complete solution and then make the decision what drafts 
    should exist =
and how many pieces.  A big concern is the perceived 
    complexity =
of multiple solutions and multiple drafts. 

    As to John Bradley=E2=80=99s comments: 

    Re: Discovery is the wrong place to mitigate threats. 
    I=E2=80=99m =
confused by this.  Our mandate was to solve a security threat 
    by having a =
discovery specification to prevent clients being 
    mis-lead =
about endpoints (of which resource service is one) in an 
    oauth =
protected exchange.  Maybe what you mean is we should not use 
    .well-known =
of any kind and we should just create a =E2=80=9C/Config=E2=80=9D 
    endpoint to =
OAuth? 

    Re: Your proposal for MITM mitigation 
    You propose =
that instead the resource endpoint check should be in 
    the oauth =
protocol itself.  The difference is that validation is 
    transferred =
back to the client to get it right. As well, without 
    the client =
informing the AS, I can=E2=80=99t see a way for the AS to know 
    what =
endpoint the client is using.  The webfinger approach does 
    this once =
and only requires that the host name be checked in many 
    cases. 

    As a principle, the members have discussed many times that =
the AS 
    service should do validation when possible =E2=80=94 this was =
particularly 
    true at the Germany meeting when this came up. This is why I =
prefer 
    the client tell the service provider what it intends to do =
and the 
    service provider can fail that request immediately if =
necessary. We 
    don=E2=80=99t have to depend on the developer getting the =
spec correct to 
    fail the correct way. 

    I worry that adding more parameters to the authz and token =
protocol 
    flows increases complexity and attack surface. It also means =
per 
    authorization validation has to take place vs. a =
one-time 
    validation at config time.  Placing it in the =
configuration lookup phase (whether via web finger or just a special OAuth =
endpoint) 
    seems more appropriate and far less complex - as the request =
itself 
    is=
 simple and has only one parameter. Here we are not considered 
    about =
legitimacy of the client. we=E2=80=99re just concerned with the =
issue 
    "has the client been correctly informed?=E2=80=9D 

    That said, it may be that when we consider all the use cases, =
some 
    combination of AS protocol and discovery may be both needed. =
I=E2=80=99m 
    not ready to make conclusions about this.  The =
current 
    oauth-discovery spec seems to put future generic clients at =
risk 
    and =
that is my primary concern. 

    Best Regards, 

    Phil 

    @independentid 
    www.independentid.com <http://www.independentid.com/&g=
t; 
    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 





    On Mar 13, 2016, at =
10:28 PM, Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@micro=
soft.com>> wrote: 

    Thanks for posting this, Phil.  It =
provides a concrete example of 
    a way that =
protected resource discovery could be added to 
    authorization =
server metadata discovery, and as such, should 
    provide =
useful input for working group discussions on this topic. 
    It=E2=80=99s =
always great when someone takes the time to write an actual 
    draft that =
can be examined and implemented, and I appreciate you 
    doing =
that. 
    The=
 content of your draft points out that there appears to be 
    complete =
agreement on what the authorization server metadata 
    format =
should be, which is great!  I=E2=80=99ll note that Section 3 =
of 
    draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorization =
Server 
    Metadata=E2=80=9D is an exact copy of Section 2 of 
    draft-ietf-oauth-discovery-01 (with the same title), =
modulo 
    applying a correction suggested by the working group.  =
To me this 
    suggests that the authorization server metadata definitions =
in 
    draft-ietf-oauth-discovery (which is now the whole =
normative 
    content of the draft) are clearly ready for standardization, =
since 
    even your alternative proposal includes them verbatim. 
    Reading your =
draft, the problem I have with it is that you are 
    returning =
the AS metadata only as a WebFinger response, rather 
    than as an =
https-protected resource published by the authorization 
    server.  =
The choice to only return this via WebFinger makes your 
    draft =
incompatible with most deployed implementations of OAuth 
    metadata, =
including the 22 implementations using it listed 
    athttp://openid.net/certification/(see the =E2=80=9COP =
Config=E2=80=9D column in 
    the table) =
andOAuth 2.0 libraries such as Microsoft=E2=80=99s =E2=80=9CADAL=E2=80=9D<=
span class=3D"Apple-converted-space"> 
    library, =
which uses the metadata path for client configuration. 
    Without =
having ASs provide the metadata as an https-protected 
    resource, =
implementations such as ADAL can=E2=80=99t use it for client 
    configuration =
as the currently do. Therefore, I would request that you make these minor =
revisions to 
    your draft and republish, so as to provide a unified way =
forward 
    that is compatible with all known existing OAuth =
Discovery 
    deployments: 
    1.Modify =
your section 2 =E2=80=9CAuthorization Server WebFinger Discovery=E2=80=9D<=
span class=3D"Apple-converted-space"> 
    to have =
the WebFinger request return the issuer identifier for the 
    AS as the =
=E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, rather than returning =
the 
    metadata values by value as the =E2=80=9Cproperties=E2=80=9D =
value. 
    2.Reference the metadata definitions from Section 2 of 
    draft-ietf-oauth-discovery, rather than duplicating them in =
your 
    Section 3. 
    That would =
have the advantage of paring your draft down to only 
    the new =
things that it proposes, enabling them to be more clearly 
    understood =
and evaluated on their own merits.  I look forward to 
    the =
discussions of ways of performing additional kinds of OAuth 
    discovery, =
and consider your draft a valuable input to those 
    discussions. 
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          Best wishes, 
              &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike 
    *From:*OAuth =
[mailto:oauth-bounces@ietf.org]*=
On Behalf Of*John Bradley 
    *Sent:*Sunday,=
 March 13, 2016 6:45 PM 
    *To:*Phil =
Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> 
    *Cc:*oauth <    oauth@ietf.org <mailto:oauth@ietf.org>> 
    *Subject:*Re: =
[OAUTH-WG] New Version Notification for 
    draft-hunt-oauth-bound-config-00.txt 
    As I have =
told Phil off list. 
    Discovery is the wrong place to try and provide security =
against 
    man in the middle attacks on the RS. 
    This =
requires the client to know what the RS URI is before 
    retrieving =
the information on the AS Configuration. 
    The proposal =
Mike and I have been working on requires the client 
    to have a =
notion of what API it is looking for and retrieve the 
    .well-known =
file for that API from the issuer.   That allows a 
    protocol =
like Connect to register its own config file that can 
    point to the =
RS. 
    If =
the API specific well known is not available the client can try 
    the default =
oauth-server one. 
    That then allows us to deal with restricting where AT =
are 
    presented as part of the protocol rather then dragging =
discovery 
    in as a requirement. 
    In my =
opinion the resource the token is targeted to should be 
    separated =
from the scope and returned as part of the meta-data 
    about the AT =
along with scopes granted and expiry time.   We 
    should also =
have a input parameter for resources so that a client 
    can restrict =
tokens issued to a subset of the ones granted by the 
    refresh =
token.   It would then also be possible to ask a AS for a 
    token for a =
unregistered RS and have the AS produce a JWT access 
    token with =
the resource as an audience if policy allows. 
    That however =
was supposed to be dealt with as part of the mixed up 
    client set =
of mitigations. 
    In that the goal was to mitigate the attacks by =
returning 
    meta-data about the tokens, and not to require =
discovery. 
    We intend to return =E2=80=9Ciss=E2=80=9D and =E2=80=9Ccleint_i=
d=E2=80=9D for the code, and I 
    intend to =
discuss at the F2F returning resource for AT as well. 
    Those =
mitigate the attack. I will continue to resist mixing up discovery of =
configuration 
    meta-data with mitigation of the attacks. 
    We return =
meta-data about the tokens now, because AT are opaque to 
    the client, =
we neglected to include some of the information for 
    the client =
needs to be secure.   We just need to add that in to 
    the existing =
flows. 
    While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add 
    on, it puts more of a burden on the client needing to =
potentially 
    change how it stores the relationships between AS and RS =
to 
    prevent compromise, I think the solution should be biased =
towards 
    simplicity on the client side. 
    If we return =
the resources as part of the existing meta data the 
    client =
checks that against the resource it intends to send the 
    token to and =
if it is not in the list then it can=E2=80=99t send the 
    token.  =
Simple check every time it gets a new AT, no optionality. 
    I am not =
saying anything new Nat has been advocating basically 
    this for =
some time, and dis submit a draft.   I prefer to return 
    the info in =
the existing format rather than as link headers,  but 
    that is the =
largest difference between what Nat and I are saying 
    with respect =
to resource. 
    That is the core of my problem with Phil=E2=80=99s =
draft. 
    I =
guess we will need to have a long conversation in BA. 
    Regards 
    John B. 

        On Mar 13, 2016, at 8:12 =
PM, Phil Hunt <phil.hunt@oracle.com 
        <mailto:phil.hunt@oracle.com>> wrote: 
        This draft is a proposed =
alternate proposal for 
        draft-ietf-oauth-discovery.&n=
bsp; As such, it contains the same 
        registry for OAuth Config =
Metadata as the authors believe that 
        both solutions are not =
required, or depending on WG discussion 
        they will be merged. The =
intent is to provide a simple 
        complete draft for =
consideration. 
        How it works... 
        Given that a client has =
previously discovered an OAuth 
        protected resource, the =
bound configuration method allows a 
        client to return the =
configuration for an oauth authorization 
        server that can issue =
tokens for the resource URI specified by 
        the client.  The AS is =
not required to be in the same domain. 
         The AS is however required =
to know if it can issue tokens for 
        a resource service (which =
presumes some agreement exists on 
        tokens etc). 
        The draft does not require =
that the resource exist (e.g. for 
        unconfigured or new user =
based resources). It only requires 
        that the AS service =
provider agrees it can issue tokens. 
        =46rom a security =
perspective, returning the OAuth service 
        configuration for a =
specified resource URI serves to confirm 
        the client is in possession =
of a valid resource URI ensuring 
        the client has received a =
valid set of endpoints for the 
        resource and the associated =
oauth services. 
        I propose that the WG =
consider the alternate draft carefully 
        as well as other =
submissions and evaluate the broader 
        discovery problem before =
proceeding with WGLC on OAuth Discovery. 
        Thanks! 
        Phil 
        @independentid 
            www.independentid.com <http://www.independentid.com/&g=
t; 
        phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 


            Begin forwarded =
message: 
            *From:*    internet-drafts@ietf.org 
            <mailto:internet-drafts@ietf.o=
rg> 
            *Subject: New Version =
Notification for 
            draft-hunt-oauth-bound-config=
-00.txt* 
            *Date:*March 13, 2016 at =
3:53:37 PM PDT 
            *To:*"Phil Hunt" <phil.hunt@yahoo.com 
            <mailto:phil.hunt@yahoo.com>=
>, "Anthony Nadalin" 
            <tonynad@microsoft.com <mailto:tonynad@microsoft.com>=
>, 
            "Tony Nadalin" <tonynad@microsoft.com 
            <mailto:tonynad@microsoft.com>=
> 


            A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt 
            has been successfully =
submitted by Phil Hunt and posted to the 
            IETF repository. 

            Name:draft-hunt-oauth-bound-c=
onfig 
            Revision:00 
            Title:OAuth 2.0 Bound =
Configuration Lookup         Document =
date:2016-03-13 
            Group:Individual =
Submission 
            Pages:22 
            URL: 
            https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-confi=
g-00.txt
            Status: 
            h=
ttps://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ 
            Htmlized: 
            http=
s://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 


            Abstract: 
              This specification defines =
a mechanism for the client of 
            an OAuth 2.0 
              protected resource service =
to obtain the configuration 
            details of an 
              OAuth 2.0 authorization =
server that is capable of 
            authorizing access 
              to a specific resource =
service.  The information 
            includes the OAuth 
              2.0 component endpoint =
location URIs and as well as 
            authorization 
              server capabilities. 




            Please note that it may =
take a couple of minutes from the 
            time of submission 
            until the htmlized version =
and diff are available 
            attools.ietf.org <http://tools.ietf.org/>. 

            The IETF Secretariat 

        _____________________________=
__________________ 
        OAuth mailing list 
        OAuth@ietf.org <mailto:OAuth@ietf.org> 
        https://www.ietf.org/=
mailman/listinfo/oauth 



    _______________________________________________ 
    OAuth =
mailing list 
    OAuth@ietf.org <mailto:OAuth@ietf.org> 
    https://www.ietf.org/=
mailman/listinfo/oauth 



    _______________________________________________ 
    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






    --=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


    =

--Apple-Mail=_C08FE2D0-A615-4290-805D-0C31331E3A77--

--Apple-Mail=_134DDDDB-C4F0-4AD0-AD1C-16327E0DD7E7
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUxOTI2MThaMCMGCSqGSIb3DQEJBDEWBBT0IwVn+nXacP5Y3ayOnDr6
/cA4SDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCCm9UmxvpePQCZ3BU2TWSZnUvBVdskHwyQpP1sP1Y4bAgagIxyNLJF
4unuEdDRsr+Lv4v53gpl4S4Murb3tsmvmjeUgC8v/WSglVLbAaCdi7oZdLjD2SmVFtlqMlCc228e
TBWz0NoayBrjkl+8vM3AucNS4MSp0p5UBQPqqLZs4VDdJQQjJCjm/RR65p6rvraLprH6hONEYWxd
JlpCvclPxElFMHfLXtyaVagiKyWF2LXxrRyOvhdlNFCvFXdji/VDc8r10uJw+FdPFiCMaQ4n4B23
7fQIkbks5pkY3QD5qqxqS6hmP7c6CqCzIDf7Ba7A5TwmuCpUr9UCPrS5ZfHvAAAAAAAA
--Apple-Mail=_134DDDDB-C4F0-4AD0-AD1C-16327E0DD7E7--


From nobody Tue Mar 15 14:29:05 2016
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 A46FE12D69D for ; Tue, 15 Mar 2016 14:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.792
X-Spam-Level: 
X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, MANY_SPAN_IN_TEXT=2.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 KRlENd8adNiz for ; Tue, 15 Mar 2016 14:28:57 -0700 (PDT)
Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB1D12D812 for ; Tue, 15 Mar 2016 14:28:56 -0700 (PDT)
Received: from mtaout-aao01.mx.aol.com (mtaout-aao01.mx.aol.com [172.27.21.13]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id 174C8380013B; Tue, 15 Mar 2016 17:28:54 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aao01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id DBF0B3800009F; Tue, 15 Mar 2016 17:28:52 -0400 (EDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E87E94.4060100@aol.com>
Date: Tue, 15 Mar 2016 17:28:52 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------010605000008040605090305"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458077334; bh=7Yv/jMT7f+ydJ+zFRLh4GwZbNXxUCChsCPUXFIiqA4U=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=kcsO7F4DBh6kz6G14M/z4nIkEwa6YfOX3i83uhcfHwQlzgfYInWKNJ2rxtckTa2F6 n9RmCxugFs/L+TnwzFvxAB+j/fJcUrxxJ02rRoalxr+7gfyWD8xj4dykbQ2eiaOSLa cw5laBT7EyxP4aMpgBd32DJKEAgQvMHTX55Vvvlc=
x-aol-sid: 3039ac1b150d56e87e946e33
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 21:29:02 -0000

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


On 3/15/16 3:26 PM, John Bradley wrote:
> I think Phil and others are concerned that a developer might get bad 
> info to put in the client , some out of band discovery goes wrong or 
> the user is somehow tricked into specifying a bad resource to the client.
>
> So getting a bad resource is a touch hypothetical.
If we are really trying to solve this problem holistically, then we 
probably need to first describe the use cases we want to solve. I'm 
starting to wonder if we are all providing solutions to slightly 
different use cases.
>
> For Connect we could suppose that someone publishes a malicious 
> discovery document listing themselves as the RS but all the other 
> endpoints are at the good AS so the client registers, authorizes the 
> user and gives the AT to the bad guy.  The confused client mitigation 
> by returning client_id_and issuer from the authorization endpoint will 
> stop the attack before the token can be given to the token endpoint or RS.
Agreed and I'm fine with this solution.
>
> So protecting the AT at this point is more for a unknown attack that 
> would confuse whatever protocol/API that is using OAuth about what RS 
> to use.
Yes. This is where we need to describe some use cases (preferably real 
vs contrived) before we propose solutions. In most cases the RS 
endpoints are hard coded into the client or maybe pulled from a 
different central config endpoint (which is fixed).

That's why the only case I could think of is a client that works with 
multiple RS endpoints from different providers that server the same 
content (e.g. PortableContacts API). In this use case, the user of the 
client would need to enter the location of the RS they wanted to use and 
then the flow would start from there. In reality, most services like 
this would have a fixed set of RS's they work with and again it wouldn't 
be dynamic.
>
> In reality this is what PoP is supposed to be for.
>
> I guess the question is what short of PoP can we do to prevent the 
> client leaking tokens to bad RS that confuse it via the application 
> protocol.
>
> If we want to del with this in OAuth then we need to tell the AS where 
> the token is going to be used or tel the client where the token can be 
> used.
>
> I think letting the client tell the AS where it wants the token used 
> having the AS construct a audience out of that is probably the best 
> thing.  to get around having a pre-established relationship between 
> the AS and RS.
Even if the client tells the AS where it wants to use the token (via 
some endpoint URL), the AS still needs to have a relationship with the 
RS (at a minimum as an endpointURL-to-RS map) otherwise how can it 
determine if it is allowed to issue an access token to the user for that 
RS. This map is what I want to avoid "building" into the AS. Do we need 
"dynamic RS registration" to support this?

>
> John B.
>
>> On Mar 15, 2016, at 3:14 PM, George Fletcher > > wrote:
>>
>>
>>
>> I think Justin provided a good break down of the different aspects a 
>> client wants to specify about the requested token. (my paraphrase)
>>   1. what RS's the token will be used at
>>   2. authorization privilege requests
>>   3. token-timing adjustments
>>
>> I'm not sure passing the full endpoint to the AS will help with my 
>> concerns... The AS could potentially do a webfinger on the resource 
>> URI and determine if it's an RS that it supports... though that 
>> requires all RS's to support webfinger. What I really want to avoid 
>> is the AS having this list of URIs to RS that is almost assuredly to 
>> get out of sync.
>>
>>
>>
>> On 3/15/16 1:56 PM, John Bradley wrote:
>>> I think it is a AS policy decision if it should error or take the 
>>> requested resource and issue a token audianced for that resource.
>> Actually, the error cases are interesting. What if the passed in 
>> resource/audience doesn't actually match a requested scope? Or some 
>> match and some don't? Is it better to send back a token with less 
>> capability? or error the entire request?
>>>
>>> I guess the question is how to transition from now to a future 
>>> state.   If you cannot upgrade all the clients at once.
>>>
>>> A processing rule on the AS that allowed some clients to not send 
>>> the requested resource , but would error out for other upgraded 
>>> clients  with a "resource not allowed†oauth error would work and 
>>> not require the return of the resources.
>>>
>>> If you return the resources and let the client error if it is trying 
>>> to send to the wrong endpoint that make upgrading easier, but gives 
>>> less control to the AS.
>>>
>>> I could live with it ether way.
>>>
>>> The advantage of always sending it in the token request is that it 
>>> allows the AS to do the mapping from a resource URI to one or more 
>>> abstract audience for the token.
>> I thought Justin provided a good break down of the different aspects 
>> a client wants to specify about the requested token. (my paraphrase)
>>   1. what RS's the token will be used at
>>   2. authorization privilege requests
>>   3. token-timing adjustments
>>
>> The question is how does a client internally reference a resource 
>> server? If it's a fixed RS endpoint, then it sort of doesn't matter, 
>> the client isn't going to send the token to the wrong endpoint anyway 
>> and it can easily reference the audience by an abstract URI.
>>
>> If the client can dynamically find new RS's to interact with. How 
>> does that happen? Does the client get handed an endpoint to use? or 
>> does it do some sort of discovery to determine the endpoint? I 
>> suppose both are possible.
>>
>> Could we prescribe that the realm value of RFC 6750 error response be 
>> effectively a resource-service-id (like issuer for the AS). The 
>> client would then need to do discovery on that value to find the 
>> valid endpoints of the RS. This could be done once and the 
>> resource-service-id could be used as the "abstract" RS identifier. 
>> This requires no more discovery than adding an AS to the client.
>>>
>>> That might help address George’s concern.
>> I'm not sure passing the full endpoint to the AS will help with my 
>> concerns... The AS could potentially do a webfinger on the resource 
>> URI and determine if it's an RS that it supports... though that 
>> requires all RS's to support webfinger. What I really want to avoid 
>> is the AS having this map of URIs to RS that is almost assuredly to 
>> get out of sync.
>>>
>>> John B.
>>>
>>>
>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell 
>>>> > wrote:
>>>>
>>>> I was thinking it'd be simpler to error, if the requested 
>>>> resource(s) weren't okay. That puts the burden of checking in the 
>>>> AS. And doesn't add anything to the token or authorization 
>>>> response. I see the potential similarity to scope but not sure it's 
>>>> worth it.
>>>>
>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradleywrote:
>>>>
>>>>     If the client specifies the resource it wants the token for,
>>>>     then the meta-data would not be required unless the resources
>>>>     the token is good at are different from the request.
>>>>     Lat is the same logic as scopes.
>>>>
>>>>     For backwards compatibility if the client is happy with the
>>>>     default resources based on scopes then I think it is a good
>>>>     idea to tell the client what the resources are in the response.
>>>>
>>>>     I suspect that it is simpler with less optionality and always
>>>>     return the resources, even if they are not required.
>>>>
>>>>     John B.
>>>>
>>>>>     On Mar 15, 2016, at 12:46 PM, Brian Campbell
>>>>>      wrote:
>>>>>
>>>>>     If the client specifies the desired audience(s)/resource(s),
>>>>>     is that metadata to the client needed? The AS can audience
>>>>>     restrict the token as needed or respond with an error if it
>>>>>     can't or wont issue a token for the resource the client asked for.
>>>>>
>>>>>     On Tue, Mar 15, 2016 at 9:37 AM, John
>>>>>     Bradleywrote:
>>>>>
>>>>>         Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>
>>>>>         The AS needs to infer an audience from the scopes snd/or
>>>>>         have the client specify the desired audience.
>>>>>
>>>>>         If the AT has a audience or audiences then as long as the
>>>>>         endpoint URI are provided as meta-data with the token, the
>>>>>         client can determine if it is sending the token to the
>>>>>         correct place.
>>>>>
>>>>>         I think Phil would prefer the server rather than the
>>>>>         client do the check, but the client always needs to take
>>>>>         some responsibility to not leak tokens giving them to the
>>>>>         wrong RS or the code to the wrong token endpoint is leaking.
>>>>>
>>>>>         I imagine that claims based access tokens are going to
>>>>>         become more popular and the static relationship between
>>>>>         one RS and one AS will not be the majority of deployments
>>>>>         over time.
>>>>>
>>>>>         In any case where the client is configured up front to
>>>>>         know the RS and the AS it seems like that would not
>>>>>         require Phil’s Solution, but that is the only case
>>>>>         supported by that discovery.
>>>>>         If the client itself is bad there is not much you can do
>>>>>         to stop it from passing on the AT in way way it wants. 
>>>>>         That however is a different problem and needs claimed URI
>>>>>         or attestations to prevent client spoofing.
>>>>>         William and I are working on that in the mobile best
>>>>>         practices draft.
>>>>>
>>>>>         John B.
>>>>>
>>>>>
>>>>>>         On Mar 15, 2016, at 12:09 PM, George Fletcher
>>>>>>          wrote:
>>>>>>
>>>>>>         I worry about two directions I see in this thread...
>>>>>>
>>>>>>         1. Client's accessing resources dynamically so that
>>>>>>         discovery is required to know the correct AS, etc. This
>>>>>>         is pretty much the classic use case for UMA and I'd
>>>>>>         rather not re-invent the wheel.
>>>>>>
>>>>>>         2. Creating a tight coupling between RS and AS such that
>>>>>>         RS endpoint changes must be continually communicated to
>>>>>>         the AS. If an RS supports multiple AS's then the RS has
>>>>>>         to deal with "guaranteed" delivery. The AS needs an
>>>>>>         endpoint to receive such communications. If not dynamic
>>>>>>         via APIs, then deployment of the new RS is bound by the
>>>>>>         associated AS's getting and deploying the new endpoints.
>>>>>>         Can both endpoints of the RS be supported within the AS
>>>>>>         for some period of time, etc. This is an operation
>>>>>>         nightmare and almost assuredly going to go wrong in
>>>>>>         production.
>>>>>>
>>>>>>         Maybe an OAuth2 "audience binding" spec is what's needed
>>>>>>         for those deployments that require this. I believe that
>>>>>>         is what John Bradley is suggesting.
>>>>>>
>>>>>>         Thanks,
>>>>>>         George
>>>>>>
>>>>>>         On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>         +1, I've found the very same in OAuth deployments that I
>>>>>>>         was involved in; the hard part is to give names and
>>>>>>>         descriptions to these concepts so that they cover all
>>>>>>>         use cases and can be applied unambiguously
>>>>>>>
>>>>>>>         Hans.
>>>>>>>
>>>>>>>         On 3/14/16 10:44 PM, Justin Richer wrote:
>>>>>>>>         I agree that this is valuable, and not just for PoP. In
>>>>>>>>         all honesty,
>>>>>>>>         it’s not even really required for PoP to function in
>>>>>>>>         many cases — it’s
>>>>>>>>         just an optimization for one particular kind of key
>>>>>>>>         distribution
>>>>>>>>         mechanism in that case.
>>>>>>>>
>>>>>>>>         In the years of deployment experience with OAuth 2, I
>>>>>>>>         think we’ve really
>>>>>>>>         got three different kinds of things that currently get
>>>>>>>>         folded into
>>>>>>>>         “scope†that we might want to try separating out better:
>>>>>>>>
>>>>>>>>
>>>>>>>>         - What things do I want to access? (photos, profile)
>>>>>>>>         - What actions do I want to take on these things?
>>>>>>>>         (read, write, delete)
>>>>>>>>         - How long do I want these tokens to work?
>>>>>>>>         (offline_access/refresh_token, one time use, next hour,
>>>>>>>>         etc)
>>>>>>>>
>>>>>>>>
>>>>>>>>         I think the first one is close to the audience/resource
>>>>>>>>         parameters that
>>>>>>>>         have been bandied about a few times, including in the
>>>>>>>>         current token
>>>>>>>>         exchange document. We should be consistent across
>>>>>>>>         drafts in that regard.
>>>>>>>>         The second is more traditional scope-ish. The third has
>>>>>>>>         been patched in
>>>>>>>>         with things like “offline_access†in certain APIs.
>>>>>>>>
>>>>>>>>         Just another vector to think about if we’re going to be
>>>>>>>>         adding things
>>>>>>>>         like “audience†or “resource†or both to the token
>>>>>>>>         requests.
>>>>>>>>
>>>>>>>>         — Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>>         On Mar 14, 2016, at 6:26 PM, John Bradley
>>>>>>>>>         >>>>>>>>         > wrote:
>>>>>>>>>
>>>>>>>>>         Yes I will work on another proposal for allowing
>>>>>>>>>         clients to specify
>>>>>>>>>         what resource they want a token for and providing the
>>>>>>>>>         meta-data to the
>>>>>>>>>         client about the resources that a token is valid for.
>>>>>>>>>
>>>>>>>>>         We have part of it in the POP key distribution spec
>>>>>>>>>         and talked about
>>>>>>>>>         separating it, as it is used more places than just for
>>>>>>>>>         assigning keys.
>>>>>>>>>         I know some AS use different token formats for
>>>>>>>>>         different RS so are
>>>>>>>>>         all-ready needing to pass the resource in the request
>>>>>>>>>         to avoid making
>>>>>>>>>         a mess of scopes.
>>>>>>>>>
>>>>>>>>>         John B.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>         On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)
>>>>>>>>>>         >>>>>>>>>         > wrote:
>>>>>>>>>>
>>>>>>>>>>         Inline
>>>>>>>>>>
>>>>>>>>>>         Phil
>>>>>>>>>>
>>>>>>>>>>         On Mar 14, 2016, at 14:13, John Bradley
>>>>>>>>>>         >>>>>>>>>         > wrote:
>>>>>>>>>>
>>>>>>>>>>>         We had two mandates.  One was to provide a spec for
>>>>>>>>>>>         AS metadata.
>>>>>>>>>>>         The other was to mitigate the client mixup attack.
>>>>>>>>>>>         The request was
>>>>>>>>>>>         to do the latter without requiring the former for
>>>>>>>>>>>         clients that don’t
>>>>>>>>>>>         otherwise need discovery.
>>>>>>>>>>         There is no mandate for any of this. See
>>>>>>>>>>         http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
>>>>>>>>>>>
>>>>>>>>>>>         Returning the issuer and client_id from the
>>>>>>>>>>>         authorization endpoint
>>>>>>>>>>>         and the client checking them can be done by the
>>>>>>>>>>>         client without
>>>>>>>>>>>         discovery.
>>>>>>>>>>
>>>>>>>>>>         How does this address the issue of whether the client
>>>>>>>>>>         is talking to
>>>>>>>>>>         the wrong endpoint?
>>>>>>>>>>>
>>>>>>>>>>>         Any client that has the resource and issuer hard
>>>>>>>>>>>         coded probably
>>>>>>>>>>>         doesn’t need discovery.
>>>>>>>>>>         We agree
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>         One of the things that a client will need discovery
>>>>>>>>>>>         for is to find
>>>>>>>>>>>         the RS, so requiring the client to know the RS URI
>>>>>>>>>>>         before getting
>>>>>>>>>>>         the AS config seems backwards to me.
>>>>>>>>>>         How can you make an assumption on order? You seem to
>>>>>>>>>>         be conflating
>>>>>>>>>>         authentication with authorization by assuming the
>>>>>>>>>>         identity drives
>>>>>>>>>>         what the resource is.
>>>>>>>>>>
>>>>>>>>>>         There are lots of applications that require user
>>>>>>>>>>         rights but are not
>>>>>>>>>>         identify centric. For example a document service.
>>>>>>>>>>>
>>>>>>>>>>>         Unless the client tells the AS where it intends to
>>>>>>>>>>>         use the token we
>>>>>>>>>>>         will be leaving a security hole because the bearer
>>>>>>>>>>>         tokens will have
>>>>>>>>>>>         too loose an audience if they have one at all.
>>>>>>>>>>         This is the biggest risk we have IMHO.
>>>>>>>>>>>
>>>>>>>>>>>         True you are telling the AS (Webfinger service) what
>>>>>>>>>>>         the RS is but
>>>>>>>>>>>         that is not at a place that is useful in the token
>>>>>>>>>>>         production process.
>>>>>>>>>>
>>>>>>>>>>         This has nothing to do with token production.
>>>>>>>>>>
>>>>>>>>>>         What we want to ensure is whether an honest client is
>>>>>>>>>>         correctly
>>>>>>>>>>         configured and has not been mislead - eg by a
>>>>>>>>>>         phishing page.
>>>>>>>>>>>
>>>>>>>>>>>         I also think there are use cases where the AS
>>>>>>>>>>>         doesn’t know all the
>>>>>>>>>>>         possible RS. That is not something that a out of
>>>>>>>>>>>         band check can
>>>>>>>>>>>         address.
>>>>>>>>>>
>>>>>>>>>>         May be. Lets identify them.
>>>>>>>>>>
>>>>>>>>>>>         There are also cases where a token might be good at
>>>>>>>>>>>         multiple RS
>>>>>>>>>>>         endpoints intentionally.
>>>>>>>>>>
>>>>>>>>>>>          In your solution the client would need to make a
>>>>>>>>>>>         discovery request
>>>>>>>>>>>         for each endpoint.
>>>>>>>>>>         Sure. Otherwise how would it know if there is one AS
>>>>>>>>>>         or a pool of AS
>>>>>>>>>>         servers assigned to each instance?
>>>>>>>>>>>         Those requests lack the context of who the client
>>>>>>>>>>>         and resource owner
>>>>>>>>>>>         are.  I think that will be a problem in some use cases.
>>>>>>>>>>
>>>>>>>>>>         Not sure I agree. This is about discovering a valid
>>>>>>>>>>         set of endpoints.
>>>>>>>>>>         For mitm, we mainly want to check the hostname is
>>>>>>>>>>         correct. If a
>>>>>>>>>>         client choosesevil.com
>>>>>>>>>>         the cert can be
>>>>>>>>>>         valid and
>>>>>>>>>>         TLS will pass. How does it otherwise know it is
>>>>>>>>>>         supposed to talk to
>>>>>>>>>>         res.example.com
>>>>>>>>>>         ?
>>>>>>>>>>>
>>>>>>>>>>>         If this is added to the token endpoint it would be
>>>>>>>>>>>         checked when code
>>>>>>>>>>>         or refresh are exchanged, not every time the token
>>>>>>>>>>>         is used.
>>>>>>>>>>         Your proposal requires rhe client to check. I am not
>>>>>>>>>>         clear how the AS
>>>>>>>>>>         can know the exact uri. It is far easier to validate
>>>>>>>>>>         than to lookup
>>>>>>>>>>         since as you say the client may be authorized to use
>>>>>>>>>>         multiple ASs.
>>>>>>>>>>>         With a out of band check the client would never know
>>>>>>>>>>>         if a RS was
>>>>>>>>>>>         removed/revoked.
>>>>>>>>>>
>>>>>>>>>>         Not sure that is in scope.
>>>>>>>>>>
>>>>>>>>>>         None of the current proposals address this issue.
>>>>>>>>>>>
>>>>>>>>>>>         I don’t see checking when refreshing a token as
>>>>>>>>>>>         something that is a
>>>>>>>>>>>         huge burden.
>>>>>>>>>>
>>>>>>>>>>         Still its a lot more than once.
>>>>>>>>>>
>>>>>>>>>>         Why don't you draft another alternative?
>>>>>>>>>>>
>>>>>>>>>>>         If the server wants to do the check on it’s side
>>>>>>>>>>>         then we could
>>>>>>>>>>>         require the client to send the RS URI in the token
>>>>>>>>>>>         request. that way
>>>>>>>>>>>         you really know the client is not going to get a
>>>>>>>>>>>         token for the wrong
>>>>>>>>>>>         RS endpoint.
>>>>>>>>>>>         If you check out of band in discovery you really
>>>>>>>>>>>         have no idea if the
>>>>>>>>>>>         client is checking.
>>>>>>>>>>
>>>>>>>>>>         In the new webfinger draft, the client isn't
>>>>>>>>>>         checking. The service
>>>>>>>>>>         provider simply does not disclose oauth information
>>>>>>>>>>         to misconfigured
>>>>>>>>>>         clients.
>>>>>>>>>>>
>>>>>>>>>>>         John B.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>         On Mar 14, 2016, at 3:56 PM, Phil Hunt
>>>>>>>>>>>>         >>>>>>>>>>>         > wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>         Thanks to Mike and John for their feedback. I’ll
>>>>>>>>>>>>         take each in turn:
>>>>>>>>>>>>
>>>>>>>>>>>>         Mike,
>>>>>>>>>>>>
>>>>>>>>>>>>         Regarding your suggested amendments
>>>>>>>>>>>>
>>>>>>>>>>>>         Item 1: Returning the config URL would create two
>>>>>>>>>>>>         problems. One,it
>>>>>>>>>>>>         makes bound discovery a two-step process - that
>>>>>>>>>>>>         adds complexity.
>>>>>>>>>>>>          It seems far simpler to mandate TLS (which I think
>>>>>>>>>>>>         it already does
>>>>>>>>>>>>         in the security considerations).
>>>>>>>>>>>>
>>>>>>>>>>>>         The two-step process allows the current discovery
>>>>>>>>>>>>         process to
>>>>>>>>>>>>         continue. I disagree with this. This is why I put
>>>>>>>>>>>>         forward an
>>>>>>>>>>>>         “alternate" draft that is almost the same but
>>>>>>>>>>>>         simply adds the check
>>>>>>>>>>>>         before returning the configuration data.  I worry
>>>>>>>>>>>>         that developers
>>>>>>>>>>>>         would have no incentive to do the two-step
>>>>>>>>>>>>         approach. They would
>>>>>>>>>>>>         just start at step 2 which in turn puts AS’s at
>>>>>>>>>>>>         risk of exposing
>>>>>>>>>>>>         tokens because it works. This makes OAuth promiscuous.
>>>>>>>>>>>>
>>>>>>>>>>>>         Regarding existing implementations. Most of those
>>>>>>>>>>>>         implementations
>>>>>>>>>>>>         are for OIDC. I think it makes sense for OIDF to
>>>>>>>>>>>>         continue use of
>>>>>>>>>>>>         OIDC's discovery spec because the UserInfo endpoint
>>>>>>>>>>>>         is well defined
>>>>>>>>>>>>         and the likelihood of a client mis-informed about
>>>>>>>>>>>>         the resource
>>>>>>>>>>>>         endpoint is not there. IMO This does not apply to
>>>>>>>>>>>>         the broader
>>>>>>>>>>>>         OAuth community.
>>>>>>>>>>>>
>>>>>>>>>>>>         Item 2:  It may be appropriate to have a separate
>>>>>>>>>>>>         configuration
>>>>>>>>>>>>         registry specification, but I think we should hold
>>>>>>>>>>>>         off until we
>>>>>>>>>>>>         have a complete solution and then make the decision
>>>>>>>>>>>>         what drafts
>>>>>>>>>>>>         should exist and how many pieces.  A big concern is
>>>>>>>>>>>>         the perceived
>>>>>>>>>>>>         complexity of multiple solutions and multiple drafts.
>>>>>>>>>>>>
>>>>>>>>>>>>         As to John Bradley’s comments:
>>>>>>>>>>>>
>>>>>>>>>>>>         Re: Discovery is the wrong place to mitigate threats.
>>>>>>>>>>>>         I’m confused by this.  Our mandate was to solve a
>>>>>>>>>>>>         security threat
>>>>>>>>>>>>         by having a discovery specification to prevent
>>>>>>>>>>>>         clients being
>>>>>>>>>>>>         mis-lead about endpoints (of which resource service
>>>>>>>>>>>>         is one) in an
>>>>>>>>>>>>         oauth protected exchange. Maybe what you mean is we
>>>>>>>>>>>>         should not use
>>>>>>>>>>>>         .well-known of any kind and we should just create a
>>>>>>>>>>>>         “/Configâ€
>>>>>>>>>>>>         endpoint to OAuth?
>>>>>>>>>>>>
>>>>>>>>>>>>         Re: Your proposal for MITM mitigation
>>>>>>>>>>>>         You propose that instead the resource endpoint
>>>>>>>>>>>>         check should be in
>>>>>>>>>>>>         the oauth protocol itself.  The difference is that
>>>>>>>>>>>>         validation is
>>>>>>>>>>>>         transferred back to the client to get it right. As
>>>>>>>>>>>>         well, without
>>>>>>>>>>>>         the client informing the AS, I can’t see a way for
>>>>>>>>>>>>         the AS to know
>>>>>>>>>>>>         what endpoint the client is using.  The webfinger
>>>>>>>>>>>>         approach does
>>>>>>>>>>>>         this once and only requires that the host name be
>>>>>>>>>>>>         checked in many
>>>>>>>>>>>>         cases.
>>>>>>>>>>>>
>>>>>>>>>>>>         As a principle, the members have discussed many
>>>>>>>>>>>>         times that the AS
>>>>>>>>>>>>         service should do validation when possible — this
>>>>>>>>>>>>         was particularly
>>>>>>>>>>>>         true at the Germany meeting when this came up. This
>>>>>>>>>>>>         is why I prefer
>>>>>>>>>>>>         the client tell the service provider what it
>>>>>>>>>>>>         intends to do and the
>>>>>>>>>>>>         service provider can fail that request immediately
>>>>>>>>>>>>         if necessary. We
>>>>>>>>>>>>         don’t have to depend on the developer getting the
>>>>>>>>>>>>         spec correct to
>>>>>>>>>>>>         fail the correct way.
>>>>>>>>>>>>
>>>>>>>>>>>>         I worry that adding more parameters to the authz
>>>>>>>>>>>>         and token protocol
>>>>>>>>>>>>         flows increases complexity and attack surface. It
>>>>>>>>>>>>         also means per
>>>>>>>>>>>>         authorization validation has to take place vs. a
>>>>>>>>>>>>         one-time
>>>>>>>>>>>>         validation at config time. Placing it in the
>>>>>>>>>>>>         configuration lookup
>>>>>>>>>>>>         phase (whether via web finger or just a special
>>>>>>>>>>>>         OAuth endpoint)
>>>>>>>>>>>>         seems more appropriate and far less complex - as
>>>>>>>>>>>>         the request itself
>>>>>>>>>>>>         is simple and has only one parameter. Here we are
>>>>>>>>>>>>         not considered
>>>>>>>>>>>>         about legitimacy of the client. we’re just
>>>>>>>>>>>>         concerned with the issue
>>>>>>>>>>>>         "has the client been correctly informed?â€
>>>>>>>>>>>>
>>>>>>>>>>>>         That said, it may be that when we consider all the
>>>>>>>>>>>>         use cases, some
>>>>>>>>>>>>         combination of AS protocol and discovery may be
>>>>>>>>>>>>         both needed. I’m
>>>>>>>>>>>>         not ready to make conclusions about this. The current
>>>>>>>>>>>>         oauth-discovery spec seems to put future generic
>>>>>>>>>>>>         clients at risk
>>>>>>>>>>>>         and that is my primary concern.
>>>>>>>>>>>>
>>>>>>>>>>>>         Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>>         Phil
>>>>>>>>>>>>
>>>>>>>>>>>>         @independentid
>>>>>>>>>>>>         www.independentid.com
>>>>>>>>>>>>         phil.hunt@oracle.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>         On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>>>>>>         >
>>>>>>>>>>>>>         wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Thanks for posting this, Phil.  It provides a
>>>>>>>>>>>>>         concrete example of
>>>>>>>>>>>>>         a way that protected resource discovery could be
>>>>>>>>>>>>>         added to
>>>>>>>>>>>>>         authorization server metadata discovery, and as
>>>>>>>>>>>>>         such, should
>>>>>>>>>>>>>         provide useful input for working group discussions
>>>>>>>>>>>>>         on this topic.
>>>>>>>>>>>>>         It’s always great when someone takes the time to
>>>>>>>>>>>>>         write an actual
>>>>>>>>>>>>>         draft that can be examined and implemented, and I
>>>>>>>>>>>>>         appreciate you
>>>>>>>>>>>>>         doing that.
>>>>>>>>>>>>>         The content of your draft points out that there
>>>>>>>>>>>>>         appears to be
>>>>>>>>>>>>>         complete agreement on what the authorization
>>>>>>>>>>>>>         server metadata
>>>>>>>>>>>>>         format should be, which is great!  I’ll note that
>>>>>>>>>>>>>         Section 3 of
>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00 titled
>>>>>>>>>>>>>         “Authorization Server
>>>>>>>>>>>>>         Metadata†is an exact copy of Section 2 of
>>>>>>>>>>>>>         draft-ietf-oauth-discovery-01 (with the same
>>>>>>>>>>>>>         title), modulo
>>>>>>>>>>>>>         applying a correction suggested by the working
>>>>>>>>>>>>>         group.  To me this
>>>>>>>>>>>>>         suggests that the authorization server metadata
>>>>>>>>>>>>>         definitions in
>>>>>>>>>>>>>         draft-ietf-oauth-discovery (which is now the whole
>>>>>>>>>>>>>         normative
>>>>>>>>>>>>>         content of the draft) are clearly ready for
>>>>>>>>>>>>>         standardization, since
>>>>>>>>>>>>>         even your alternative proposal includes them verbatim.
>>>>>>>>>>>>>         Reading your draft, the problem I have with it is
>>>>>>>>>>>>>         that you are
>>>>>>>>>>>>>         returning the AS metadata only as a WebFinger
>>>>>>>>>>>>>         response, rather
>>>>>>>>>>>>>         than as an https-protected resource published by
>>>>>>>>>>>>>         the authorization
>>>>>>>>>>>>>         server.  The choice to only return this via
>>>>>>>>>>>>>         WebFinger makes your
>>>>>>>>>>>>>         draft incompatible with most deployed
>>>>>>>>>>>>>         implementations of OAuth
>>>>>>>>>>>>>         metadata, including the 22 implementations using
>>>>>>>>>>>>>         it listed
>>>>>>>>>>>>>         athttp://openid.net/certification/(see the “OP
>>>>>>>>>>>>>         Config†column in
>>>>>>>>>>>>>         the table) andOAuth 2.0 libraries such as
>>>>>>>>>>>>>         Microsoft’s “ADALâ€
>>>>>>>>>>>>>         library, which uses the metadata path for client
>>>>>>>>>>>>>         configuration.
>>>>>>>>>>>>>         Without having ASs provide the metadata as an
>>>>>>>>>>>>>         https-protected
>>>>>>>>>>>>>         resource, implementations such as ADAL can’t use
>>>>>>>>>>>>>         it for client
>>>>>>>>>>>>>         configuration as the currently do.
>>>>>>>>>>>>>         Therefore, I would request that you make these
>>>>>>>>>>>>>         minor revisions to
>>>>>>>>>>>>>         your draft and republish, so as to provide a
>>>>>>>>>>>>>         unified way forward
>>>>>>>>>>>>>         that is compatible with all known existing OAuth
>>>>>>>>>>>>>         Discovery
>>>>>>>>>>>>>         deployments:
>>>>>>>>>>>>>         1.Modify your section 2 “Authorization Server
>>>>>>>>>>>>>         WebFinger Discoveryâ€
>>>>>>>>>>>>>         to have the WebFinger request return the issuer
>>>>>>>>>>>>>         identifier for the
>>>>>>>>>>>>>         AS as the “WebFinger “rel†value, rather than
>>>>>>>>>>>>>         returning the
>>>>>>>>>>>>>         metadata values by value as the “properties†value.
>>>>>>>>>>>>>         2.Reference the metadata definitions from Section 2 of
>>>>>>>>>>>>>         draft-ietf-oauth-discovery, rather than
>>>>>>>>>>>>>         duplicating them in your
>>>>>>>>>>>>>         Section 3.
>>>>>>>>>>>>>         That would have the advantage of paring your draft
>>>>>>>>>>>>>         down to only
>>>>>>>>>>>>>         the new things that it proposes, enabling them to
>>>>>>>>>>>>>         be more clearly
>>>>>>>>>>>>>         understood and evaluated on their own merits.  I
>>>>>>>>>>>>>         look forward to
>>>>>>>>>>>>>         the discussions of ways of performing additional
>>>>>>>>>>>>>         kinds of OAuth
>>>>>>>>>>>>>         discovery, and consider your draft a valuable
>>>>>>>>>>>>>         input to those
>>>>>>>>>>>>>         discussions.
>>>>>>>>>>>>>         Best wishes,
>>>>>>>>>>>>>         -- Mike
>>>>>>>>>>>>>         *From:*OAuth [mailto:oauth-bounces@ietf.org]*On
>>>>>>>>>>>>>         Behalf Of*John Bradley
>>>>>>>>>>>>>         *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>>>>>>         *To:*Phil Hunt
>>>>>>>>>>>>>         >
>>>>>>>>>>>>>         *Cc:*oauth >
>>>>>>>>>>>>>         *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>>>         As I have told Phil off list.
>>>>>>>>>>>>>         Discovery is the wrong place to try and provide
>>>>>>>>>>>>>         security against
>>>>>>>>>>>>>         man in the middle attacks on the RS.
>>>>>>>>>>>>>         This requires the client to know what the RS URI
>>>>>>>>>>>>>         is before
>>>>>>>>>>>>>         retrieving the information on the AS Configuration.
>>>>>>>>>>>>>         The proposal Mike and I have been working on
>>>>>>>>>>>>>         requires the client
>>>>>>>>>>>>>         to have a notion of what API it is looking for and
>>>>>>>>>>>>>         retrieve the
>>>>>>>>>>>>>         .well-known file for that API from the issuer.  
>>>>>>>>>>>>>         That allows a
>>>>>>>>>>>>>         protocol like Connect to register its own config
>>>>>>>>>>>>>         file that can
>>>>>>>>>>>>>         point to the RS.
>>>>>>>>>>>>>         If the API specific well known is not available
>>>>>>>>>>>>>         the client can try
>>>>>>>>>>>>>         the default oauth-server one.
>>>>>>>>>>>>>         That then allows us to deal with restricting where
>>>>>>>>>>>>>         AT are
>>>>>>>>>>>>>         presented as part of the protocol rather then
>>>>>>>>>>>>>         dragging discovery
>>>>>>>>>>>>>         in as a requirement.
>>>>>>>>>>>>>         In my opinion the resource the token is targeted
>>>>>>>>>>>>>         to should be
>>>>>>>>>>>>>         separated from the scope and returned as part of
>>>>>>>>>>>>>         the meta-data
>>>>>>>>>>>>>         about the AT along with scopes granted and expiry
>>>>>>>>>>>>>         time.   We
>>>>>>>>>>>>>         should also have a input parameter for resources
>>>>>>>>>>>>>         so that a client
>>>>>>>>>>>>>         can restrict tokens issued to a subset of the ones
>>>>>>>>>>>>>         granted by the
>>>>>>>>>>>>>         refresh token.   It would then also be possible to
>>>>>>>>>>>>>         ask a AS for a
>>>>>>>>>>>>>         token for a unregistered RS and have the AS
>>>>>>>>>>>>>         produce a JWT access
>>>>>>>>>>>>>         token with the resource as an audience if policy
>>>>>>>>>>>>>         allows.
>>>>>>>>>>>>>         That however was supposed to be dealt with as part
>>>>>>>>>>>>>         of the mixed up
>>>>>>>>>>>>>         client set of mitigations.
>>>>>>>>>>>>>         In that the goal was to mitigate the attacks by
>>>>>>>>>>>>>         returning
>>>>>>>>>>>>>         meta-data about the tokens, and not to require
>>>>>>>>>>>>>         discovery.
>>>>>>>>>>>>>         We intend to return “iss†and “cleint_id†for the
>>>>>>>>>>>>>         code, and I
>>>>>>>>>>>>>         intend to discuss at the F2F returning resource
>>>>>>>>>>>>>         for AT as well.
>>>>>>>>>>>>>         Those mitigate the attack.
>>>>>>>>>>>>>         I will continue to resist mixing up discovery of
>>>>>>>>>>>>>         configuration
>>>>>>>>>>>>>         meta-data with mitigation of the attacks.
>>>>>>>>>>>>>         We return meta-data about the tokens now, because
>>>>>>>>>>>>>         AT are opaque to
>>>>>>>>>>>>>         the client, we neglected to include some of the
>>>>>>>>>>>>>         information for
>>>>>>>>>>>>>         the client needs to be secure.   We just need to
>>>>>>>>>>>>>         add that in to
>>>>>>>>>>>>>         the existing flows.
>>>>>>>>>>>>>         While Phil’s proposal is easier for the AS to
>>>>>>>>>>>>>         implement as an add
>>>>>>>>>>>>>         on, it puts more of a burden on the client needing
>>>>>>>>>>>>>         to potentially
>>>>>>>>>>>>>         change how it stores the relationships between AS
>>>>>>>>>>>>>         and RS to
>>>>>>>>>>>>>         prevent compromise, I think the solution should be
>>>>>>>>>>>>>         biased towards
>>>>>>>>>>>>>         simplicity on the client side.
>>>>>>>>>>>>>         If we return the resources as part of the existing
>>>>>>>>>>>>>         meta data the
>>>>>>>>>>>>>         client checks that against the resource it intends
>>>>>>>>>>>>>         to send the
>>>>>>>>>>>>>         token to and if it is not in the list then it
>>>>>>>>>>>>>         can’t send the
>>>>>>>>>>>>>         token.  Simple check every time it gets a new AT,
>>>>>>>>>>>>>         no optionality.
>>>>>>>>>>>>>         I am not saying anything new Nat has been
>>>>>>>>>>>>>         advocating basically
>>>>>>>>>>>>>         this for some time, and dis submit a draft.   I
>>>>>>>>>>>>>         prefer to return
>>>>>>>>>>>>>         the info in the existing format rather than as
>>>>>>>>>>>>>         link headers,  but
>>>>>>>>>>>>>         that is the largest difference between what Nat
>>>>>>>>>>>>>         and I are saying
>>>>>>>>>>>>>         with respect to resource.
>>>>>>>>>>>>>         That is the core of my problem with Phil’s draft.
>>>>>>>>>>>>>         I guess we will need to have a long conversation
>>>>>>>>>>>>>         in BA.
>>>>>>>>>>>>>         Regards
>>>>>>>>>>>>>         John B.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         On Mar 13, 2016, at 8:12 PM, Phil Hunt
>>>>>>>>>>>>>         >>>>>>>>>>>>         > wrote:
>>>>>>>>>>>>>         This draft is a proposed alternate proposal for
>>>>>>>>>>>>>         draft-ietf-oauth-discovery. As such, it contains
>>>>>>>>>>>>>         the same
>>>>>>>>>>>>>         registry for OAuth Config Metadata as the authors
>>>>>>>>>>>>>         believe that
>>>>>>>>>>>>>         both solutions are not required, or depending on
>>>>>>>>>>>>>         WG discussion
>>>>>>>>>>>>>         they will be merged. The intent is to provide a simple
>>>>>>>>>>>>>         complete draft for consideration.
>>>>>>>>>>>>>         How it works...
>>>>>>>>>>>>>         Given that a client has previously discovered an OAuth
>>>>>>>>>>>>>         protected resource, the bound configuration method
>>>>>>>>>>>>>         allows a
>>>>>>>>>>>>>         client to return the configuration for an oauth
>>>>>>>>>>>>>         authorization
>>>>>>>>>>>>>         server that can issue tokens for the resource URI
>>>>>>>>>>>>>         specified by
>>>>>>>>>>>>>         the client.  The AS is not required to be in the
>>>>>>>>>>>>>         same domain.
>>>>>>>>>>>>>         The AS is however required to know if it can issue
>>>>>>>>>>>>>         tokens for
>>>>>>>>>>>>>         a resource service (which presumes some agreement
>>>>>>>>>>>>>         exists on
>>>>>>>>>>>>>         tokens etc).
>>>>>>>>>>>>>         The draft does not require that the resource exist
>>>>>>>>>>>>>         (e.g. for
>>>>>>>>>>>>>         unconfigured or new user based resources). It only
>>>>>>>>>>>>>         requires
>>>>>>>>>>>>>         that the AS service provider agrees it can issue
>>>>>>>>>>>>>         tokens.
>>>>>>>>>>>>>         From a security perspective, returning the OAuth
>>>>>>>>>>>>>         service
>>>>>>>>>>>>>         configuration for a specified resource URI serves
>>>>>>>>>>>>>         to confirm
>>>>>>>>>>>>>         the client is in possession of a valid resource
>>>>>>>>>>>>>         URI ensuring
>>>>>>>>>>>>>         the client has received a valid set of endpoints
>>>>>>>>>>>>>         for the
>>>>>>>>>>>>>         resource and the associated oauth services.
>>>>>>>>>>>>>         I propose that the WG consider the alternate draft
>>>>>>>>>>>>>         carefully
>>>>>>>>>>>>>         as well as other submissions and evaluate the broader
>>>>>>>>>>>>>         discovery problem before proceeding with WGLC on
>>>>>>>>>>>>>         OAuth Discovery.
>>>>>>>>>>>>>         Thanks!
>>>>>>>>>>>>>         Phil
>>>>>>>>>>>>>         @independentid
>>>>>>>>>>>>>         www.independentid.com
>>>>>>>>>>>>>         phil.hunt@oracle.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Begin forwarded message:
>>>>>>>>>>>>>         *From:*internet-drafts@ietf.org
>>>>>>>>>>>>>         
>>>>>>>>>>>>>         *Subject: New Version Notification for
>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*
>>>>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>>>>>>         >, "Anthony Nadalin"
>>>>>>>>>>>>>         >,
>>>>>>>>>>>>>         "Tony Nadalin" >>>>>>>>>>>>         >
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>         A new version of I-D,
>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>>>         has been successfully submitted by Phil Hunt and
>>>>>>>>>>>>>         posted to the
>>>>>>>>>>>>>         IETF repository.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>>>>>>>>         Revision:00
>>>>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>>>>>>>         Document date:2016-03-13
>>>>>>>>>>>>>         Group:Individual Submission
>>>>>>>>>>>>>         Pages:22
>>>>>>>>>>>>>         URL:
>>>>>>>>>>>>>         https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>>>         Status:
>>>>>>>>>>>>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>>>>>>>         Htmlized:
>>>>>>>>>>>>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Abstract:
>>>>>>>>>>>>>         This specification defines a mechanism for the
>>>>>>>>>>>>>         client of
>>>>>>>>>>>>>         an OAuth 2.0
>>>>>>>>>>>>>         protected resource service to obtain the configuration
>>>>>>>>>>>>>         details of an
>>>>>>>>>>>>>         OAuth 2.0 authorization server that is capable of
>>>>>>>>>>>>>         authorizing access
>>>>>>>>>>>>>         to a specific resource service. The information
>>>>>>>>>>>>>         includes the OAuth
>>>>>>>>>>>>>         2.0 component endpoint location URIs and as well as
>>>>>>>>>>>>>         authorization
>>>>>>>>>>>>>         server capabilities.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Please note that it may take a couple of minutes
>>>>>>>>>>>>>         from the
>>>>>>>>>>>>>         time of submission
>>>>>>>>>>>>>         until the htmlized version and diff are available
>>>>>>>>>>>>>         attools.ietf.org
>>>>>>>>>>>>>         .
>>>>>>>>>>>>>
>>>>>>>>>>>>>         The IETF Secretariat
>>>>>>>>>>>>>
>>>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>>>         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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         _______________________________________________
>>>>>>>>         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
>>>>>
>>>>>
>>>>
>>>>
>>>


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


  
    
  
  
    
    
    
    On 3/15/16 3:26 PM, John Bradley wrote:
    
    
    
    
    
      
      I think Phil and others are concerned that a developer might get
      bad info to put in the client , some out of band discovery goes
      wrong or the user is somehow tricked into specifying a bad
      resource to the client.
      

    
      
    
      
    So getting a bad resource is a touch hypothetical. 
    
      
    
    
    
    If we are really trying to solve this problem holistically, then we
    probably need to first describe the use cases we want to solve. I'm
    starting to wonder if we are all providing solutions to slightly
    different use cases.
    
    
    
      

    
      
    
      
    For Connect we could suppose that someone publishes
        a malicious discovery document listing themselves as the RS but
        all the other endpoints are at the good AS so the client
        registers, authorizes the user and gives the AT to the bad guy.
         The confused client mitigation by returning client_id_and
        issuer from the authorization endpoint will stop the attack
        before the token can be given to the token endpoint or RS.
    
    
    
    Agreed and I'm fine with this solution.
    
    
    
      

    
      
    
      
    So protecting the AT at this point is more for a
        unknown attack that would confuse whatever protocol/API that is
        using OAuth about what RS to use.
    
    
    
    Yes. This is where we need to describe some use cases (preferably
    real vs contrived) before we propose solutions. In most cases the RS
    endpoints are hard coded into the client or maybe pulled from a
    different central config endpoint (which is fixed).
    
    
    
    That's why the only case I could think of is a client that works
    with multiple RS endpoints from different providers that server the
    same content (e.g. PortableContacts API). In this use case, the user
    of the client would need to enter the location of the RS they wanted
    to use and then the flow would start from there. In reality, most
    services like this would have a fixed set of RS's they work with and
    again it wouldn't be dynamic.
    
    
    
      

    
      
    
      
    In reality this is what PoP is supposed to be for.
    
      

    
      
    
      
    I guess the question is what short of PoP can we do
        to prevent the client leaking tokens to bad RS that confuse it
        via the application protocol.
    
      

    
      
    
      
    If we want to del with this in OAuth then we need to
        tell the AS where the token is going to be used or tel the
        client where the token can be used. 
    
      

    
      
    
      
    I think letting the client tell the AS where it
        wants the token used having the AS construct a audience out of
        that is probably the best thing.  to get around having a
        pre-established relationship between the AS and RS.
    
    
    
    Even if the client tells the AS where it wants to use the token (via
    some endpoint URL), the AS still needs to have a relationship with
    the RS (at a minimum as an endpointURL-to-RS map) otherwise how can
    it determine if it is allowed to issue an access token to the user
    for that RS. This map is what I want to avoid "building" into the
    AS. Do we need "dynamic RS registration" to support this?
    
    
    
    
    
      

    
      
    
      
    John B.
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 3:14 PM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            

    
                
    
                I think Justin provided a good break down of the
                different aspects a client wants to specify about the
                requested token. (my paraphrase)
    
                  1. what RS's the token will be used at
    
                  2. authorization privilege requests
    
                  3. token-timing adjustments
    
                
    
                I'm not sure passing the full endpoint to the AS will
                help with my concerns... The AS could potentially do a
                webfinger on the resource URI and determine if it's an
                RS that it supports... though that requires all RS's to
                support webfinger. What I really want to avoid is the AS
                having this list of URIs to RS that is almost assuredly
                to get out of sync.
    
                
    
                
    
              
    
              
    On 3/15/16 1:56 PM, John Bradley
                wrote:
    
              
    
              
    I think
                it is a AS policy decision if it should error or take
                the requested resource and issue a token audianced for
                that resource.
    
              Actually, the error cases are interesting.
                What if the passed in resource/audience doesn't actually
                match a requested scope? Or some match and some don't?
                Is it better to send back a token with less capability?
                or error the entire request?
              
    
                

    
                
    
                
    I guess the question is how to transition
                  from now to a future state.   If you cannot upgrade
                  all the clients at once.
    
                

    
                
    
                
    A processing rule on the AS that allowed
                  some clients to not send the requested resource , but
                  would error out for other upgraded clients  with a
                  "resource not allowed†oauth error would work and not
                  require the return of the resources.  
    
                

    
                
    
                
    If you return the resources and let the
                  client error if it is trying to send to the wrong
                  endpoint that make upgrading easier, but gives less
                  control to the AS.
    
                

    
                
    
                
    
                  
    
                    
    I could live with it
                        ether way.
    
                    

    
                    
    
                    The advantage of always sending it in the token
                    request is that it allows the AS to do the mapping
                    from a resource URI to one or more abstract audience
                    for the token.
    
                
    
              
    
              I thought Justin provided a good break down
                of the different aspects a client wants to specify about
                the requested token. (my paraphrase)
    
                  1. what RS's the token will be used at
    
                  2. authorization privilege requests
    
                  3. token-timing adjustments
    
                
    
                The question is how does a client internally reference a
                resource server? If it's a fixed RS endpoint, then it
                sort of doesn't matter, the client isn't going to send
                the token to the wrong endpoint anyway and it can easily
                reference the audience by an abstract URI.
    
                
    
                If the client can dynamically find new RS's to interact
                with. How does that happen? Does the client get handed
                an endpoint to use? or does it do some sort of discovery
                to determine the endpoint? I suppose both are possible.
    
                
    
                Could we prescribe that the realm value of RFC 6750
                error response be effectively a resource-service-id
                (like issuer for the AS). The client would then need to
                do discovery on that value to find the valid endpoints
                of the RS. This could be done once and the
                resource-service-id could be used as the "abstract" RS
                identifier. This requires no more discovery than adding
                an AS to the client.
    
                  
              
    
                
    
                  

    
                  
    
                  
    That might help address George’s
                    concern.
    
                
    
              
    
              I'm not sure passing the full endpoint to
                the AS will help with my concerns... The AS could
                potentially do a webfinger on the resource URI and
                determine if it's an RS that it supports... though that
                requires all RS's to support webfinger. What I really
                want to avoid is the AS having this map of URIs to RS
                that is almost assuredly to get out of sync.
              
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                  
    
                  

    
                    
    
                      
    On Mar 15, 2016, at 2:44 PM, Brian
                        Campbell <bcampbell@pingidentity.com>
                        wrote:
    
                      
    
                      
    
                        
    I was thinking it'd be
                          simpler to error, if the requested resource(s)
                          weren't okay. That puts the burden of checking
                          in the AS. And doesn't add anything to the
                          token or authorization response. I see the
                          potential similarity to scope but not sure
                          it's worth it.    
    
                        

    
                          
    On Tue, Mar 15, 2016
                            at 11:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    
                            
    
                              
    If the client specifies the
                                resource it wants the token for, then
                                the meta-data would not be required
                                unless the resources the token is good
                                at are different from the request.  
                                
    Lat is the same logic as
                                  scopes.
    
                                

    
                                
    
                                
    For backwards
                                  compatibility if the client is happy
                                  with the default resources based on
                                  scopes then I think it is a good idea
                                  to tell the client what the resources
                                  are in the response.
    
                                

    
                                
    
                                
    I suspect that it is
                                  simpler with less optionality and
                                  always return the resources, even if
                                  they are not required.
    
                                

    
                                
    
                                
    John B.
    
                                
    
                                  
    
                                    

    
                                    
    
                                    
    
                                      
    
                                        
    
                                          
    On Mar 15, 2016,
                                            at 12:46 PM, Brian Campbell
                                            <bcampbell@pingidentity.com>
                                            wrote:
    
                                          
    
                                          
    
                                            
    If
                                              the client specifies the
                                              desired
                                              audience(s)/resource(s),
                                              is that metadata to the
                                              client needed? The AS can
                                              audience restrict the
                                              token as needed or respond
                                              with an error if it can't
                                              or wont issue a token for
                                              the resource the client
                                              asked for. 
    
                                              
    
                                                
    
                                                  

    
                                                    
    On
                                                      Tue, Mar 15, 2016
                                                      at 9:37 AM, John
                                                      Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                                      
    
                                                        
    Yes,
                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The
                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          audience.
    
                                                          

    
                                                          
    
                                                          
    If
                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time. 
    
                                                          

    
                                                          
    
                                                          
    In
                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil’s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
      
    
                                                          
    If
                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.  That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    William
                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John
                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>
                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On
                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously 
    
                                                          
    
                                                          Hans. 
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: 
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty, 
    
                                                          it’s not even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases —
                                                          it’s 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution 
    
                                                          mechanism in
                                                          that case. 
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we’ve
                                                          really 
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into 
    
                                                          “scope†that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: 
    
                                                          
    
                                                          
    
                                                            -
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile) 
    
                                                            -
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete) 
    
                                                            -
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? 
    
                                                          (offline_access/refresh_token,
                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token 
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. 
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in 
    
                                                          with things
                                                          like
                                                          “offline_accessâ€
                                                          in certain
                                                          APIs. 
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we’re going to
                                                          be adding
                                                          things 
    
                                                          like
                                                          “audience†or
                                                          “resource†or
                                                          both to the
                                                          token
                                                          requests. 
    
                                                          
    
                                                            —
                                                          Justin 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>
                                                          wrote: 
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify 
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. 
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are 
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making 
    
                                                          a mess of
                                                          scopes. 
    
                                                          
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                          
    
                                                          Inline 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>
                                                          wrote: 
    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.  One
                                                          was to provide
                                                          a spec for AS
                                                          metadata. 
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack. 
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don’t 
    
                                                          otherwise need
                                                          discovery. 
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint 
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without 
    
                                                          discovery. 
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to 
    
                                                          the wrong
                                                          endpoint? 
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably 
    
                                                          doesn’t need
                                                          discovery. 
    
                                                          
    
                                                          We agree 
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find 
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating 
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives 
    
                                                          what the
                                                          resource is. 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not 
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service. 
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have 
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. 
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process. 
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production. 
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. 
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn’t
                                                          know all the 
    
                                                          possible RS.  
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can 
    
                                                          address. 
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them. 
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS 
    
                                                          endpoints
                                                          intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request 
    
                                                          for each
                                                          endpoint. 
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS 
    
                                                          servers
                                                          assigned to
                                                          each instance? 
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner 
    
                                                          are.  I think
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. 
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints. 
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a 
    
                                                          client chooses evil.com <http://evil.com/> the cert can be valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to 
    
                                                          res.example.com <http://res.example.com/>? 
    
                                                          

    
                                                          If this is
                                                          added to the
                                                          token endpoint
                                                          it would be
                                                          checked when
                                                          code 
    
                                                          or refresh are
                                                          exchanged, not
                                                          every time the
                                                          token is used. 
    
                                                          
    
                                                          Your proposal
                                                          requires rhe
                                                          client to
                                                          check. I am
                                                          not clear how
                                                          the AS 
    
                                                          can know the
                                                          exact uri. It
                                                          is far easier
                                                          to validate
                                                          than to lookup 
    
                                                          since as you
                                                          say the client
                                                          may be
                                                          authorized to
                                                          use multiple
                                                          ASs. 
    
                                                          
    With
                                                          a out of band
                                                          check the
                                                          client would
                                                          never know if
                                                          a RS was 
    
removed/revoked. 
    
                                                          
    
                                                          
    
                                                          Not sure that
                                                          is in scope. 
    
                                                          
    
                                                          None of the
                                                          current
                                                          proposals
                                                          address this
                                                          issue. 
    
                                                          

    
                                                          I don’t see
                                                          checking when
                                                          refreshing a
                                                          token as
                                                          something that
                                                          is a 
    
                                                          huge burden. 
    
                                                          
    
                                                          
    
                                                          Still its a
                                                          lot more than
                                                          once. 
    
                                                          
    
                                                          Why don't you
                                                          draft another
                                                          alternative? 
    
                                                          

    
                                                          If the server
                                                          wants to do
                                                          the check on
                                                          it’s side then
                                                          we could 
    
                                                          require the
                                                          client to send
                                                          the RS URI in
                                                          the token
                                                          request. that
                                                          way 
    
                                                          you really
                                                          know the
                                                          client is not
                                                          going to get a
                                                          token for the
                                                          wrong 
    
                                                          RS endpoint. 
    
                                                          If you check
                                                          out of band in
                                                          discovery you
                                                          really have no
                                                          idea if the 
    
                                                          client is
                                                          checking. 
    
                                                          
    
                                                          
    
                                                          In the new
                                                          webfinger
                                                          draft, the
                                                          client isn't
                                                          checking. The
                                                          service 
    
                                                          provider
                                                          simply does
                                                          not disclose
                                                          oauth
                                                          information to
                                                          misconfigured 
    
                                                          clients. 
    
                                                          

    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 3:56 PM,
                                                          Phil Hunt <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                          
    
                                                          Thanks to Mike
                                                          and John for
                                                          their
                                                          feedback. 
                                                          I’ll take each
                                                          in turn: 
    
                                                          
    
                                                          Mike, 
    
                                                          
    
                                                          Regarding your
                                                          suggested
                                                          amendments 
    
                                                          
    
                                                          Item 1:
                                                          Returning the
                                                          config URL
                                                          would create
                                                          two problems.
                                                          One,it 
    
                                                          makes bound
                                                          discovery a
                                                          two-step
                                                          process - that
                                                          adds
                                                          complexity. 
    
                                                           It seems far
                                                          simpler to
                                                          mandate TLS
                                                          (which I think
                                                          it already
                                                          does 
    
                                                          in the
                                                          security
                                                          considerations). 
    
                                                          
    
                                                          The two-step
                                                          process allows
                                                          the current
                                                          discovery
                                                          process to 
    
                                                          continue. I
                                                          disagree with
                                                          this. This is
                                                          why I put
                                                          forward an 
    
                                                          “alternate"
                                                          draft that is
                                                          almost the
                                                          same but
                                                          simply adds
                                                          the check 
    
                                                          before
                                                          returning the
                                                          configuration
                                                          data.  I worry
                                                          that 
                                                          developers 
    
                                                          would have no
                                                          incentive to
                                                          do the
                                                          two-step
                                                          approach. They
                                                          would 
    
                                                          just start at
                                                          step 2 which
                                                          in turn puts
                                                          AS’s at risk
                                                          of exposing 
    
                                                          tokens because
                                                          it works. This
                                                          makes OAuth
                                                          promiscuous. 
    
                                                          
    
                                                          Regarding
                                                          existing
                                                          implementations.
                                                          Most of those
implementations 
    
                                                          are for OIDC. 
                                                          I think it
                                                          makes sense
                                                          for OIDF to
                                                          continue use
                                                          of 
    
                                                          OIDC's
                                                          discovery spec
                                                          because the
                                                          UserInfo
                                                          endpoint is
                                                          well defined 
    
                                                          and the
                                                          likelihood of
                                                          a client
                                                          mis-informed
                                                          about the
                                                          resource 
    
                                                          endpoint is
                                                          not there. 
                                                          IMO This does
                                                          not apply to
                                                          the broader 
    
                                                          OAuth
                                                          community. 
    
                                                          
    
                                                          Item 2:  It
                                                          may be
                                                          appropriate to
                                                          have a
                                                          separate
                                                          configuration 
    
                                                          registry
                                                          specification,
                                                          but I think we
                                                          should hold
                                                          off until we 
    
                                                          have a
                                                          complete
                                                          solution and
                                                          then make the
                                                          decision what
                                                          drafts 
    
                                                          should exist
                                                          and how many
                                                          pieces.  A big
                                                          concern is the
                                                          perceived 
    
                                                          complexity of
                                                          multiple
                                                          solutions and
                                                          multiple
                                                          drafts. 
    
                                                          
    
                                                          As to John
                                                          Bradley’s
                                                          comments: 
    
                                                          
    
                                                          Re: Discovery
                                                          is the wrong
                                                          place to
                                                          mitigate
                                                          threats. 
    
                                                          I’m confused
                                                          by this.  Our
                                                          mandate was to
                                                          solve a
                                                          security
                                                          threat 
    
                                                          by having a
                                                          discovery
                                                          specification
                                                          to prevent
                                                          clients being 
    
                                                          mis-lead about
                                                          endpoints (of
                                                          which resource
                                                          service is
                                                          one) in an 
    
                                                          oauth
                                                          protected
                                                          exchange. 
                                                          Maybe what you
                                                          mean is we
                                                          should not use 
    
                                                          .well-known of
                                                          any kind and
                                                          we should just
                                                          create a
                                                          “/Configâ€Â 
    
                                                          endpoint to
                                                          OAuth? 
    
                                                          
    
                                                          Re: Your
                                                          proposal for
                                                          MITM
                                                          mitigation 
    
                                                          You propose
                                                          that instead
                                                          the resource
                                                          endpoint check
                                                          should be in 
    
                                                          the oauth
                                                          protocol
                                                          itself.  The
                                                          difference is
                                                          that
                                                          validation is 
    
                                                          transferred
                                                          back to the
                                                          client to get
                                                          it right. As
                                                          well, without 
    
                                                          the client
                                                          informing the
                                                          AS, I can’t
                                                          see a way for
                                                          the AS to know 
    
                                                          what endpoint
                                                          the client is
                                                          using.  The
                                                          webfinger
                                                          approach does 
    
                                                          this once and
                                                          only requires
                                                          that the host
                                                          name be
                                                          checked in
                                                          many 
    
                                                          cases. 
    
                                                          
    
                                                          As a
                                                          principle, the
                                                          members have
                                                          discussed many
                                                          times that the
                                                          AS 
    
                                                          service should
                                                          do validation
                                                          when possible
                                                          — this was
                                                          particularly 
    
                                                          true at the
                                                          Germany
                                                          meeting when
                                                          this came up.
                                                          This is why I
                                                          prefer 
    
                                                          the client
                                                          tell the
                                                          service
                                                          provider what
                                                          it intends to
                                                          do and the 
    
                                                          service
                                                          provider can
                                                          fail that
                                                          request
                                                          immediately if
                                                          necessary. We 
    
                                                          don’t have to
                                                          depend on the
                                                          developer
                                                          getting the
                                                          spec correct
                                                          to 
    
                                                          fail the
                                                          correct way. 
    
                                                          
    
                                                          I worry that
                                                          adding more
                                                          parameters to
                                                          the authz and
                                                          token protocol 
    
                                                          flows
                                                          increases
                                                          complexity and
                                                          attack
                                                          surface. It
                                                          also means per 
    
                                                          authorization
                                                          validation has
                                                          to take place
                                                          vs. a one-time 
    
                                                          validation at
                                                          config time. 
                                                          Placing it in
                                                          the
                                                          configuration
                                                          lookup 
    
                                                          phase (whether
                                                          via web finger
                                                          or just a
                                                          special OAuth
                                                          endpoint) 
    
                                                          seems more
                                                          appropriate
                                                          and far less
                                                          complex - as
                                                          the request
                                                          itself 
    
                                                          is simple and
                                                          has only one
                                                          parameter.
                                                          Here we are
                                                          not considered 
    
                                                          about
                                                          legitimacy of
                                                          the client.
                                                          we’re just
                                                          concerned with
                                                          the issue 
    
                                                          "has the
                                                          client been
                                                          correctly
                                                          informed?â€Â 
    
                                                          
    
                                                          That said, it
                                                          may be that
                                                          when we
                                                          consider all
                                                          the use cases,
                                                          some 
    
                                                          combination of
                                                          AS protocol
                                                          and discovery
                                                          may be both
                                                          needed. I’m 
    
                                                          not ready to
                                                          make
                                                          conclusions
                                                          about this. 
                                                          The current 
    
                                                          oauth-discovery
                                                          spec seems to
                                                          put future
                                                          generic
                                                          clients at
                                                          risk 
    
                                                          and that is my
                                                          primary
                                                          concern. 
    
                                                          
    
                                                          Best Regards, 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          @independentid 
    
                                                          www.independentid.com <http://www.independentid.com/> 
    
                                                          phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 13, 2016,
                                                          at 10:28 PM,
                                                          Mike Jones 
    
                                                          <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> 
    
                                                          wrote: 
    
                                                          
    
                                                          Thanks for
                                                          posting this,
                                                          Phil.  It
                                                          provides a
                                                          concrete
                                                          example of 
    
                                                          a way that
                                                          protected
                                                          resource
                                                          discovery
                                                          could be added
                                                          to 
    
                                                          authorization
                                                          server
                                                          metadata
                                                          discovery, and
                                                          as such,
                                                          should 
    
                                                          provide useful
                                                          input for
                                                          working group
                                                          discussions on
                                                          this topic. 
    
                                                          It’s always
                                                          great when
                                                          someone takes
                                                          the time to
                                                          write an
                                                          actual 
    
                                                          draft that can
                                                          be examined
                                                          and
                                                          implemented,
                                                          and I
                                                          appreciate you 
    
                                                          doing that. 
    
                                                          The content of
                                                          your draft
                                                          points out
                                                          that there
                                                          appears to be 
    
                                                          complete
                                                          agreement on
                                                          what the
                                                          authorization
                                                          server
                                                          metadata 
    
                                                          format should
                                                          be, which is
                                                          great!  I’ll
                                                          note that
                                                          Section 3 of 
    
                                                          draft-hunt-oauth-bound-config-00
                                                          titled
                                                          “Authorization
                                                          Server 
    
                                                          Metadata†is
                                                          an exact copy
                                                          of Section 2
                                                          of 
    
                                                          draft-ietf-oauth-discovery-01
                                                          (with the same
                                                          title), modulo 
    
                                                          applying a
                                                          correction
                                                          suggested by
                                                          the working
                                                          group.  To me
                                                          this 
    
                                                          suggests that
                                                          the
                                                          authorization
                                                          server
                                                          metadata
                                                          definitions in 
    
                                                          draft-ietf-oauth-discovery
                                                          (which is now
                                                          the whole
                                                          normative 
    
                                                          content of the
                                                          draft) are
                                                          clearly ready
                                                          for
                                                          standardization,
                                                          since 
    
                                                          even your
                                                          alternative
                                                          proposal
                                                          includes them
                                                          verbatim. 
    
                                                          Reading your
                                                          draft, the
                                                          problem I have
                                                          with it is
                                                          that you are 
    
                                                          returning the
                                                          AS metadata
                                                          only as a
                                                          WebFinger
                                                          response,
                                                          rather 
    
                                                          than as an
                                                          https-protected
                                                          resource
                                                          published by
                                                          the
                                                          authorization 
    
                                                          server.  The
                                                          choice to only
                                                          return this
                                                          via WebFinger
                                                          makes your 
    
                                                          draft
                                                          incompatible
                                                          with most
                                                          deployed
                                                          implementations
                                                          of OAuth 
    
                                                          metadata,
                                                          including the
                                                          22
                                                          implementations
                                                          using it
                                                          listed 
    
                                                          athttp://openid.net/certification/(see
                                                          the “OP
                                                          Config†column
                                                          in 
    
                                                          the table)
                                                          andOAuth 2.0
                                                          libraries such
                                                          as Microsoft’s
                                                          “ADALâ€Â 
    
                                                          library, which
                                                          uses the
                                                          metadata path
                                                          for client
                                                          configuration. 
    
                                                          Without having
                                                          ASs provide
                                                          the metadata
                                                          as an
                                                          https-protected 
    
                                                          resource,
                                                          implementations
                                                          such as ADAL
                                                          can’t use it
                                                          for client 
    
                                                          configuration
                                                          as the
                                                          currently do. 
    
                                                          Therefore, I
                                                          would request
                                                          that you make
                                                          these minor
                                                          revisions to 
    
                                                          your draft and
                                                          republish, so
                                                          as to provide
                                                          a unified way
                                                          forward 
    
                                                          that is
                                                          compatible
                                                          with all known
                                                          existing OAuth
                                                          Discovery 
    
                                                          deployments: 
    
                                                          1.Modify your
                                                          section 2
                                                          “Authorization
                                                          Server
                                                          WebFinger
                                                          Discoveryâ€Â 
    
                                                          to have the
                                                          WebFinger
                                                          request return
                                                          the issuer
                                                          identifier for
                                                          the 
    
                                                          AS as the
                                                          “WebFinger
                                                          “rel†value,
                                                          rather than
                                                          returning the 
    
                                                          metadata
                                                          values by
                                                          value as the
                                                          “propertiesâ€
                                                          value. 
    
                                                          2.Reference
                                                          the metadata
                                                          definitions
                                                          from Section 2
                                                          of 
    
                                                          draft-ietf-oauth-discovery,
                                                          rather than
                                                          duplicating
                                                          them in your 
    
                                                          Section 3. 
    
                                                          That would
                                                          have the
                                                          advantage of
                                                          paring your
                                                          draft down to
                                                          only 
    
                                                          the new things
                                                          that it
                                                          proposes,
                                                          enabling them
                                                          to be more
                                                          clearly 
    
                                                          understood and
                                                          evaluated on
                                                          their own
                                                          merits.  I
                                                          look forward
                                                          to 
    
                                                          the
                                                          discussions of
                                                          ways of
                                                          performing
                                                          additional
                                                          kinds of OAuth 
    
                                                          discovery, and
                                                          consider your
                                                          draft a
                                                          valuable input
                                                          to those 
    
                                                          discussions. 
    
                                                          Best
                                                          wishes, 
    
                                                          --
                                                          Mike 
    
                                                          *From:*OAuth [mailto:oauth-bounces@ietf.org]*On
                                                          Behalf Of*John
                                                          Bradley 
    
                                                          *Sent:*Sunday,
                                                          March 13, 2016
                                                          6:45 PM 
    
                                                          *To:*Phil Hunt
                                                          <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> 
    
                                                          *Cc:*oauth
                                                          <oauth@ietf.org <mailto:oauth@ietf.org>> 
    
                                                          *Subject:*Re:
                                                          [OAUTH-WG] New
                                                          Version
                                                          Notification
                                                          for 
    
draft-hunt-oauth-bound-config-00.txt 
    
                                                          As I have told
                                                          Phil off list. 
    
                                                          Discovery is
                                                          the wrong
                                                          place to try
                                                          and provide
                                                          security
                                                          against 
    
                                                          man in the
                                                          middle attacks
                                                          on the RS. 
    
                                                          This requires
                                                          the client to
                                                          know what the
                                                          RS URI is
                                                          before 
    
                                                          retrieving the
                                                          information on
                                                          the AS
                                                          Configuration. 
    
                                                          The proposal
                                                          Mike and I
                                                          have been
                                                          working on
                                                          requires the
                                                          client 
    
                                                          to have a
                                                          notion of what
                                                          API it is
                                                          looking for
                                                          and retrieve
                                                          the 
    
                                                          .well-known
                                                          file for that
                                                          API from the
                                                          issuer.   That
                                                          allows a 
    
                                                          protocol like
                                                          Connect to
                                                          register its
                                                          own config
                                                          file that can 
    
                                                          point to the
                                                          RS. 
    
                                                          If the API
                                                          specific well
                                                          known is not
                                                          available the
                                                          client can try 
    
                                                          the default
                                                          oauth-server
                                                          one. 
    
                                                          That then
                                                          allows us to
                                                          deal with
                                                          restricting
                                                          where AT are 
    
                                                          presented as
                                                          part of the
                                                          protocol
                                                          rather then
                                                          dragging
                                                          discovery 
    
                                                          in as a
                                                          requirement. 
    
                                                          In my opinion
                                                          the resource
                                                          the token is
                                                          targeted to
                                                          should be 
    
                                                          separated from
                                                          the scope and
                                                          returned as
                                                          part of the
                                                          meta-data 
    
                                                          about the AT
                                                          along with
                                                          scopes granted
                                                          and expiry
                                                          time.   We 
    
                                                          should also
                                                          have a input
                                                          parameter for
                                                          resources so
                                                          that a client 
    
                                                          can restrict
                                                          tokens issued
                                                          to a subset of
                                                          the ones
                                                          granted by the 
    
                                                          refresh
                                                          token.   It
                                                          would then
                                                          also be
                                                          possible to
                                                          ask a AS for a 
    
                                                          token for a
                                                          unregistered
                                                          RS and have
                                                          the AS produce
                                                          a JWT access 
    
                                                          token with the
                                                          resource as an
                                                          audience if
                                                          policy allows. 
    
                                                          That however
                                                          was supposed
                                                          to be dealt
                                                          with as part
                                                          of the mixed
                                                          up 
    
                                                          client set of
                                                          mitigations. 
    
                                                          In that the
                                                          goal was to
                                                          mitigate the
                                                          attacks by
                                                          returning 
    
                                                          meta-data
                                                          about the
                                                          tokens, and
                                                          not to require
                                                          discovery. 
    
                                                          We intend to
                                                          return “issâ€
                                                          and
                                                          “cleint_idâ€
                                                          for the code,
                                                          and I 
    
                                                          intend to
                                                          discuss at the
                                                          F2F returning
                                                          resource for
                                                          AT as well. 
    
                                                          Those mitigate
                                                          the attack. 
    
                                                          I will
                                                          continue to
                                                          resist mixing
                                                          up discovery
                                                          of
                                                          configuration 
    
                                                          meta-data with
                                                          mitigation of
                                                          the attacks. 
    
                                                          We return
                                                          meta-data
                                                          about the
                                                          tokens now,
                                                          because AT are
                                                          opaque to 
    
                                                          the client, we
                                                          neglected to
                                                          include some
                                                          of the
                                                          information
                                                          for 
    
                                                          the client
                                                          needs to be
                                                          secure.   We
                                                          just need to
                                                          add that in to 
    
                                                          the existing
                                                          flows. 
    
                                                          While Phil’s
                                                          proposal is
                                                          easier for the
                                                          AS to
                                                          implement as
                                                          an add 
    
                                                          on, it puts
                                                          more of a
                                                          burden on the
                                                          client needing
                                                          to potentially 
    
                                                          change how it
                                                          stores the
                                                          relationships
                                                          between AS and
                                                          RS to 
    
                                                          prevent
                                                          compromise, I
                                                          think the
                                                          solution
                                                          should be
                                                          biased towards 
    
                                                          simplicity on
                                                          the client
                                                          side. 
    
                                                          If we return
                                                          the resources
                                                          as part of the
                                                          existing meta
                                                          data the 
    
                                                          client checks
                                                          that against
                                                          the resource
                                                          it intends to
                                                          send the 
    
                                                          token to and
                                                          if it is not
                                                          in the list
                                                          then it can’t
                                                          send the 
    
                                                          token.  Simple
                                                          check every
                                                          time it gets a
                                                          new AT, no
                                                          optionality. 
    
                                                          I am not
                                                          saying
                                                          anything new
                                                          Nat has been
                                                          advocating
                                                          basically 
    
                                                          this for some
                                                          time, and dis
                                                          submit a
                                                          draft.   I
                                                          prefer to
                                                          return 
    
                                                          the info in
                                                          the existing
                                                          format rather
                                                          than as link
                                                          headers,  but 
    
                                                          that is the
                                                          largest
                                                          difference
                                                          between what
                                                          Nat and I are
                                                          saying 
    
                                                          with respect
                                                          to resource. 
    
                                                          That is the
                                                          core of my
                                                          problem with
                                                          Phil’s draft. 
    
                                                          I guess we
                                                          will need to
                                                          have a long
                                                          conversation
                                                          in BA. 
    
                                                          Regards 
    
                                                          John B. 
    
                                                          
    
                                                              On
                                                          Mar 13, 2016,
                                                          at 8:12 PM,
                                                          Phil Hunt <phil.hunt@oracle.com 
    
                                                              <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                              This
                                                          draft is a
                                                          proposed
                                                          alternate
                                                          proposal for 
    
                                                              draft-ietf-oauth-discovery. 
                                                          As such, it
                                                          contains the
                                                          same 
    
                                                              registry
                                                          for OAuth
                                                          Config
                                                          Metadata as
                                                          the authors
                                                          believe that 
    
                                                              both
                                                          solutions are
                                                          not required,
                                                          or depending
                                                          on WG
                                                          discussion 
    
                                                              they
                                                          will be
                                                          merged. The
                                                          intent is to
                                                          provide a
                                                          simple 
    
                                                              complete
                                                          draft for
                                                          consideration. 
    
                                                              How
                                                          it works... 
    
                                                              Given
                                                          that a client
                                                          has previously
                                                          discovered an
                                                          OAuth 
    
                                                              protected
                                                          resource, the
                                                          bound
                                                          configuration
                                                          method allows
                                                          a 
    
                                                              client
                                                          to return the
                                                          configuration
                                                          for an oauth
                                                          authorization 
    
                                                              server
                                                          that can issue
                                                          tokens for the
                                                          resource URI
                                                          specified by 
    
                                                              the
                                                          client.  The
                                                          AS is not
                                                          required to be
                                                          in the same
                                                          domain. 
    
                                                               The
                                                          AS is however
                                                          required to
                                                          know if it can
                                                          issue tokens
                                                          for 
    
                                                              a
                                                          resource
                                                          service (which
                                                          presumes some
                                                          agreement
                                                          exists on 
    
                                                              tokens
                                                          etc). 
    
                                                              The
                                                          draft does not
                                                          require that
                                                          the resource
                                                          exist (e.g.
                                                          for 
    
                                                              unconfigured
                                                          or new user
                                                          based
                                                          resources). It
                                                          only requires 
    
                                                              that
                                                          the AS service
                                                          provider
                                                          agrees it can
                                                          issue tokens. 
    
                                                              From
                                                          a security
                                                          perspective,
                                                          returning the
                                                          OAuth service 
    
                                                              configuration
                                                          for a
                                                          specified
                                                          resource URI
                                                          serves to
                                                          confirm 
    
                                                              the
                                                          client is in
                                                          possession of
                                                          a valid
                                                          resource URI
                                                          ensuring 
    
                                                              the
                                                          client has
                                                          received a
                                                          valid set of
                                                          endpoints for
                                                          the 
    
                                                              resource
                                                          and the
                                                          associated
                                                          oauth
                                                          services. 
    
                                                              I
                                                          propose that
                                                          the WG
                                                          consider the
                                                          alternate
                                                          draft
                                                          carefully 
    
                                                              as
                                                          well as other
                                                          submissions
                                                          and evaluate
                                                          the broader 
    
                                                              discovery
                                                          problem before
                                                          proceeding
                                                          with WGLC on
                                                          OAuth
                                                          Discovery. 
    
                                                              Thanks! 
    
                                                              Phil 
    
                                                              @independentid 
    
                                                              www.independentid.com <http://www.independentid.com/> 
    
                                                              phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 
    
                                                          
    
                                                          
    
                                                                  Begin
                                                          forwarded
                                                          message: 
    
                                                                  *From:*internet-drafts@ietf.org 
    
                                                                  <mailto:internet-drafts@ietf.org> 
    
                                                                  *Subject:
                                                          New Version
                                                          Notification
                                                          for 
    
                                                                  draft-hunt-oauth-bound-config-00.txt* 
    
                                                                  *Date:*March
                                                          13, 2016 at
                                                          3:53:37 PM PDT 
    
                                                                  *To:*"Phil
                                                          Hunt" <phil.hunt@yahoo.com 
    
                                                                  <mailto:phil.hunt@yahoo.com>>,
                                                          "Anthony
                                                          Nadalin" 
    
                                                                  <tonynad@microsoft.com <mailto:tonynad@microsoft.com>>, 
    
                                                                  "Tony
                                                          Nadalin" <tonynad@microsoft.com 
    
                                                                  <mailto:tonynad@microsoft.com>> 
    
                                                          
    
                                                          
    
                                                                  A
                                                          new version of
                                                          I-D,
                                                          draft-hunt-oauth-bound-config-00.txt 
    
                                                                  has
                                                          been
                                                          successfully
                                                          submitted by
                                                          Phil Hunt and
                                                          posted to the 
    
                                                                  IETF
                                                          repository. 
    
                                                          
    
                                                                  Name:draft-hunt-oauth-bound-config 
    
                                                                  Revision:00 
    
                                                                  Title:OAuth
                                                          2.0 Bound
                                                          Configuration
                                                          Lookup 
    
                                                                  Document
date:2016-03-13 
    
                                                                  Group:Individual
                                                          Submission 
    
                                                                  Pages:22 
    
                                                                  URL: 
    
                                                                  https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                                                                  Status: 
    
                                                                  https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ 
    
                                                                  Htmlized: 
    
                                                                  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 
    
                                                          
    
                                                          
    
                                                                  Abstract: 
    
                                                                    This specification defines a
                                                          mechanism for
                                                          the client of 
    
                                                                  an
                                                          OAuth 2.0 
    
                                                                    protected resource service to
                                                          obtain the
                                                          configuration 
    
                                                                  details
                                                          of an 
    
                                                                    OAuth 2.0 authorization server
                                                          that is
                                                          capable of 
    
                                                                  authorizing
                                                          access 
    
                                                                    to a specific resource service. 
                                                          The
                                                          information 
    
                                                                  includes
                                                          the OAuth 
    
                                                                    2.0 component endpoint location
                                                          URIs and as
                                                          well as 
    
                                                                  authorization 
    
                                                                    server capabilities. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                                  Please
                                                          note that it
                                                          may take a
                                                          couple of
                                                          minutes from
                                                          the 
    
                                                                  time
                                                          of submission 
    
                                                                  until
                                                          the htmlized
                                                          version and
                                                          diff are
                                                          available 
    
                                                                  attools.ietf.org <http://tools.ietf.org/>. 
    
                                                          
    
                                                                  The
                                                          IETF
                                                          Secretariat 
    
                                                          
    
                                                              _______________________________________________ 
    
                                                              OAuth
                                                          mailing list 
    
                                                              OAuth@ietf.org <mailto:OAuth@ietf.org> 
    
                                                              https://www.ietf.org/mailman/listinfo/oauth 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
_______________________________________________ 
    
                                                          OAuth mailing
                                                          list 
    
                                                          OAuth@ietf.org <mailto:OAuth@ietf.org> 
    
                                                          https://www.ietf.org/mailman/listinfo/oauth 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
_______________________________________________ 
    
                                                          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
    
                                                        
    
                                                      
    
                                                    
    
                                                    
    
                                                  
    
                                                
    
                                              
    
                                            
    
                                          
    
                                        
    
                                      
    
                                      
    
                                    
    
                                  
    
                                
    
                              
    
                            
    
                          
    
                          
    
                        
    
                      
    
                    
    
                  
    
                  
    
                
    
              
    
            
    
          
    
        
    
      
    
    
    
    
    
  


--------------010605000008040605090305--


From nobody Tue Mar 15 15:15:12 2016
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 6AA2212D697 for ; Tue, 15 Mar 2016 15:15:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 M9nhot7SnrUy for ; Tue, 15 Mar 2016 15:15:04 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 4AB0B12D57E for ; Tue, 15 Mar 2016 15:15:04 -0700 (PDT)
Received: by mail-qg0-x22a.google.com with SMTP id t4so27857873qge.0 for ; Tue, 15 Mar 2016 15:15:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=STL+HUzI3KqSheqZv10I9cCHsI3Dh6QPqW2pUsZFIOQ=; b=xT468lHXQMjlnMPQ9nm0Z4Vy45Ge4iT3GC46gqmiDZdO26ZN/FSdlJdV/HldVArNRO A1pp/CpY3uj58yOSiIazz4flMXyAUsTxFB4xUoIwZgdHFC0OWUSNu94ueG293iZQsTKb JgKFU+v5F6pGldIq8kC78irwaoESvaM4Sjxf/cg1zrlImlRVj1KfCh1fQcxL2hoIG36a yVZA30hvY4SdOkDOWJPl4eatOEdyXf3ka5OoLs/TFcZme0HIzLMdy8c6o2FudhQSd8hW IDT+ITXFr2ZQKfOE/S/U7M4avFE417pnwfEZ+p8sTFW+Vh1DXGFqzBXPtV0FE/+F4dBH JMjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=STL+HUzI3KqSheqZv10I9cCHsI3Dh6QPqW2pUsZFIOQ=; b=lCVTii7dviagspgXqJICtfNUbmsByaE3Qnzu8w6nRuC5OcwWnQux7KB79b/a6c3vG6 FVU1njeha/cdxUQ9DpTHoRnnvPeLacWpnXEuGdPkL2UUpW1p7bSb4Sv2OTaWQjd5uavO nckRDhq221x1STLM3w0jv3zCg9KstIv5VnLWU/J/5K6IlGNSxL9X5Ed8i9bApMZiGUUi sFEinASH2cWqLByJRU7hrkapVBM9JzDqOS2YadJiVl0DqV24br/Hpbu+1JrdjmtqtkkX HrfviUID7hdXg5H6uqgaelFPKC1pMT4bfBu4Zt9zWva5qfhogQ2T3cBwZvM0R1H8sWY+ 8bOQ==
X-Gm-Message-State: AD7BkJIbhnqhwKYZa8bpwQeAqxWaq205kSefOlDQHphfb9pRYCWwhMzKBf2/6CYIAq8a5w==
X-Received: by 10.140.148.134 with SMTP id 128mr681252qhu.98.1458080102875; Tue, 15 Mar 2016 15:15:02 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.31.112]) by smtp.gmail.com with ESMTPSA id 107sm130110qge.16.2016.03.15.15.15.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Mar 2016 15:15:02 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_1515BFF8-73F1-415A-BDE4-C338218C14EE"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56E87E94.4060100@aol.com>
Date: Tue, 15 Mar 2016 19:14:58 -0300
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Mar 2016 22:15:11 -0000

--Apple-Mail=_1515BFF8-73F1-415A-BDE4-C338218C14EE
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2E284206-9932-46EB-A190-327B6183F73B"


--Apple-Mail=_2E284206-9932-46EB-A190-327B6183F73B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If the AS is audience restricting the tokens then it just needs to put =
the right audience in the token based on what the client is asking for. =20=

That is safe as the RS wouldn=E2=80=99t be able to replay the token =
someplace else.

That would need to be a AS policy if it wanted to do that for unknown =
RS.  =20

Allowing more than one audience in a token is a convince but a well =
known security risk with bearer tokens.

A AS would probably want to have only one audience in a AT for a =
untrusted RS, but may allow multiple if they are all trusted.

John B.


> On Mar 15, 2016, at 6:28 PM, George Fletcher  wrote:
>=20
>=20
> On 3/15/16 3:26 PM, John Bradley wrote:
>> I think Phil and others are concerned that a developer might get bad =
info to put in the client , some out of band discovery goes wrong or the =
user is somehow tricked into specifying a bad resource to the client.
>>=20
>> So getting a bad resource is a touch hypothetical.=20
> If we are really trying to solve this problem holistically, then we =
probably need to first describe the use cases we want to solve. I'm =
starting to wonder if we are all providing solutions to slightly =
different use cases.
>>=20
>> For Connect we could suppose that someone publishes a malicious =
discovery document listing themselves as the RS but all the other =
endpoints are at the good AS so the client registers, authorizes the =
user and gives the AT to the bad guy.  The confused client mitigation by =
returning client_id_and issuer from the authorization endpoint will stop =
the attack before the token can be given to the token endpoint or RS.
> Agreed and I'm fine with this solution.
>>=20
>> So protecting the AT at this point is more for a unknown attack that =
would confuse whatever protocol/API that is using OAuth about what RS to =
use.
> Yes. This is where we need to describe some use cases (preferably real =
vs contrived) before we propose solutions. In most cases the RS =
endpoints are hard coded into the client or maybe pulled from a =
different central config endpoint (which is fixed).
>=20
> That's why the only case I could think of is a client that works with =
multiple RS endpoints from different providers that server the same =
content (e.g. PortableContacts API). In this use case, the user of the =
client would need to enter the location of the RS they wanted to use and =
then the flow would start from there. In reality, most services like =
this would have a fixed set of RS's they work with and again it wouldn't =
be dynamic.
>>=20
>> In reality this is what PoP is supposed to be for.
>>=20
>> I guess the question is what short of PoP can we do to prevent the =
client leaking tokens to bad RS that confuse it via the application =
protocol.
>>=20
>> If we want to del with this in OAuth then we need to tell the AS =
where the token is going to be used or tel the client where the token =
can be used.=20
>>=20
>> I think letting the client tell the AS where it wants the token used =
having the AS construct a audience out of that is probably the best =
thing.  to get around having a pre-established relationship between the =
AS and RS.
> Even if the client tells the AS where it wants to use the token (via =
some endpoint URL), the AS still needs to have a relationship with the =
RS (at a minimum as an endpointURL-to-RS map) otherwise how can it =
determine if it is allowed to issue an access token to the user for that =
RS. This map is what I want to avoid "building" into the AS. Do we need =
"dynamic RS registration" to support this?
>=20
>>=20
>> John B.
>>=20
>>> On Mar 15, 2016, at 3:14 PM, George Fletcher > wrote:
>>>=20
>>>=20
>>>=20
>>> I think Justin provided a good break down of the different aspects a =
client wants to specify about the requested token. (my paraphrase)
>>>   1. what RS's the token will be used at
>>>   2. authorization privilege requests
>>>   3. token-timing adjustments
>>>=20
>>> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.
>>>=20
>>>=20
>>>=20
>>> On 3/15/16 1:56 PM, John Bradley wrote:
>>>> I think it is a AS policy decision if it should error or take the =
requested resource and issue a token audianced for that resource.
>>> Actually, the error cases are interesting. What if the passed in =
resource/audience doesn't actually match a requested scope? Or some =
match and some don't? Is it better to send back a token with less =
capability? or error the entire request?
>>>>=20
>>>>=20
>>>> I guess the question is how to transition from now to a future =
state.   If you cannot upgrade all the clients at once.
>>>>=20
>>>> A processing rule on the AS that allowed some clients to not send =
the requested resource , but would error out for other upgraded clients  =
with a "resource not allowed=E2=80=9D oauth error would work and not =
require the return of the resources. =20
>>>>=20
>>>> If you return the resources and let the client error if it is =
trying to send to the wrong endpoint that make upgrading easier, but =
gives less control to the AS.
>>>>=20
>>>> I could live with it ether way.
>>>>=20
>>>> The advantage of always sending it in the token request is that it =
allows the AS to do the mapping from a resource URI to one or more =
abstract audience for the token.
>>> I thought Justin provided a good break down of the different aspects =
a client wants to specify about the requested token. (my paraphrase)
>>>   1. what RS's the token will be used at
>>>   2. authorization privilege requests
>>>   3. token-timing adjustments
>>>=20
>>> The question is how does a client internally reference a resource =
server? If it's a fixed RS endpoint, then it sort of doesn't matter, the =
client isn't going to send the token to the wrong endpoint anyway and it =
can easily reference the audience by an abstract URI.
>>>=20
>>> If the client can dynamically find new RS's to interact with. How =
does that happen? Does the client get handed an endpoint to use? or does =
it do some sort of discovery to determine the endpoint? I suppose both =
are possible.
>>>=20
>>> Could we prescribe that the realm value of RFC 6750 error response =
be effectively a resource-service-id (like issuer for the AS). The =
client would then need to do discovery on that value to find the valid =
endpoints of the RS. This could be done once and the resource-service-id =
could be used as the "abstract" RS identifier. This requires no more =
discovery than adding an AS to the client.
>>>>=20
>>>> That might help address George=E2=80=99s concern.
>>> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this map of URIs to RS that is almost assuredly to get out of sync.
>>>>=20
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell =
> wrote:
>>>>>=20
>>>>> I was thinking it'd be simpler to error, if the requested =
resource(s) weren't okay. That puts the burden of checking in the AS. =
And doesn't add anything to the token or authorization response. I see =
the potential similarity to scope but not sure it's worth it.   =20
>>>>>=20
>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>>> If the client specifies the resource it wants the token for, then =
the meta-data would not be required unless the resources the token is =
good at are different from the request. =20
>>>>> Lat is the same logic as scopes.
>>>>>=20
>>>>> For backwards compatibility if the client is happy with the =
default resources based on scopes then I think it is a good idea to tell =
the client what the resources are in the response.
>>>>>=20
>>>>> I suspect that it is simpler with less optionality and always =
return the resources, even if they are not required.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell < =
bcampbell@pingidentity.com =
> wrote:
>>>>>>=20
>>>>>> If the client specifies the desired audience(s)/resource(s), is =
that metadata to the client needed? The AS can audience restrict the =
token as needed or respond with an error if it can't or wont issue a =
token for the resource the client asked for.=20
>>>>>>=20
>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>>=20
>>>>>> The AS needs to infer an audience from the scopes snd/or have the =
client specify the desired audience.
>>>>>>=20
>>>>>> If the AT has a audience or audiences then as long as the =
endpoint URI are provided as meta-data with the token, the client can =
determine if it is sending the token to the correct place.
>>>>>>=20
>>>>>> I think Phil would prefer the server rather than the client do =
the check, but the client always needs to take some responsibility to =
not leak tokens giving them to the wrong RS or the code to the wrong =
token endpoint is leaking.
>>>>>>=20
>>>>>> I imagine that claims based access tokens are going to become =
more popular and the static relationship between one RS and one AS will =
not be the majority of deployments over time.=20
>>>>>>=20
>>>>>> In any case where the client is configured up front to know the =
RS and the AS it seems like that would not require Phil=E2=80=99s =
Solution, but that is the only case supported by that discovery.
>>>>>>  =20
>>>>>> If the client itself is bad there is not much you can do to stop =
it from passing on the AT in way way it wants.  That however is a =
different problem and needs claimed URI or attestations to prevent =
client spoofing.
>>>>>> William and I are working on that in the mobile best practices =
draft.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>>=20
>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>>>=20
>>>>>>> I worry about two directions I see in this thread...
>>>>>>>=20
>>>>>>> 1. Client's accessing resources dynamically so that discovery is =
required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>>>>>>>=20
>>>>>>> 2. Creating a tight coupling between RS and AS such that RS =
endpoint changes must be continually communicated to the AS. If an RS =
supports multiple AS's then the RS has to deal with "guaranteed" =
delivery. The AS needs an endpoint to receive such communications. If =
not dynamic via APIs, then deployment of the new RS is bound by the =
associated AS's getting and deploying the new endpoints. Can both =
endpoints of the RS be supported within the AS for some period of time, =
etc. This is an operation nightmare and almost assuredly going to go =
wrong in production.
>>>>>>>=20
>>>>>>> Maybe an OAuth2 "audience binding" spec is what's needed for =
those deployments that require this. I believe that is what John Bradley =
is suggesting.
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> George
>>>>>>>=20
>>>>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>> +1, I've found the very same in OAuth deployments that I was =
involved in; the hard part is to give names and descriptions to these =
concepts so that they cover all use cases and can be applied =
unambiguously=20
>>>>>>>>=20
>>>>>>>> Hans.=20
>>>>>>>>=20
>>>>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>>>>>> I agree that this is valuable, and not just for PoP. In all =
honesty,=20
>>>>>>>>> it=E2=80=99s not even really required for PoP to function in =
many cases =E2=80=94 it=E2=80=99s=20
>>>>>>>>> just an optimization for one particular kind of key =
distribution=20
>>>>>>>>> mechanism in that case.=20
>>>>>>>>>=20
>>>>>>>>> In the years of deployment experience with OAuth 2, I think =
we=E2=80=99ve really=20
>>>>>>>>> got three different kinds of things that currently get folded =
into=20
>>>>>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating =
out better:=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>>>>>   - What actions do I want to take on these things? (read, =
write, delete)=20
>>>>>>>>>   - How long do I want these tokens to work?=20
>>>>>>>>> (offline_access/refresh_token, one time use, next hour, etc)=20=

>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> I think the first one is close to the audience/resource =
parameters that=20
>>>>>>>>> have been bandied about a few times, including in the current =
token=20
>>>>>>>>> exchange document. We should be consistent across drafts in =
that regard.=20
>>>>>>>>> The second is more traditional scope-ish. The third has been =
patched in=20
>>>>>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain =
APIs.=20
>>>>>>>>>=20
>>>>>>>>> Just another vector to think about if we=E2=80=99re going to =
be adding things=20
>>>>>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D =
or both to the token requests.=20
>>>>>>>>>=20
>>>>>>>>>   =E2=80=94 Justin=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>>>>>   =
> wrote:=20
>>>>>>>>>>=20
>>>>>>>>>> Yes I will work on another proposal for allowing clients to =
specify=20
>>>>>>>>>> what resource they want a token for and providing the =
meta-data to the=20
>>>>>>>>>> client about the resources that a token is valid for.=20
>>>>>>>>>>=20
>>>>>>>>>> We have part of it in the POP key distribution spec and =
talked about=20
>>>>>>>>>> separating it, as it is used more places than just for =
assigning keys.=20
>>>>>>>>>> I know some AS use different token formats for different RS =
so are=20
>>>>>>>>>> all-ready needing to pass the resource in the request to =
avoid making=20
>>>>>>>>>> a mess of scopes.=20
>>>>>>>>>>=20
>>>>>>>>>> John B.=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) < =
phil.hunt@oracle.com =
=20
>>>>>>>>>>>   =
> wrote:=20
>>>>>>>>>>>=20
>>>>>>>>>>> Inline=20
>>>>>>>>>>>=20
>>>>>>>>>>> Phil=20
>>>>>>>>>>>=20
>>>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>>>>>>   =
> wrote:=20
>>>>>>>>>>>=20
>>>>>>>>>>>> We had two mandates.  One was to provide a spec for AS =
metadata.=20
>>>>>>>>>>>> The other was to mitigate the client mixup attack.  The =
request was=20
>>>>>>>>>>>> to do the latter without requiring the former for clients =
that don=E2=80=99t=20
>>>>>>>>>>>> otherwise need discovery.=20
>>>>>>>>>>> There is no mandate for any of this. See=20
>>>>>>>>>>>  =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22=
.txt =
=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Returning the issuer and client_id from the authorization =
endpoint=20
>>>>>>>>>>>> and the client checking them can be done by the client =
without=20
>>>>>>>>>>>> discovery.=20
>>>>>>>>>>>=20
>>>>>>>>>>> How does this address the issue of whether the client is =
talking to=20
>>>>>>>>>>> the wrong endpoint?=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Any client that has the resource and issuer hard coded =
probably=20
>>>>>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>>>>>> We agree=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> One of the things that a client will need discovery for is =
to find=20
>>>>>>>>>>>> the RS, so requiring the client to know the RS URI before =
getting=20
>>>>>>>>>>>> the AS config seems backwards to me.=20
>>>>>>>>>>> How can you make an assumption on order? You seem to be =
conflating=20
>>>>>>>>>>> authentication with authorization by assuming the identity =
drives=20
>>>>>>>>>>> what the resource is.=20
>>>>>>>>>>>=20
>>>>>>>>>>> There are lots of applications that require user rights but =
are not=20
>>>>>>>>>>> identify centric. For example a document service.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Unless the client tells the AS where it intends to use the =
token we=20
>>>>>>>>>>>> will be leaving a security hole because the bearer tokens =
will have=20
>>>>>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> True you are telling the AS (Webfinger service) what the RS =
is but=20
>>>>>>>>>>>> that is not at a place that is useful in the token =
production process.=20
>>>>>>>>>>>=20
>>>>>>>>>>> This has nothing to do with token production.=20
>>>>>>>>>>>=20
>>>>>>>>>>> What we want to ensure is whether an honest client is =
correctly=20
>>>>>>>>>>> configured and has not been mislead - eg by a phishing page.=20=

>>>>>>>>>>>>=20
>>>>>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99t=
 know all the=20
>>>>>>>>>>>> possible RS.   That is not something that a out of band =
check can=20
>>>>>>>>>>>> address.=20
>>>>>>>>>>>=20
>>>>>>>>>>> May be. Lets identify them.=20
>>>>>>>>>>>=20
>>>>>>>>>>>> There are also cases where a token might be good at =
multiple RS=20
>>>>>>>>>>>> endpoints intentionally.=20
>>>>>>>>>>>=20
>>>>>>>>>>>>  In your solution the client would need to make a discovery =
request=20
>>>>>>>>>>>> for each endpoint.=20
>>>>>>>>>>> Sure. Otherwise how would it know if there is one AS or a =
pool of AS=20
>>>>>>>>>>> servers assigned to each instance?=20
>>>>>>>>>>>> Those requests lack the context of who the client and =
resource owner=20
>>>>>>>>>>>> are.  I think that will be a problem in some use cases.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Not sure I agree. This is about discovering a valid set of =
endpoints.=20
>>>>>>>>>>> For mitm, we mainly want to check the hostname is correct. =
If a=20
>>>>>>>>>>> client chooses evil.com   =
  the cert can be =
valid and=20
>>>>>>>>>>> TLS will pass. How does it otherwise know it is supposed to =
talk to=20
>>>>>>>>>>> res.example.com  =
 ?=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> If this is added to the token endpoint it would be checked =
when code=20
>>>>>>>>>>>> or refresh are exchanged, not every time the token is used.=20=

>>>>>>>>>>> Your proposal requires rhe client to check. I am not clear =
how the AS=20
>>>>>>>>>>> can know the exact uri. It is far easier to validate than to =
lookup=20
>>>>>>>>>>> since as you say the client may be authorized to use =
multiple ASs.=20
>>>>>>>>>>>> With a out of band check the client would never know if a =
RS was=20
>>>>>>>>>>>> removed/revoked.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Not sure that is in scope.=20
>>>>>>>>>>>=20
>>>>>>>>>>> None of the current proposals address this issue.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> I don=E2=80=99t see checking when refreshing a token as =
something that is a=20
>>>>>>>>>>>> huge burden.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Still its a lot more than once.=20
>>>>>>>>>>>=20
>>>>>>>>>>> Why don't you draft another alternative?=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> If the server wants to do the check on it=E2=80=99s side =
then we could=20
>>>>>>>>>>>> require the client to send the RS URI in the token request. =
that way=20
>>>>>>>>>>>> you really know the client is not going to get a token for =
the wrong=20
>>>>>>>>>>>> RS endpoint.=20
>>>>>>>>>>>> If you check out of band in discovery you really have no =
idea if the=20
>>>>>>>>>>>> client is checking.=20
>>>>>>>>>>>=20
>>>>>>>>>>> In the new webfinger draft, the client isn't checking. The =
service=20
>>>>>>>>>>> provider simply does not disclose oauth information to =
misconfigured=20
>>>>>>>>>>> clients.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> John B.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt < =
phil.hunt@oracle.com =
=20
>>>>>>>>>>>>>  =
 =
> wrote:=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Thanks to Mike and John for their feedback.  I=E2=80=99ll =
take each in turn:=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Mike,=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Regarding your suggested amendments=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Item 1: Returning the config URL would create two =
problems. One,it=20
>>>>>>>>>>>>> makes bound discovery a two-step process - that adds =
complexity.=20
>>>>>>>>>>>>>  It seems far simpler to mandate TLS (which I think it =
already does=20
>>>>>>>>>>>>> in the security considerations).=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> The two-step process allows the current discovery process =
to=20
>>>>>>>>>>>>> continue. I disagree with this. This is why I put forward =
an=20
>>>>>>>>>>>>> =E2=80=9Calternate" draft that is almost the same but =
simply adds the check=20
>>>>>>>>>>>>> before returning the configuration data.  I worry that  =
developers=20
>>>>>>>>>>>>> would have no incentive to do the two-step approach. They =
would=20
>>>>>>>>>>>>> just start at step 2 which in turn puts AS=E2=80=99s at =
risk of exposing=20
>>>>>>>>>>>>> tokens because it works. This makes OAuth promiscuous.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Regarding existing implementations. Most of those =
implementations=20
>>>>>>>>>>>>> are for OIDC.  I think it makes sense for OIDF to continue =
use of=20
>>>>>>>>>>>>> OIDC's discovery spec because the UserInfo endpoint is =
well defined=20
>>>>>>>>>>>>> and the likelihood of a client mis-informed about the =
resource=20
>>>>>>>>>>>>> endpoint is not there.  IMO This does not apply to the =
broader=20
>>>>>>>>>>>>> OAuth community.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Item 2:  It may be appropriate to have a separate =
configuration=20
>>>>>>>>>>>>> registry specification, but I think we should hold off =
until we=20
>>>>>>>>>>>>> have a complete solution and then make the decision what =
drafts=20
>>>>>>>>>>>>> should exist and how many pieces.  A big concern is the =
perceived=20
>>>>>>>>>>>>> complexity of multiple solutions and multiple drafts.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> As to John Bradley=E2=80=99s comments:=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.=20
>>>>>>>>>>>>> I=E2=80=99m confused by this.  Our mandate was to solve a =
security threat=20
>>>>>>>>>>>>> by having a discovery specification to prevent clients =
being=20
>>>>>>>>>>>>> mis-lead about endpoints (of which resource service is =
one) in an=20
>>>>>>>>>>>>> oauth protected exchange.  Maybe what you mean is we =
should not use=20
>>>>>>>>>>>>> .well-known of any kind and we should just create a =
=E2=80=9C/Config=E2=80=9D=20
>>>>>>>>>>>>> endpoint to OAuth?=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Re: Your proposal for MITM mitigation=20
>>>>>>>>>>>>> You propose that instead the resource endpoint check =
should be in=20
>>>>>>>>>>>>> the oauth protocol itself.  The difference is that =
validation is=20
>>>>>>>>>>>>> transferred back to the client to get it right. As well, =
without=20
>>>>>>>>>>>>> the client informing the AS, I can=E2=80=99t see a way for =
the AS to know=20
>>>>>>>>>>>>> what endpoint the client is using.  The webfinger approach =
does=20
>>>>>>>>>>>>> this once and only requires that the host name be checked =
in many=20
>>>>>>>>>>>>> cases.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> As a principle, the members have discussed many times that =
the AS=20
>>>>>>>>>>>>> service should do validation when possible =E2=80=94 this =
was particularly=20
>>>>>>>>>>>>> true at the Germany meeting when this came up. This is why =
I prefer=20
>>>>>>>>>>>>> the client tell the service provider what it intends to do =
and the=20
>>>>>>>>>>>>> service provider can fail that request immediately if =
necessary. We=20
>>>>>>>>>>>>> don=E2=80=99t have to depend on the developer getting the =
spec correct to=20
>>>>>>>>>>>>> fail the correct way.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I worry that adding more parameters to the authz and token =
protocol=20
>>>>>>>>>>>>> flows increases complexity and attack surface. It also =
means per=20
>>>>>>>>>>>>> authorization validation has to take place vs. a one-time=20=

>>>>>>>>>>>>> validation at config time.  Placing it in the =
configuration lookup=20
>>>>>>>>>>>>> phase (whether via web finger or just a special OAuth =
endpoint)=20
>>>>>>>>>>>>> seems more appropriate and far less complex - as the =
request itself=20
>>>>>>>>>>>>> is simple and has only one parameter. Here we are not =
considered=20
>>>>>>>>>>>>> about legitimacy of the client. we=E2=80=99re just =
concerned with the issue=20
>>>>>>>>>>>>> "has the client been correctly informed?=E2=80=9D=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> That said, it may be that when we consider all the use =
cases, some=20
>>>>>>>>>>>>> combination of AS protocol and discovery may be both =
needed. I=E2=80=99m=20
>>>>>>>>>>>>> not ready to make conclusions about this.  The current=20
>>>>>>>>>>>>> oauth-discovery spec seems to put future generic clients =
at risk=20
>>>>>>>>>>>>> and that is my primary concern.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Best Regards,=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Phil=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> @independentid=20
>>>>>>>>>>>>>  www.independentid.com =
  =
=20
>>>>>>>>>>>>>  phil.hunt@oracle.com =
  =
=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones=20
>>>>>>>>>>>>>> < =
Michael.Jones@microsoft.com =
 =
 =
>=20
>>>>>>>>>>>>>> wrote:=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Thanks for posting this, Phil.  It provides a concrete =
example of=20
>>>>>>>>>>>>>> a way that protected resource discovery could be added to=20=

>>>>>>>>>>>>>> authorization server metadata discovery, and as such, =
should=20
>>>>>>>>>>>>>> provide useful input for working group discussions on =
this topic.=20
>>>>>>>>>>>>>> It=E2=80=99s always great when someone takes the time to =
write an actual=20
>>>>>>>>>>>>>> draft that can be examined and implemented, and I =
appreciate you=20
>>>>>>>>>>>>>> doing that.=20
>>>>>>>>>>>>>> The content of your draft points out that there appears =
to be=20
>>>>>>>>>>>>>> complete agreement on what the authorization server =
metadata=20
>>>>>>>>>>>>>> format should be, which is great!  I=E2=80=99ll note that =
Section 3 of=20
>>>>>>>>>>>>>> draft-hunt-oauth-bound-config-00 titled =E2=80=9CAuthorizat=
ion Server=20
>>>>>>>>>>>>>> Metadata=E2=80=9D is an exact copy of Section 2 of=20
>>>>>>>>>>>>>> draft-ietf-oauth-discovery-01 (with the same title), =
modulo=20
>>>>>>>>>>>>>> applying a correction suggested by the working group.  To =
me this=20
>>>>>>>>>>>>>> suggests that the authorization server metadata =
definitions in=20
>>>>>>>>>>>>>> draft-ietf-oauth-discovery (which is now the whole =
normative=20
>>>>>>>>>>>>>> content of the draft) are clearly ready for =
standardization, since=20
>>>>>>>>>>>>>> even your alternative proposal includes them verbatim.=20
>>>>>>>>>>>>>> Reading your draft, the problem I have with it is that =
you are=20
>>>>>>>>>>>>>> returning the AS metadata only as a WebFinger response, =
rather=20
>>>>>>>>>>>>>> than as an https-protected resource published by the =
authorization=20
>>>>>>>>>>>>>> server.  The choice to only return this via WebFinger =
makes your=20
>>>>>>>>>>>>>> draft incompatible with most deployed implementations of =
OAuth=20
>>>>>>>>>>>>>> metadata, including the 22 implementations using it =
listed=20
>>>>>>>>>>>>>> athttp://openid.net/certification/ <>(see the =E2=80=9COP =
Config=E2=80=9D column in=20
>>>>>>>>>>>>>> the table) andOAuth 2.0 libraries such as Microsoft=E2=80=99=
s =E2=80=9CADAL=E2=80=9D=20
>>>>>>>>>>>>>> library, which uses the metadata path for client =
configuration.=20
>>>>>>>>>>>>>> Without having ASs provide the metadata as an =
https-protected=20
>>>>>>>>>>>>>> resource, implementations such as ADAL can=E2=80=99t use =
it for client=20
>>>>>>>>>>>>>> configuration as the currently do.=20
>>>>>>>>>>>>>> Therefore, I would request that you make these minor =
revisions to=20
>>>>>>>>>>>>>> your draft and republish, so as to provide a unified way =
forward=20
>>>>>>>>>>>>>> that is compatible with all known existing OAuth =
Discovery=20
>>>>>>>>>>>>>> deployments:=20
>>>>>>>>>>>>>> 1.Modify your section 2 =E2=80=9CAuthorization Server =
WebFinger Discovery=E2=80=9D=20
>>>>>>>>>>>>>> to have the WebFinger request return the issuer =
identifier for the=20
>>>>>>>>>>>>>> AS as the =E2=80=9CWebFinger =E2=80=9Crel=E2=80=9D value, =
rather than returning the=20
>>>>>>>>>>>>>> metadata values by value as the =E2=80=9Cproperties=E2=80=9D=
 value.=20
>>>>>>>>>>>>>> 2.Reference the metadata definitions from Section 2 of=20
>>>>>>>>>>>>>> draft-ietf-oauth-discovery, rather than duplicating them =
in your=20
>>>>>>>>>>>>>> Section 3.=20
>>>>>>>>>>>>>> That would have the advantage of paring your draft down =
to only=20
>>>>>>>>>>>>>> the new things that it proposes, enabling them to be more =
clearly=20
>>>>>>>>>>>>>> understood and evaluated on their own merits.  I look =
forward to=20
>>>>>>>>>>>>>> the discussions of ways of performing additional kinds of =
OAuth=20
>>>>>>>>>>>>>> discovery, and consider your draft a valuable input to =
those=20
>>>>>>>>>>>>>> discussions.=20
>>>>>>>>>>>>>>                                                           =
Best wishes,=20
>>>>>>>>>>>>>>                                                           =
-- Mike=20
>>>>>>>>>>>>>> *From:*OAuth [ =
mailto:oauth-bounces@ietf.org =
]*On Behalf Of*John Bradley=20
>>>>>>>>>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM=20
>>>>>>>>>>>>>> *To:*Phil Hunt < =
phil.hunt@oracle.com =
  =
>=20
>>>>>>>>>>>>>> *Cc:*oauth < oauth@ietf.org =
  >=20=

>>>>>>>>>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for=20
>>>>>>>>>>>>>> draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>>>>>> As I have told Phil off list.=20
>>>>>>>>>>>>>> Discovery is the wrong place to try and provide security =
against=20
>>>>>>>>>>>>>> man in the middle attacks on the RS.=20
>>>>>>>>>>>>>> This requires the client to know what the RS URI is =
before=20
>>>>>>>>>>>>>> retrieving the information on the AS Configuration.=20
>>>>>>>>>>>>>> The proposal Mike and I have been working on requires the =
client=20
>>>>>>>>>>>>>> to have a notion of what API it is looking for and =
retrieve the=20
>>>>>>>>>>>>>> .well-known file for that API from the issuer.   That =
allows a=20
>>>>>>>>>>>>>> protocol like Connect to register its own config file =
that can=20
>>>>>>>>>>>>>> point to the RS.=20
>>>>>>>>>>>>>> If the API specific well known is not available the =
client can try=20
>>>>>>>>>>>>>> the default oauth-server one.=20
>>>>>>>>>>>>>> That then allows us to deal with restricting where AT are=20=

>>>>>>>>>>>>>> presented as part of the protocol rather then dragging =
discovery=20
>>>>>>>>>>>>>> in as a requirement.=20
>>>>>>>>>>>>>> In my opinion the resource the token is targeted to =
should be=20
>>>>>>>>>>>>>> separated from the scope and returned as part of the =
meta-data=20
>>>>>>>>>>>>>> about the AT along with scopes granted and expiry time.   =
We=20
>>>>>>>>>>>>>> should also have a input parameter for resources so that =
a client=20
>>>>>>>>>>>>>> can restrict tokens issued to a subset of the ones =
granted by the=20
>>>>>>>>>>>>>> refresh token.   It would then also be possible to ask a =
AS for a=20
>>>>>>>>>>>>>> token for a unregistered RS and have the AS produce a JWT =
access=20
>>>>>>>>>>>>>> token with the resource as an audience if policy allows.=20=

>>>>>>>>>>>>>> That however was supposed to be dealt with as part of the =
mixed up=20
>>>>>>>>>>>>>> client set of mitigations.=20
>>>>>>>>>>>>>> In that the goal was to mitigate the attacks by returning=20=

>>>>>>>>>>>>>> meta-data about the tokens, and not to require discovery.=20=

>>>>>>>>>>>>>> We intend to return =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Ccleint_id=E2=80=9D for the code, and I=20
>>>>>>>>>>>>>> intend to discuss at the F2F returning resource for AT as =
well.=20
>>>>>>>>>>>>>> Those mitigate the attack.=20
>>>>>>>>>>>>>> I will continue to resist mixing up discovery of =
configuration=20
>>>>>>>>>>>>>> meta-data with mitigation of the attacks.=20
>>>>>>>>>>>>>> We return meta-data about the tokens now, because AT are =
opaque to=20
>>>>>>>>>>>>>> the client, we neglected to include some of the =
information for=20
>>>>>>>>>>>>>> the client needs to be secure.   We just need to add that =
in to=20
>>>>>>>>>>>>>> the existing flows.=20
>>>>>>>>>>>>>> While Phil=E2=80=99s proposal is easier for the AS to =
implement as an add=20
>>>>>>>>>>>>>> on, it puts more of a burden on the client needing to =
potentially=20
>>>>>>>>>>>>>> change how it stores the relationships between AS and RS =
to=20
>>>>>>>>>>>>>> prevent compromise, I think the solution should be biased =
towards=20
>>>>>>>>>>>>>> simplicity on the client side.=20
>>>>>>>>>>>>>> If we return the resources as part of the existing meta =
data the=20
>>>>>>>>>>>>>> client checks that against the resource it intends to =
send the=20
>>>>>>>>>>>>>> token to and if it is not in the list then it can=E2=80=99t=
 send the=20
>>>>>>>>>>>>>> token.  Simple check every time it gets a new AT, no =
optionality.=20
>>>>>>>>>>>>>> I am not saying anything new Nat has been advocating =
basically=20
>>>>>>>>>>>>>> this for some time, and dis submit a draft.   I prefer to =
return=20
>>>>>>>>>>>>>> the info in the existing format rather than as link =
headers,  but=20
>>>>>>>>>>>>>> that is the largest difference between what Nat and I are =
saying=20
>>>>>>>>>>>>>> with respect to resource.=20
>>>>>>>>>>>>>> That is the core of my problem with Phil=E2=80=99s draft.=20=

>>>>>>>>>>>>>> I guess we will need to have a long conversation in BA.=20=

>>>>>>>>>>>>>> Regards=20
>>>>>>>>>>>>>> John B.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt < =
phil.hunt@oracle.com =
=20
>>>>>>>>>>>>>>      =
 =
> wrote:=20
>>>>>>>>>>>>>>     This draft is a proposed alternate proposal for=20
>>>>>>>>>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the =
same=20
>>>>>>>>>>>>>>     registry for OAuth Config Metadata as the authors =
believe that=20
>>>>>>>>>>>>>>     both solutions are not required, or depending on WG =
discussion=20
>>>>>>>>>>>>>>     they will be merged. The intent is to provide a =
simple=20
>>>>>>>>>>>>>>     complete draft for consideration.=20
>>>>>>>>>>>>>>     How it works...=20
>>>>>>>>>>>>>>     Given that a client has previously discovered an =
OAuth=20
>>>>>>>>>>>>>>     protected resource, the bound configuration method =
allows a=20
>>>>>>>>>>>>>>     client to return the configuration for an oauth =
authorization=20
>>>>>>>>>>>>>>     server that can issue tokens for the resource URI =
specified by=20
>>>>>>>>>>>>>>     the client.  The AS is not required to be in the same =
domain.=20
>>>>>>>>>>>>>>      The AS is however required to know if it can issue =
tokens for=20
>>>>>>>>>>>>>>     a resource service (which presumes some agreement =
exists on=20
>>>>>>>>>>>>>>     tokens etc).=20
>>>>>>>>>>>>>>     The draft does not require that the resource exist =
(e.g. for=20
>>>>>>>>>>>>>>     unconfigured or new user based resources). It only =
requires=20
>>>>>>>>>>>>>>     that the AS service provider agrees it can issue =
tokens.=20
>>>>>>>>>>>>>>     =46rom a security perspective, returning the OAuth =
service=20
>>>>>>>>>>>>>>     configuration for a specified resource URI serves to =
confirm=20
>>>>>>>>>>>>>>     the client is in possession of a valid resource URI =
ensuring=20
>>>>>>>>>>>>>>     the client has received a valid set of endpoints for =
the=20
>>>>>>>>>>>>>>     resource and the associated oauth services.=20
>>>>>>>>>>>>>>     I propose that the WG consider the alternate draft =
carefully=20
>>>>>>>>>>>>>>     as well as other submissions and evaluate the broader=20=

>>>>>>>>>>>>>>     discovery problem before proceeding with WGLC on =
OAuth Discovery.=20
>>>>>>>>>>>>>>     Thanks!=20
>>>>>>>>>>>>>>     Phil=20
>>>>>>>>>>>>>>     @independentid=20
>>>>>>>>>>>>>>      www.independentid.com =
  =
=20
>>>>>>>>>>>>>>      phil.hunt@oracle.com =
  =
=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>         Begin forwarded message:=20
>>>>>>>>>>>>>>         *From:* =
internet-drafts@ietf.org =
=20
>>>>>>>>>>>>>>          =
 =
=20
>>>>>>>>>>>>>>         *Subject: New Version Notification for=20
>>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*=20
>>>>>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT=20
>>>>>>>>>>>>>>         *To:*"Phil Hunt" < =
phil.hunt@yahoo.com =
=20
>>>>>>>>>>>>>>          =
 =
>, "Anthony Nadalin"=20
>>>>>>>>>>>>>>         < =
tonynad@microsoft.com =
  =
>,=20
>>>>>>>>>>>>>>         "Tony Nadalin" < =
tonynad@microsoft.com =
=20
>>>>>>>>>>>>>>          =
 =
>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>         A new version of I-D, =
draft-hunt-oauth-bound-config-00.txt=20
>>>>>>>>>>>>>>         has been successfully submitted by Phil Hunt and =
posted to the=20
>>>>>>>>>>>>>>         IETF repository.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>         Name:draft-hunt-oauth-bound-config=20
>>>>>>>>>>>>>>         Revision:00=20
>>>>>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup=20
>>>>>>>>>>>>>>         Document date:2016-03-13=20
>>>>>>>>>>>>>>         Group:Individual Submission=20
>>>>>>>>>>>>>>         Pages:22=20
>>>>>>>>>>>>>>         URL:=20
>>>>>>>>>>>>>>          =
https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt=
 =

>>>>>>>>>>>>>>         Status:=20
>>>>>>>>>>>>>>          =
https://d=
atatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ =
=20
>>>>>>>>>>>>>>         Htmlized:=20
>>>>>>>>>>>>>>          =
https://tool=
s.ietf.org/html/draft-hunt-oauth-bound-config-00 =
=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>         Abstract:=20
>>>>>>>>>>>>>>           This specification defines a mechanism for the =
client of=20
>>>>>>>>>>>>>>         an OAuth 2.0=20
>>>>>>>>>>>>>>           protected resource service to obtain the =
configuration=20
>>>>>>>>>>>>>>         details of an=20
>>>>>>>>>>>>>>           OAuth 2.0 authorization server that is capable =
of=20
>>>>>>>>>>>>>>         authorizing access=20
>>>>>>>>>>>>>>           to a specific resource service.  The =
information=20
>>>>>>>>>>>>>>         includes the OAuth=20
>>>>>>>>>>>>>>           2.0 component endpoint location URIs and as =
well as=20
>>>>>>>>>>>>>>         authorization=20
>>>>>>>>>>>>>>           server capabilities.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>         Please note that it may take a couple of minutes =
from the=20
>>>>>>>>>>>>>>         time of submission=20
>>>>>>>>>>>>>>         until the htmlized version and diff are available=20=

>>>>>>>>>>>>>>         attools.ietf.org  =
 .=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>         The IETF Secretariat=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>     _______________________________________________=20
>>>>>>>>>>>>>>     OAuth mailing list=20
>>>>>>>>>>>>>>      OAuth@ietf.org =
  =20=

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

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

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


--Apple-Mail=_2E284206-9932-46EB-A190-327B6183F73B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

If the AS is audience restricting the tokens then it just =
needs to put the right audience in the token based on what the client is =
asking for.  
    That is safe as the RS wouldn=E2=80=99t =
be able to replay the token someplace else.

    That would need to be a AS policy if it =
wanted to do that for unknown RS.   

    Allowing more than one audience in a =
token is a convince but a well known security risk with bearer =
tokens.

    A AS =
would probably want to have only one audience in a AT for a untrusted =
RS, but may allow multiple if they are all trusted.

    John B.


    On =
Mar 15, 2016, at 6:28 PM, George Fletcher <gffletch@aol.com> =
wrote:

    
 =20
    
 =20
  
    
    
    
    
    On 3/15/16 3:26 PM, John Bradley =
wrote:
    
    
    
    
    
      
      I think Phil and others are concerned that a developer might get
      bad info to put in the client , some out of band discovery goes
      wrong or the user is somehow tricked into specifying a bad
      resource to the client.
      

    
      
    
      
    So getting a bad resource is a touch hypothetical. =

    
      
    
    
    
    If we are really trying to solve this problem holistically, then we
    probably need to first describe the use cases we want to solve. I'm
    starting to wonder if we are all providing solutions to slightly
    different use cases.
    
    
    
      

    
      
    
      
    For Connect we could suppose that someone =
publishes
        a malicious discovery document listing themselves as the RS but
        all the other endpoints are at the good AS so the client
        registers, authorizes the user and gives the AT to the bad guy.
         The confused client mitigation by returning client_id_and
        issuer from the authorization endpoint will stop the attack
        before the token can be given to the token endpoint or RS.
    
    
    
    Agreed and I'm fine with this solution.
    
    
    
      

    
      
    
      
    So protecting the AT at this point is more for a
        unknown attack that would confuse whatever protocol/API that is
        using OAuth about what RS to use.
    
    
    
    Yes. This is where we need to describe some use cases (preferably
    real vs contrived) before we propose solutions. In most cases the RS
    endpoints are hard coded into the client or maybe pulled from a
    different central config endpoint (which is fixed).
    
    
    
    That's why the only case I could think of is a client that works
    with multiple RS endpoints from different providers that server the
    same content (e.g. PortableContacts API). In this use case, the user
    of the client would need to enter the location of the RS they wanted
    to use and then the flow would start from there. In reality, most
    services like this would have a fixed set of RS's they work with and
    again it wouldn't be dynamic.
    
    
    
      

    
      
    
      
    In reality this is what PoP is supposed to be =
for.
    
      

    
      
    
      
    I guess the question is what short of PoP can we =
do
        to prevent the client leaking tokens to bad RS that confuse it
        via the application protocol.
    
      

    
      
    
      
    If we want to del with this in OAuth then we need =
to
        tell the AS where the token is going to be used or tel the
        client where the token can be used. 
    
      

    
      
    
      
    I think letting the client tell the AS where it
        wants the token used having the AS construct a audience out of
        that is probably the best thing.  to get around having a
        pre-established relationship between the AS and RS.
    
    
    
    Even if the client tells the AS where it wants to use the token (via
    some endpoint URL), the AS still needs to have a relationship with
    the RS (at a minimum as an endpointURL-to-RS map) otherwise how can
    it determine if it is allowed to issue an access token to the user
    for that RS. This map is what I want to avoid "building" into the
    AS. Do we need "dynamic RS registration" to support this?
    
    
    
    
    
      

    
      
    
      
    John B.
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 3:14 PM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            

    
                
    
                I think Justin provided a good break down of the
                different aspects a client wants to specify about the
                requested token. (my paraphrase)
    
                  1. what RS's the token will be used at
    
                  2. authorization privilege requests
    
                  3. token-timing adjustments
    
                
    
                I'm not sure passing the full endpoint to the AS will
                help with my concerns... The AS could potentially do a
                webfinger on the resource URI and determine if it's an
                RS that it supports... though that requires all RS's to
                support webfinger. What I really want to avoid is the AS
                having this list of URIs to RS that is almost assuredly
                to get out of sync.
    
                
    
                
    
              
    
              
    On 3/15/16 1:56 PM, John Bradley
                wrote:
    
              
    
              
    I =
think
                it is a AS policy decision if it should error or take
                the requested resource and issue a token audianced for
                that resource.
    
              Actually, the error cases are interesting.
                What if the passed in resource/audience doesn't actually
                match a requested scope? Or some match and some don't?
                Is it better to send back a token with less capability?
                or error the entire request?
              
    
                

    
                
    
                
    I guess the question is how to =
transition
                  from now to a future state.   If you cannot =
upgrade
                  all the clients at once.
    
                

    
                
    
                
    A processing rule on the AS that allowed
                  some clients to not send the requested resource , but
                  would error out for other upgraded clients  with =
a
                  "resource not allowed=E2=80=9D oauth error would work =
and not
                  require the return of the resources.  
    
                

    
                
    
                
    If you return the resources and let the
                  client error if it is trying to send to the wrong
                  endpoint that make upgrading easier, but gives less
                  control to the AS.
    
                

    
                
    
                
    
                  
    
                    
    I could live with =
it
                        ether way.
    
                    

    
                    
    
                    The advantage of always sending it in the token
                    request is that it allows the AS to do the mapping
                    from a resource URI to one or more abstract audience
                    for the token.
    
                
    
              
    
              I thought Justin provided a good break down
                of the different aspects a client wants to specify about
                the requested token. (my paraphrase)
    
                  1. what RS's the token will be used at
    
                  2. authorization privilege requests
    
                  3. token-timing adjustments
    
                
    
                The question is how does a client internally reference a
                resource server? If it's a fixed RS endpoint, then it
                sort of doesn't matter, the client isn't going to send
                the token to the wrong endpoint anyway and it can easily
                reference the audience by an abstract URI.
    
                
    
                If the client can dynamically find new RS's to interact
                with. How does that happen? Does the client get handed
                an endpoint to use? or does it do some sort of discovery
                to determine the endpoint? I suppose both are =
possible.
    
                
    
                Could we prescribe that the realm value of RFC 6750
                error response be effectively a resource-service-id
                (like issuer for the AS). The client would then need to
                do discovery on that value to find the valid endpoints
                of the RS. This could be done once and the
                resource-service-id could be used as the "abstract" RS
                identifier. This requires no more discovery than adding
                an AS to the client.
    
                  
              
    
                
    
                  

    
                  
    
                  
    That might help address George=E2=80=99s=

                    concern.
    
                
    
              
    
              I'm not sure passing the full endpoint to
                the AS will help with my concerns... The AS could
                potentially do a webfinger on the resource URI and
                determine if it's an RS that it supports... though that
                requires all RS's to support webfinger. What I really
                want to avoid is the AS having this map of URIs to RS
                that is almost assuredly to get out of sync.
              
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                  
    
                  

    
                    
    
                      
    On Mar 15, 2016, at 2:44 PM, Brian
                        Campbell <bcampbell@pingidentity.com>
                        wrote:
    
                      
    
                      
    
                        
    I was thinking it'd =
be
                          simpler to error, if the requested resource(s)
                          weren't okay. That puts the burden of checking
                          in the AS. And doesn't add anything to the
                          token or authorization response. I see the
                          potential similarity to scope but not sure
                          it's worth it.    
    
                        

    
                          
    On Tue, Mar 15, =
2016
                            at 11:37 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    
                            
    
                              
    If the client specifies the
                                resource it wants the token for, then
                                the meta-data would not be required
                                unless the resources the token is good
                                at are different from the request. =
 
                                
    Lat is the same logic as
                                  scopes.
    
                                

    
                                
    
                                
    For backwards
                                  compatibility if the client is happy
                                  with the default resources based on
                                  scopes then I think it is a good idea
                                  to tell the client what the resources
                                  are in the response.
    
                                

    
                                
    
                                
    I suspect that it is
                                  simpler with less optionality and
                                  always return the resources, even if
                                  they are not required.
    
                                

    
                                
    
                                
    John B.
    
                                
    
                                  
    
                                    

    
                                    
    
                                    
    
                                      
    
                                        
    
                                          
    On Mar 15, =
2016,
                                            at 12:46 PM, Brian Campbell
                                            <bcampbell@pingidentity.com&=
gt;
                                            wrote:
    
                                          
    
                                          
    
                                            
    If=

                                              the client specifies the
                                              desired
                                              audience(s)/resource(s),
                                              is that metadata to the
                                              client needed? The AS can
                                              audience restrict the
                                              token as needed or respond
                                              with an error if it can't
                                              or wont issue a token for
                                              the resource the client
                                              asked for. 
    
                                              
    
                                                
    
                                                  

    
                                                    
    On
                                                      Tue, Mar 15, 2016
                                                      at 9:37 AM, John
                                                      Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                                      
    
                                                        
    Yes,
                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The
                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          =
audience.
    
                                                          

    
                                                          
    
                                                          
    If
                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is =
leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over =
time. 
    
                                                          

    
                                                          
    
                                                          
    In
                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require =
Phil=E2=80=99s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          =
discovery.
    
                                                          
      
    
                                                          
    If
                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.  =
That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          =
spoofing.
    
                                                          
    William
                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John
                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    =

                                                          
    
                                                          
    On
                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher =
<gffletch@aol.com>
                                                          wrote:
    
                                                          
    
                                                          
    =

                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          =
communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    =

                                                          

    
                                                          
    On
                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          =
unambiguously 
    
                                                          
    
                                                          Hans. 
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: 
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty, 
    
                                                          it=E2=80=99s =
not even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases =E2=80=
=94
                                                          it=E2=80=99s 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          =
distribution 
    
                                                          mechanism in
                                                          that =
case. 
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think =
we=E2=80=99ve
                                                          really 
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded =
into 
    
                                                          =E2=80=9Cscope=E2=
=80=9D that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: 
    
                                                          
    
                                                          
    
                                                            -
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile) 
    
                                                            -
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, =
delete) 
    
                                                            -
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? 
    
                                                          =
(offline_access/refresh_token,
                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          =
audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token 
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. 
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched =
in 
    
                                                          with things
                                                          like
                                                          =
=E2=80=9Coffline_access=E2=80=9D
                                                          in certain
                                                          APIs. 
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we=E2=80=99re =
going to
                                                          be adding
                                                          things 
    
                                                          like
                                                          =E2=80=9Caudienc=
e=E2=80=9D or
                                                          =E2=80=9Cresourc=
e=E2=80=9D or
                                                          both to the
                                                          token
                                                          requests. 
    
                                                          
    
                                                            =E2=80=94
                                                          Justin 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>=

                                                          wrote: 
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify 
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid =
for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked =
about 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. 
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are 
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid =
making 
    
                                                          a mess of
                                                          scopes. 
    
                                                          
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                          
    
                                                          Inline 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <    ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>=

                                                          wrote: 
    
                                                          
    
                                                          
    We
                                                          had two
                                                          =
mandates.  One
                                                          was to provide
                                                          a spec for AS
                                                          metadata. 
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup =
attack. 
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don=E2=80=99t 
    
                                                          otherwise need
                                                          =
discovery. 
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint 
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without 
    
                                                          =
discovery. 
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking =
to 
    
                                                          the wrong
                                                          endpoint? 
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded =
probably 
    =

                                                          doesn=E2=80=99t =
need
                                                          =
discovery. 
    
                                                          
    
                                                          We agree 
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to =
find 
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before =
getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          =
conflating 
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives 
    
                                                          what the
                                                          resource =
is. 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are =
not 
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service. 
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have 
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. 
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have =
IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is =
but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process. 
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          =
production. 
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is =
correctly 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. 
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS =
doesn=E2=80=99t
                                                          know all =
the 
    
                                                          possible =
RS.  
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can 
    
                                                          address. 
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify =
them. 
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple =
RS 
    
                                                          endpoints
                                                          =
intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request 
    
                                                          for each
                                                          endpoint. 
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of =
AS 
    
                                                          servers
                                                          assigned to
                                                          each =
instance? 
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner 
    
                                                          are.  I =
think
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. 
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          =
endpoints. 
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If =
a 
    
                                                          client =
chooses evil.com <http://evil.com/> the cert can be valid =
and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk =
to 
    
                                                          res.example.com <http://res.example.com/>? 
    
                                                          

    
                                                          If this is
                                                          added to the
                                                          token endpoint
                                                          it would be
                                                          checked when
                                                          code 
    
                                                          or refresh are
                                                          exchanged, not
                                                          every time the
                                                          token is =
used. 
    
                                                          
    
                                                          Your proposal
                                                          requires rhe
                                                          client to
                                                          check. I am
                                                          not clear how
                                                          the AS 
    
                                                          can know the
                                                          exact uri. It
                                                          is far easier
                                                          to validate
                                                          than to =
lookup 
    
                                                          since as you
                                                          say the client
                                                          may be
                                                          authorized to
                                                          use multiple
                                                          ASs. 
    
                                                          
    With
                                                          a out of band
                                                          check the
                                                          client would
                                                          never know if
                                                          a RS was 
    
removed/revoked. 
    
                                                          
    
                                                          
    
                                                          Not sure that
                                                          is in =
scope. 
    
                                                          
    
                                                          None of the
                                                          current
                                                          proposals
                                                          address this
                                                          issue. 
    
                                                          

    
                                                          I don=E2=80=99t =
see
                                                          checking when
                                                          refreshing a
                                                          token as
                                                          something that
                                                          is a 
    
                                                          huge =
burden. 
    
                                                          
    
                                                          
    
                                                          Still its a
                                                          lot more than
                                                          once. 
    
                                                          
    
                                                          Why don't you
                                                          draft another
                                                          =
alternative? 
    
                                                          

    
                                                          If the server
                                                          wants to do
                                                          the check on
                                                          it=E2=80=99s =
side then
                                                          we could 
    
                                                          require the
                                                          client to send
                                                          the RS URI in
                                                          the token
                                                          request. that
                                                          way 
    
                                                          you really
                                                          know the
                                                          client is not
                                                          going to get a
                                                          token for the
                                                          wrong 
    
                                                          RS =
endpoint. 
    
                                                          If you check
                                                          out of band in
                                                          discovery you
                                                          really have no
                                                          idea if =
the 
    
                                                          client is
                                                          checking. 
    
                                                          
    
                                                          
    
                                                          In the new
                                                          webfinger
                                                          draft, the
                                                          client isn't
                                                          checking. The
                                                          service 
    
                                                          provider
                                                          simply does
                                                          not disclose
                                                          oauth
                                                          information to
                                                          =
misconfigured 
    
                                                          clients. 
    
                                                          

    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 3:56 PM,
                                                          Phil Hunt =
<phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                          
    
                                                          Thanks to Mike
                                                          and John for
                                                          their
                                                          =
feedback. 
                                                          I=E2=80=99ll =
take each
                                                          in turn: 
    
                                                          
    
                                                          Mike, 
    
                                                          
    
                                                          Regarding your
                                                          suggested
                                                          =
amendments 
    
                                                          
    
                                                          Item 1:
                                                          Returning the
                                                          config URL
                                                          would create
                                                          two problems.
                                                          One,it 
    
                                                          makes bound
                                                          discovery a
                                                          two-step
                                                          process - that
                                                          adds
                                                          =
complexity. 
    
                                                           It seems =
far
                                                          simpler to
                                                          mandate TLS
                                                          (which I think
                                                          it already
                                                          does 
    
                                                          in the
                                                          security
                                                          =
considerations). 
    
                                                          
    
                                                          The two-step
                                                          process allows
                                                          the current
                                                          discovery
                                                          process =
to 
    
                                                          continue. I
                                                          disagree with
                                                          this. This is
                                                          why I put
                                                          forward =
an 
    
                                                          =E2=80=9Calterna=
te"
                                                          draft that is
                                                          almost the
                                                          same but
                                                          simply adds
                                                          the check 
    
                                                          before
                                                          returning the
                                                          configuration
                                                          data.  I =
worry
                                                          that 
                                                          =
developers 
    
                                                          would have no
                                                          incentive to
                                                          do the
                                                          two-step
                                                          approach. They
                                                          would 
    
                                                          just start at
                                                          step 2 which
                                                          in turn puts
                                                          AS=E2=80=99s =
at risk
                                                          of =
exposing 
    =

                                                          tokens because
                                                          it works. This
                                                          makes OAuth
                                                          =
promiscuous. 
    
                                                          
    
                                                          Regarding
                                                          existing
                                                          =
implementations.
                                                          Most of those
implementations 
    
                                                          are for =
OIDC. 
                                                          I think it
                                                          makes sense
                                                          for OIDF to
                                                          continue use
                                                          of 
    
                                                          OIDC's
                                                          discovery spec
                                                          because the
                                                          UserInfo
                                                          endpoint is
                                                          well =
defined 
    
                                                          and the
                                                          likelihood of
                                                          a client
                                                          mis-informed
                                                          about the
                                                          resource 
    
                                                          endpoint is
                                                          not =
there. 
                                                          IMO This does
                                                          not apply to
                                                          the =
broader 
    
                                                          OAuth
                                                          =
community. 
    
                                                          
    
                                                          Item 2:  =
It
                                                          may be
                                                          appropriate to
                                                          have a
                                                          separate
                                                          =
configuration 
    
                                                          registry
                                                          specification,
                                                          but I think we
                                                          should hold
                                                          off until =
we 
    
                                                          have a
                                                          complete
                                                          solution and
                                                          then make the
                                                          decision what
                                                          drafts 
    
                                                          should exist
                                                          and how many
                                                          pieces.  =
A big
                                                          concern is the
                                                          perceived 
    
                                                          complexity of
                                                          multiple
                                                          solutions and
                                                          multiple
                                                          drafts. 
    
                                                          
    
                                                          As to John
                                                          Bradley=E2=80=99=
s
                                                          comments: 
    
                                                          
    
                                                          Re: Discovery
                                                          is the wrong
                                                          place to
                                                          mitigate
                                                          threats. 
    
                                                          I=E2=80=99m =
confused
                                                          by this.  =
Our
                                                          mandate was to
                                                          solve a
                                                          security
                                                          threat 
    
                                                          by having a
                                                          discovery
                                                          specification
                                                          to prevent
                                                          clients =
being 
    
                                                          mis-lead about
                                                          endpoints (of
                                                          which resource
                                                          service is
                                                          one) in =
an 
    
                                                          oauth
                                                          protected
                                                          =
exchange. 
                                                          Maybe what you
                                                          mean is we
                                                          should not =
use 
    
                                                          .well-known of
                                                          any kind and
                                                          we should just
                                                          create a
                                                          =
=E2=80=9C/Config=E2=80=9D 
    
                                                          endpoint to
                                                          OAuth? 
    
                                                          
    
                                                          Re: Your
                                                          proposal for
                                                          MITM
                                                          =
mitigation 
    
                                                          You propose
                                                          that instead
                                                          the resource
                                                          endpoint check
                                                          should be =
in 
    
                                                          the oauth
                                                          protocol
                                                          itself.  =
The
                                                          difference is
                                                          that
                                                          validation =
is 
    
                                                          transferred
                                                          back to the
                                                          client to get
                                                          it right. As
                                                          well, =
without 
    
                                                          the client
                                                          informing the
                                                          AS, I can=E2=80=99=
t
                                                          see a way for
                                                          the AS to =
know 
    
                                                          what endpoint
                                                          the client is
                                                          using.  =
The
                                                          webfinger
                                                          approach =
does 
    
                                                          this once and
                                                          only requires
                                                          that the host
                                                          name be
                                                          checked in
                                                          many 
    
                                                          cases. 
    
                                                          
    
                                                          As a
                                                          principle, the
                                                          members have
                                                          discussed many
                                                          times that the
                                                          AS 
    
                                                          service should
                                                          do validation
                                                          when possible
                                                          =E2=80=94 this =
was
                                                          =
particularly 
    
                                                          true at the
                                                          Germany
                                                          meeting when
                                                          this came up.
                                                          This is why I
                                                          prefer 
    
                                                          the client
                                                          tell the
                                                          service
                                                          provider what
                                                          it intends to
                                                          do and =
the 
    
                                                          service
                                                          provider can
                                                          fail that
                                                          request
                                                          immediately if
                                                          necessary. =
We 
    
                                                          don=E2=80=99t =
have to
                                                          depend on the
                                                          developer
                                                          getting the
                                                          spec correct
                                                          to 
    
                                                          fail the
                                                          correct =
way. 
    
                                                          
    
                                                          I worry that
                                                          adding more
                                                          parameters to
                                                          the authz and
                                                          token =
protocol 
    =

                                                          flows
                                                          increases
                                                          complexity and
                                                          attack
                                                          surface. It
                                                          also means =
per 
    
                                                          authorization
                                                          validation has
                                                          to take place
                                                          vs. a =
one-time 
    =

                                                          validation at
                                                          config =
time. 
                                                          Placing it in
                                                          the
                                                          configuration
                                                          lookup 
    
                                                          phase (whether
                                                          via web finger
                                                          or just a
                                                          special OAuth
                                                          endpoint) 
    
                                                          seems more
                                                          appropriate
                                                          and far less
                                                          complex - as
                                                          the request
                                                          itself 
    
                                                          is simple and
                                                          has only one
                                                          parameter.
                                                          Here we are
                                                          not =
considered 
    
                                                          about
                                                          legitimacy of
                                                          the client.
                                                          we=E2=80=99re =
just
                                                          concerned with
                                                          the issue 
    
                                                          "has the
                                                          client been
                                                          correctly
                                                          =
informed?=E2=80=9D 
    
                                                          
    
                                                          That said, it
                                                          may be that
                                                          when we
                                                          consider all
                                                          the use cases,
                                                          some 
    
                                                          combination of
                                                          AS protocol
                                                          and discovery
                                                          may be both
                                                          needed. =
I=E2=80=99m 
    
                                                          not ready to
                                                          make
                                                          conclusions
                                                          about =
this. 
                                                          The =
current 
    
                                                          =
oauth-discovery
                                                          spec seems to
                                                          put future
                                                          generic
                                                          clients at
                                                          risk 
    
                                                          and that is my
                                                          primary
                                                          concern. 
    
                                                          
    
                                                          Best =
Regards, 
    =

                                                          
    
                                                          Phil 
    
                                                          
    
                                                          =
@independentid 
    
                                                              www.independentid.com <http://www.independentid.com/&g=
t; 
    
                                                          phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 13, 2016,
                                                          at 10:28 PM,
                                                          Mike =
Jones 
    
                                                          <    Michael.Jones@microsoft.com <mailto:Michael.Jones@micro=
soft.com>> 
                                                          wrote: 
    
                                                          
    
                                                          Thanks for
                                                          posting this,
                                                          Phil.  It
                                                          provides a
                                                          concrete
                                                          example =
of 
    
                                                          a way that
                                                          protected
                                                          resource
                                                          discovery
                                                          could be added
                                                          to 
    
                                                          authorization
                                                          server
                                                          metadata
                                                          discovery, and
                                                          as such,
                                                          should 
    
                                                          provide useful
                                                          input for
                                                          working group
                                                          discussions on
                                                          this =
topic. 
    
                                                          It=E2=80=99s =
always
                                                          great when
                                                          someone takes
                                                          the time to
                                                          write an
                                                          actual 
    
                                                          draft that can
                                                          be examined
                                                          and
                                                          implemented,
                                                          and I
                                                          appreciate =
you 
    
                                                          doing =
that. 
    
                                                          The content of
                                                          your draft
                                                          points out
                                                          that there
                                                          appears to =
be 
    
                                                          complete
                                                          agreement on
                                                          what the
                                                          authorization
                                                          server
                                                          metadata 
    
                                                          format should
                                                          be, which is
                                                          great!  =
I=E2=80=99ll
                                                          note that
                                                          Section 3 =
of 
    
                                                          =
draft-hunt-oauth-bound-config-00
                                                          titled
                                                          =
=E2=80=9CAuthorization
                                                          Server 
    
                                                          Metadata=E2=80=9D=
 is
                                                          an exact copy
                                                          of Section 2
                                                          of 
    
                                                          =
draft-ietf-oauth-discovery-01
                                                          (with the same
                                                          title), =
modulo 
    
                                                          applying a
                                                          correction
                                                          suggested by
                                                          the working
                                                          group.  =
To me
                                                          this 
    
                                                          suggests that
                                                          the
                                                          authorization
                                                          server
                                                          metadata
                                                          definitions =
in 
    
                                                          =
draft-ietf-oauth-discovery
                                                          (which is now
                                                          the whole
                                                          normative 
    
                                                          content of the
                                                          draft) are
                                                          clearly ready
                                                          for
                                                          =
standardization,
                                                          since 
    
                                                          even your
                                                          alternative
                                                          proposal
                                                          includes them
                                                          verbatim. 
    
                                                          Reading your
                                                          draft, the
                                                          problem I have
                                                          with it is
                                                          that you =
are 
    
                                                          returning the
                                                          AS metadata
                                                          only as a
                                                          WebFinger
                                                          response,
                                                          rather 
    
                                                          than as an
                                                          =
https-protected
                                                          resource
                                                          published by
                                                          the
                                                          =
authorization 
    
                                                          server.  =
The
                                                          choice to only
                                                          return this
                                                          via WebFinger
                                                          makes =
your 
    
                                                          draft
                                                          incompatible
                                                          with most
                                                          deployed
                                                          =
implementations
                                                          of OAuth 
    
                                                          metadata,
                                                          including the
                                                          22
                                                          =
implementations
                                                          using it
                                                          listed 
    
                                                          athttp://openid.net/certification/(see
                                                          the =E2=80=9COP
                                                          Config=E2=80=9D =
column
                                                          in 
    
                                                          the table)
                                                          andOAuth 2.0
                                                          libraries such
                                                          as =
Microsoft=E2=80=99s
                                                          =
=E2=80=9CADAL=E2=80=9D 
    
                                                          library, which
                                                          uses the
                                                          metadata path
                                                          for client
                                                          =
configuration. 
    
                                                          Without having
                                                          ASs provide
                                                          the metadata
                                                          as an
                                                          =
https-protected 
    
                                                          resource,
                                                          =
implementations
                                                          such as ADAL
                                                          can=E2=80=99t =
use it
                                                          for =
client 
    
                                                          configuration
                                                          as the
                                                          currently =
do. 
    
                                                          Therefore, I
                                                          would request
                                                          that you make
                                                          these minor
                                                          revisions =
to 
    
                                                          your draft and
                                                          republish, so
                                                          as to provide
                                                          a unified way
                                                          forward 
    
                                                          that is
                                                          compatible
                                                          with all known
                                                          existing OAuth
                                                          Discovery 
    
                                                          =
deployments: 
    
                                                          1.Modify your
                                                          section 2
                                                          =
=E2=80=9CAuthorization
                                                          Server
                                                          WebFinger
                                                          =
Discovery=E2=80=9D 
    
                                                          to have the
                                                          WebFinger
                                                          request return
                                                          the issuer
                                                          identifier for
                                                          the 
    
                                                          AS as the
                                                          =E2=80=9CWebFing=
er
                                                          =E2=80=9Crel=E2=80=
=9D value,
                                                          rather than
                                                          returning =
the 
    
                                                          metadata
                                                          values by
                                                          value as the
                                                          =
=E2=80=9Cproperties=E2=80=9D
                                                          value. 
    
                                                          2.Reference
                                                          the metadata
                                                          definitions
                                                          from Section 2
                                                          of 
    
                                                          =
draft-ietf-oauth-discovery,
                                                          rather than
                                                          duplicating
                                                          them in =
your 
    
                                                          Section =
3. 
    
                                                          That would
                                                          have the
                                                          advantage of
                                                          paring your
                                                          draft down to
                                                          only 
    
                                                          the new things
                                                          that it
                                                          proposes,
                                                          enabling them
                                                          to be more
                                                          clearly 
    
                                                          understood and
                                                          evaluated on
                                                          their own
                                                          merits.  =
I
                                                          look forward
                                                          to 
    
                                                          the
                                                          discussions of
                                                          ways of
                                                          performing
                                                          additional
                                                          kinds of =
OAuth 
    
                                                          discovery, and
                                                          consider your
                                                          draft a
                                                          valuable input
                                                          to those 
    
                                                          =
discussions. 
    
=
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;        Best
                                                          wishes, 
    
=
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;        --
                                                          Mike 
    
                                                          *From:*OAuth =
[mailto:oauth-bounces@ietf.org]*=
On
                                                          Behalf Of*John
                                                          Bradley 
    
                                                          *Sent:*Sunday,
                                                          March 13, 2016
                                                          6:45 PM 
    
                                                          *To:*Phil Hunt
                                                          <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> 
    
                                                          *Cc:*oauth
                                                          <    oauth@ietf.org <mailto:oauth@ietf.org>> 
    
                                                          *Subject:*Re:
                                                          [OAUTH-WG] New
                                                          Version
                                                          Notification
                                                          for 
    
draft-hunt-oauth-bound-config-00.txt 
    
                                                          As I have told
                                                          Phil off =
list. 
    
                                                          Discovery is
                                                          the wrong
                                                          place to try
                                                          and provide
                                                          security
                                                          against 
    
                                                          man in the
                                                          middle attacks
                                                          on the =
RS. 
    
                                                          This requires
                                                          the client to
                                                          know what the
                                                          RS URI is
                                                          before 
    
                                                          retrieving the
                                                          information on
                                                          the AS
                                                          =
Configuration. 
    
                                                          The proposal
                                                          Mike and I
                                                          have been
                                                          working on
                                                          requires the
                                                          client 
    
                                                          to have a
                                                          notion of what
                                                          API it is
                                                          looking for
                                                          and retrieve
                                                          the 
    
                                                          .well-known
                                                          file for that
                                                          API from the
                                                          =
issuer.   That
                                                          allows a 
    
                                                          protocol like
                                                          Connect to
                                                          register its
                                                          own config
                                                          file that =
can 
    
                                                          point to the
                                                          RS. 
    
                                                          If the API
                                                          specific well
                                                          known is not
                                                          available the
                                                          client can =
try 
    
                                                          the default
                                                          oauth-server
                                                          one. 
    
                                                          That then
                                                          allows us to
                                                          deal with
                                                          restricting
                                                          where AT =
are 
    
                                                          presented as
                                                          part of the
                                                          protocol
                                                          rather then
                                                          dragging
                                                          discovery 
    
                                                          in as a
                                                          =
requirement. 
    
                                                          In my opinion
                                                          the resource
                                                          the token is
                                                          targeted to
                                                          should be 
    
                                                          separated from
                                                          the scope and
                                                          returned as
                                                          part of the
                                                          meta-data 
    
                                                          about the AT
                                                          along with
                                                          scopes granted
                                                          and expiry
                                                          =
time.   We 
                                                          should also
                                                          have a input
                                                          parameter for
                                                          resources so
                                                          that a =
client 
    
                                                          can restrict
                                                          tokens issued
                                                          to a subset of
                                                          the ones
                                                          granted by =
the 
    
                                                          refresh
                                                          =
token.   It
                                                          would then
                                                          also be
                                                          possible to
                                                          ask a AS for =
a 
    
                                                          token for a
                                                          unregistered
                                                          RS and have
                                                          the AS produce
                                                          a JWT =
access 
    
                                                          token with the
                                                          resource as an
                                                          audience if
                                                          policy =
allows. 
    
                                                          That however
                                                          was supposed
                                                          to be dealt
                                                          with as part
                                                          of the mixed
                                                          up 
    
                                                          client set of
                                                          =
mitigations. 
    
                                                          In that the
                                                          goal was to
                                                          mitigate the
                                                          attacks by
                                                          returning 
    
                                                          meta-data
                                                          about the
                                                          tokens, and
                                                          not to require
                                                          =
discovery. 
    
                                                          We intend to
                                                          return =
=E2=80=9Ciss=E2=80=9D
                                                          and
                                                          =
=E2=80=9Ccleint_id=E2=80=9D
                                                          for the code,
                                                          and I 
    
                                                          intend to
                                                          discuss at the
                                                          F2F returning
                                                          resource for
                                                          AT as =
well. 
    
                                                          Those mitigate
                                                          the =
attack. 
    
                                                          I will
                                                          continue to
                                                          resist mixing
                                                          up discovery
                                                          of
                                                          =
configuration 
    
                                                          meta-data with
                                                          mitigation of
                                                          the =
attacks. 
    =

                                                          We return
                                                          meta-data
                                                          about the
                                                          tokens now,
                                                          because AT are
                                                          opaque to 
    
                                                          the client, we
                                                          neglected to
                                                          include some
                                                          of the
                                                          information
                                                          for 
    
                                                          the client
                                                          needs to be
                                                          =
secure.   We
                                                          just need to
                                                          add that in =
to 
    
                                                          the existing
                                                          flows. 
    
                                                          While Phil=E2=80=
=99s
                                                          proposal is
                                                          easier for the
                                                          AS to
                                                          implement as
                                                          an add 
    
                                                          on, it puts
                                                          more of a
                                                          burden on the
                                                          client needing
                                                          to =
potentially 
    
                                                          change how it
                                                          stores the
                                                          relationships
                                                          between AS and
                                                          RS to 
    
                                                          prevent
                                                          compromise, I
                                                          think the
                                                          solution
                                                          should be
                                                          biased =
towards 
    
                                                          simplicity on
                                                          the client
                                                          side. 
    
                                                          If we return
                                                          the resources
                                                          as part of the
                                                          existing meta
                                                          data the 
    
                                                          client checks
                                                          that against
                                                          the resource
                                                          it intends to
                                                          send the 
    
                                                          token to and
                                                          if it is not
                                                          in the list
                                                          then it =
can=E2=80=99t
                                                          send the 
    
                                                          token.  =
Simple
                                                          check every
                                                          time it gets a
                                                          new AT, no
                                                          =
optionality. 
    
                                                          I am not
                                                          saying
                                                          anything new
                                                          Nat has been
                                                          advocating
                                                          basically 
    
                                                          this for some
                                                          time, and dis
                                                          submit a
                                                          =
draft.   I
                                                          prefer to
                                                          return 
    
                                                          the info in
                                                          the existing
                                                          format rather
                                                          than as link
                                                          headers,  =
but 
    
                                                          that is the
                                                          largest
                                                          difference
                                                          between what
                                                          Nat and I are
                                                          saying 
    
                                                          with respect
                                                          to =
resource. 
    
                                                          That is the
                                                          core of my
                                                          problem with
                                                          Phil=E2=80=99s =
draft. 
    
                                                          I guess we
                                                          will need to
                                                          have a long
                                                          conversation
                                                          in BA. 
    
                                                          Regards 
    
                                                          John B. 
    
                                                          
    
                                                          =
    On
                                                          Mar 13, 2016,
                                                          at 8:12 PM,
                                                          Phil Hunt =
<phil.hunt@oracle.com 
    
                                                          =
    <mailto:phil.hunt@oracle.com>>
                                                          wrote: 
    
                                                          =
    This
                                                          draft is a
                                                          proposed
                                                          alternate
                                                          proposal =
for 
    
                                                          =
    draft-ietf-oauth-discovery.&n=
bsp;
                                                          As such, it
                                                          contains the
                                                          same 
    
                                                          =
    registry
                                                          for OAuth
                                                          Config
                                                          Metadata as
                                                          the authors
                                                          believe =
that 
    
                                                          =
    both
                                                          solutions are
                                                          not required,
                                                          or depending
                                                          on WG
                                                          =
discussion 
    
                                                          =
    they
                                                          will be
                                                          merged. The
                                                          intent is to
                                                          provide a
                                                          simple 
    
                                                          =
    complete
                                                          draft for
                                                          =
consideration. 
    
                                                          =
    How
                                                          it =
works... 
    =

                                                          =
    Given=

                                                          that a client
                                                          has previously
                                                          discovered an
                                                          OAuth 
    
                                                          =
    protected
                                                          resource, the
                                                          bound
                                                          configuration
                                                          method allows
                                                          a 
    
                                                          =
    client
                                                          to return the
                                                          configuration
                                                          for an oauth
                                                          =
authorization 
    
                                                          =
    server
                                                          that can issue
                                                          tokens for the
                                                          resource URI
                                                          specified =
by 
    
                                                          =
    the
                                                          client.  =
The
                                                          AS is not
                                                          required to be
                                                          in the same
                                                          domain. 
    
                                                          =
     The
                                                          AS is however
                                                          required to
                                                          know if it can
                                                          issue tokens
                                                          for 
    
                                                          =
    a
                                                          resource
                                                          service (which
                                                          presumes some
                                                          agreement
                                                          exists on 
    
                                                          =
    tokens
                                                          etc). 
    
                                                          =
    The
                                                          draft does not
                                                          require that
                                                          the resource
                                                          exist (e.g.
                                                          for 
    
                                                          =
    unconfigured
                                                          or new user
                                                          based
                                                          resources). It
                                                          only =
requires 
    =

                                                          =
    that
                                                          the AS service
                                                          provider
                                                          agrees it can
                                                          issue =
tokens. 
    
                                                          =
    From
                                                          a security
                                                          perspective,
                                                          returning the
                                                          OAuth =
service 
    
                                                          =
    configuration
                                                          for a
                                                          specified
                                                          resource URI
                                                          serves to
                                                          confirm 
    
                                                          =
    the
                                                          client is in
                                                          possession of
                                                          a valid
                                                          resource URI
                                                          ensuring 
    
                                                          =
    the
                                                          client has
                                                          received a
                                                          valid set of
                                                          endpoints for
                                                          the 
    
                                                          =
    resource
                                                          and the
                                                          associated
                                                          oauth
                                                          services. 
    
                                                          =
    I
                                                          propose that
                                                          the WG
                                                          consider the
                                                          alternate
                                                          draft
                                                          carefully 
    
                                                          =
    as
                                                          well as other
                                                          submissions
                                                          and evaluate
                                                          the =
broader 
    
                                                          =
    discovery
                                                          problem before
                                                          proceeding
                                                          with WGLC on
                                                          OAuth
                                                          =
Discovery. 
    
                                                          =
    Thanks! 
    
                                                          =
    Phil 
    
                                                          =
    @independentid 
    
                                                          =
        www.independentid.com <http://www.independentid.com/&g=
t; 
    
                                                          =
    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 
    
                                                          
    
                                                          
    
                                                          =
        Begin
                                                          forwarded
                                                          message: 
    
                                                          =
        *From:*    internet-drafts@ietf.org 
    
                                                          =
        <mailto:internet-drafts@ietf.o=
rg> 
    
                                                          =
        *Subject:
                                                          New Version
                                                          Notification
                                                          for 
    
                                                          =
        draft-hunt-oauth-bound-config=
-00.txt* 
    =

                                                          =
        *Date:*March
                                                          13, 2016 at
                                                          3:53:37 PM =
PDT 
    
                                                          =
        *To:*"Phil
                                                          Hunt" <phil.hunt@yahoo.com 
    
                                                          =
        <mailto:phil.hunt@yahoo.com>=
>,
                                                          "Anthony
                                                          Nadalin" 
    
                                                          =
        <tonynad@microsoft.com <mailto:tonynad@microsoft.com>=
>, 
    
                                                          =
        "Tony
                                                          Nadalin" =
<tonynad@microsoft.com 
    
                                                          =
        <mailto:tonynad@microsoft.com>=
> 
    =

                                                          
    
                                                          
    
                                                          =
        A
                                                          new version of
                                                          I-D,
                                                          =
draft-hunt-oauth-bound-config-00.txt 
    
                                                          =
        has
                                                          been
                                                          successfully
                                                          submitted by
                                                          Phil Hunt and
                                                          posted to =
the 
    
                                                          =
        IETF
                                                          =
repository. 
    
                                                          
    
                                                          =
        Name:draft-hunt-oauth-bound-c=
onfig 
    
                                                          =
        Revision:00 
    
                                                          =
        Title:OAuth
                                                          2.0 Bound
                                                          Configuration
                                                          Lookup 
    
                                                          =
        Document
date:2016-03-13 
    
                                                          =
        Group:Individual
                                                          =
Submission 
    
                                                          =
        Pages:22 
    
                                                          =
        URL: 
    
                                                          =
        https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-confi=
g-00.txt
    
                                                          =
        Status: 
    
                                                          =
        <=
/a>h=
ttps://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ 
    
                                                          =
        Htmlized: 
    
                                                          =
        =
http=
s://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 
    
                                                          
    
                                                          
    
                                                          =
        Abstract: 
    
                                                          =
          This specification defines =
a
                                                          mechanism for
                                                          the client =
of 
    
                                                          =
        an
                                                          OAuth 2.0 
    
                                                          =
          protected resource service =
to
                                                          obtain the
                                                          =
configuration 
    
                                                          =
        details
                                                          of an 
    
                                                          =
          OAuth 2.0 authorization =
server
                                                          that is
                                                          capable =
of 
    
                                                          =
        authorizing
                                                          access 
    
                                                          =
          to a specific resource =
service. 
                                                          The
                                                          =
information 
    
                                                          =
        includes
                                                          the OAuth 
    
                                                          =
          2.0 component endpoint =
location
                                                          URIs and as
                                                          well as 
    
                                                          =
        authorization 
    
                                                          =
          server capabilities. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          =
        Please
                                                          note that it
                                                          may take a
                                                          couple of
                                                          minutes from
                                                          the 
    
                                                          =
        time
                                                          of =
submission 
    
                                                          =
        until
                                                          the htmlized
                                                          version and
                                                          diff are
                                                          available 
    
                                                          =
        attools.ietf.org <http://tools.ietf.org/>. 
    
                                                          
    
                                                          =
        The
                                                          IETF
                                                          =
Secretariat 
    
                                                          
    
                                                          =
    _____________________________=
__________________ 
    
                                                          =
    OAuth=

                                                          mailing =
list 
    
                                                          =
    OAuth@ietf.org <mailto:OAuth@ietf.org> 
    
                                                          =
    https://www.ietf.org/=
mailman/listinfo/oauth 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
_______________________________________________ 
    
                                                          OAuth mailing
                                                          list 
    
                                                          OAuth@ietf.org <mailto:OAuth@ietf.org> 
    
                                                          https://www.ietf.org/=
mailman/listinfo/oauth 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
_______________________________________________ 
    
                                                          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
    
                                                        
    
                                                      
    
                                                    
    
                                                    
    
                                                  
    
                                                
    
                                              
    
                                            
    
                                          
    
                                        
    
                                      
    
                                      
    
                                    
    
                                  
    
                                
    
                              
    
                            
    
                          
    
                          
    
                        
    
                      
    
                    
    
                  
    
                  
    
                
    
              
    
            
    
          
    
        
    
      
    
    
    
    
    
  
    



    =

--Apple-Mail=_2E284206-9932-46EB-A190-327B6183F73B--

--Apple-Mail=_1515BFF8-73F1-415A-BDE4-C338218C14EE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTUyMjE0NTlaMCMGCSqGSIb3DQEJBDEWBBQ9B6FO4NFmJmZKqZPmmpBe
DsxmMzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBW5knKLnlKm3/1i2u5t3fnQ8Ly/Ra0u3yEIJte70tLhWzm0paX5naq
uQnnWHOFkRvCex2xD56dpRljjDxfr+CtWZNJGJiTEHDO3v1NmlI+uAuU9oktCiRF8pADRn4HTtPr
9k0mQ6e7MWoOfz7xzmemKwDz8YqciJfM62TIqjyUjIZKjrxeMh+O8QMb2I8lIRGMgyV/7ae722df
3JgWxGnStyC4a1yw9eChKXgPAJJIcDocykSj25v4J0P3nJofOndmXwpGPvi44h4J4qIJAxloKdrI
oU74T9qLFbJ2/0YN7G/5Sx0DX1ie0ILtj6z+89HQnM06EnvahEH432Ds3JZUAAAAAAAA
--Apple-Mail=_1515BFF8-73F1-415A-BDE4-C338218C14EE--


From nobody Wed Mar 16 07:27:33 2016
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 63F0412D98C for ; Wed, 16 Mar 2016 07:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.792
X-Spam-Level: 
X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, MANY_SPAN_IN_TEXT=2.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 CETKRWJlMKMV for ; Wed, 16 Mar 2016 07:27:23 -0700 (PDT)
Received: from omr-a016e.mx.aol.com (omr-a016e.mx.aol.com [204.29.186.65]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE2412D765 for ; Wed, 16 Mar 2016 07:27:22 -0700 (PDT)
Received: from mtaout-aab02.mx.aol.com (mtaout-aab02.mx.aol.com [172.26.126.206]) by omr-a016e.mx.aol.com (Outbound Mail Relay) with ESMTP id 963493800092; Wed, 16 Mar 2016 10:27:21 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aab02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 836E338000094; Wed, 16 Mar 2016 10:27:20 -0400 (EDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E96D48.90704@aol.com>
Date: Wed, 16 Mar 2016 10:27:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040601010606090806010003"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458138441; bh=Urv2cUlILO5omhN+jESdrKsl5+EuHbCcY1WzqcavnjY=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=wcCcwcJsxrv5NlzyQ93reAaJCL9Ww5v9MYEb4t6B4jb3yQ1KEui5G2zF4y20vMCC7 3whwJlnnSUCsB1XmyDumx+sbZZU0/FGLu1EOv9SIBS6Cl7SEmy1RVscuDuKG+ItNCD LHZX/2Mr5/+ING6dRuoqv/IUBTANEAqBhMcZQpj0=
x-aol-sid: 3039ac1a7ece56e96d486d5b
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 14:27:32 -0000

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



On 3/15/16 6:14 PM, John Bradley wrote:
> If the AS is audience restricting the tokens then it just needs to put 
> the right audience in the token based on what the client is asking for.
> That is safe as the RS wouldn’t be able to replay the token someplace 
> else.
So let's assuming a client sends a token audience restricted to GoodRS 
instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, 
how does GoodRS reject the token because when GoodRS sends the token to 
the AS for introspection (or does so itself) the token will be audience 
restricted to the GoodRS and it will process the token. The only way to 
prevent this is with client-authentication so that the presenter can be 
matched against who is allowed to present the token (aka PoP).

In the pure bearer token model, I don't see how this can be prevented at 
the protocol level.
>
> That would need to be a AS policy if it wanted to do that for unknown RS.
>
> Allowing more than one audience in a token is a convince but a well 
> known security risk with bearer tokens.
True, but this means clients have to manage many tokens or call the 
token endpoint to get a "downscoped, audience restricted" token every 
time they need one. This is a very different model than what most people 
think of when they think of OAuth2. Not bad, just different:)
>
> A AS would probably want to have only one audience in a AT for a 
> untrusted RS, but may allow multiple if they are all trusted.
>
> John B.
>
>
>> On Mar 15, 2016, at 6:28 PM, George Fletcher > > wrote:
>>
>>
>> On 3/15/16 3:26 PM, John Bradley wrote:
>>> I think Phil and others are concerned that a developer might get bad 
>>> info to put in the client , some out of band discovery goes wrong or 
>>> the user is somehow tricked into specifying a bad resource to the 
>>> client.
>>>
>>> So getting a bad resource is a touch hypothetical.
>> If we are really trying to solve this problem holistically, then we 
>> probably need to first describe the use cases we want to solve. I'm 
>> starting to wonder if we are all providing solutions to slightly 
>> different use cases.
>>>
>>> For Connect we could suppose that someone publishes a malicious 
>>> discovery document listing themselves as the RS but all the other 
>>> endpoints are at the good AS so the client registers, authorizes the 
>>> user and gives the AT to the bad guy.  The confused client 
>>> mitigation by returning client_id_and issuer from the authorization 
>>> endpoint will stop the attack before the token can be given to the 
>>> token endpoint or RS.
>> Agreed and I'm fine with this solution.
>>>
>>> So protecting the AT at this point is more for a unknown attack that 
>>> would confuse whatever protocol/API that is using OAuth about what 
>>> RS to use.
>> Yes. This is where we need to describe some use cases (preferably 
>> real vs contrived) before we propose solutions. In most cases the RS 
>> endpoints are hard coded into the client or maybe pulled from a 
>> different central config endpoint (which is fixed).
>>
>> That's why the only case I could think of is a client that works with 
>> multiple RS endpoints from different providers that server the same 
>> content (e.g. PortableContacts API). In this use case, the user of 
>> the client would need to enter the location of the RS they wanted to 
>> use and then the flow would start from there. In reality, most 
>> services like this would have a fixed set of RS's they work with and 
>> again it wouldn't be dynamic.
>>>
>>> In reality this is what PoP is supposed to be for.
>>>
>>> I guess the question is what short of PoP can we do to prevent the 
>>> client leaking tokens to bad RS that confuse it via the application 
>>> protocol.
>>>
>>> If we want to del with this in OAuth then we need to tell the AS 
>>> where the token is going to be used or tel the client where the 
>>> token can be used.
>>>
>>> I think letting the client tell the AS where it wants the token used 
>>> having the AS construct a audience out of that is probably the best 
>>> thing.  to get around having a pre-established relationship between 
>>> the AS and RS.
>> Even if the client tells the AS where it wants to use the token (via 
>> some endpoint URL), the AS still needs to have a relationship with 
>> the RS (at a minimum as an endpointURL-to-RS map) otherwise how can 
>> it determine if it is allowed to issue an access token to the user 
>> for that RS. This map is what I want to avoid "building" into the AS. 
>> Do we need "dynamic RS registration" to support this?
>>
>>>
>>> John B.
>>>
>>>> On Mar 15, 2016, at 3:14 PM, George Fletcher >>> > wrote:
>>>>
>>>>
>>>>
>>>> I think Justin provided a good break down of the different aspects 
>>>> a client wants to specify about the requested token. (my paraphrase)
>>>>   1. what RS's the token will be used at
>>>>   2. authorization privilege requests
>>>>   3. token-timing adjustments
>>>>
>>>> I'm not sure passing the full endpoint to the AS will help with my 
>>>> concerns... The AS could potentially do a webfinger on the resource 
>>>> URI and determine if it's an RS that it supports... though that 
>>>> requires all RS's to support webfinger. What I really want to avoid 
>>>> is the AS having this list of URIs to RS that is almost assuredly 
>>>> to get out of sync.
>>>>
>>>>
>>>>
>>>> On 3/15/16 1:56 PM, John Bradley wrote:
>>>>> I think it is a AS policy decision if it should error or take the 
>>>>> requested resource and issue a token audianced for that resource.
>>>> Actually, the error cases are interesting. What if the passed in 
>>>> resource/audience doesn't actually match a requested scope? Or some 
>>>> match and some don't? Is it better to send back a token with less 
>>>> capability? or error the entire request?
>>>>>
>>>>> I guess the question is how to transition from now to a future 
>>>>> state. If you cannot upgrade all the clients at once.
>>>>>
>>>>> A processing rule on the AS that allowed some clients to not send 
>>>>> the requested resource , but would error out for other upgraded 
>>>>> clients  with a "resource not allowed†oauth error would work and 
>>>>> not require the return of the resources.
>>>>>
>>>>> If you return the resources and let the client error if it is 
>>>>> trying to send to the wrong endpoint that make upgrading easier, 
>>>>> but gives less control to the AS.
>>>>>
>>>>> I could live with it ether way.
>>>>>
>>>>> The advantage of always sending it in the token request is that it 
>>>>> allows the AS to do the mapping from a resource URI to one or more 
>>>>> abstract audience for the token.
>>>> I thought Justin provided a good break down of the different 
>>>> aspects a client wants to specify about the requested token. (my 
>>>> paraphrase)
>>>>   1. what RS's the token will be used at
>>>>   2. authorization privilege requests
>>>>   3. token-timing adjustments
>>>>
>>>> The question is how does a client internally reference a resource 
>>>> server? If it's a fixed RS endpoint, then it sort of doesn't 
>>>> matter, the client isn't going to send the token to the wrong 
>>>> endpoint anyway and it can easily reference the audience by an 
>>>> abstract URI.
>>>>
>>>> If the client can dynamically find new RS's to interact with. How 
>>>> does that happen? Does the client get handed an endpoint to use? or 
>>>> does it do some sort of discovery to determine the endpoint? I 
>>>> suppose both are possible.
>>>>
>>>> Could we prescribe that the realm value of RFC 6750 error response 
>>>> be effectively a resource-service-id (like issuer for the AS). The 
>>>> client would then need to do discovery on that value to find the 
>>>> valid endpoints of the RS. This could be done once and the 
>>>> resource-service-id could be used as the "abstract" RS identifier. 
>>>> This requires no more discovery than adding an AS to the client.
>>>>>
>>>>> That might help address George’s concern.
>>>> I'm not sure passing the full endpoint to the AS will help with my 
>>>> concerns... The AS could potentially do a webfinger on the resource 
>>>> URI and determine if it's an RS that it supports... though that 
>>>> requires all RS's to support webfinger. What I really want to avoid 
>>>> is the AS having this map of URIs to RS that is almost assuredly to 
>>>> get out of sync.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell 
>>>>>> > 
>>>>>> wrote:
>>>>>>
>>>>>> I was thinking it'd be simpler to error, if the requested 
>>>>>> resource(s) weren't okay. That puts the burden of checking in the 
>>>>>> AS. And doesn't add anything to the token or authorization 
>>>>>> response. I see the potential similarity to scope but not sure 
>>>>>> it's worth it.
>>>>>>
>>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John 
>>>>>> Bradleywrote:
>>>>>>
>>>>>>     If the client specifies the resource it wants the token for,
>>>>>>     then the meta-data would not be required unless the resources
>>>>>>     the token is good at are different from the request.
>>>>>>     Lat is the same logic as scopes.
>>>>>>
>>>>>>     For backwards compatibility if the client is happy with the
>>>>>>     default resources based on scopes then I think it is a good
>>>>>>     idea to tell the client what the resources are in the response.
>>>>>>
>>>>>>     I suspect that it is simpler with less optionality and always
>>>>>>     return the resources, even if they are not required.
>>>>>>
>>>>>>     John B.
>>>>>>
>>>>>>>     On Mar 15, 2016, at 12:46 PM, Brian Campbell
>>>>>>>      wrote:
>>>>>>>
>>>>>>>     If the client specifies the desired audience(s)/resource(s),
>>>>>>>     is that metadata to the client needed? The AS can audience
>>>>>>>     restrict the token as needed or respond with an error if it
>>>>>>>     can't or wont issue a token for the resource the client
>>>>>>>     asked for.
>>>>>>>
>>>>>>>     On Tue, Mar 15, 2016 at 9:37 AM, John
>>>>>>>     Bradleywrote:
>>>>>>>
>>>>>>>         Yes,  I think bearer tokens with no audience are a bad
>>>>>>>         idea.
>>>>>>>
>>>>>>>         The AS needs to infer an audience from the scopes snd/or
>>>>>>>         have the client specify the desired audience.
>>>>>>>
>>>>>>>         If the AT has a audience or audiences then as long as
>>>>>>>         the endpoint URI are provided as meta-data with the
>>>>>>>         token, the client can determine if it is sending the
>>>>>>>         token to the correct place.
>>>>>>>
>>>>>>>         I think Phil would prefer the server rather than the
>>>>>>>         client do the check, but the client always needs to take
>>>>>>>         some responsibility to not leak tokens giving them to
>>>>>>>         the wrong RS or the code to the wrong token endpoint is
>>>>>>>         leaking.
>>>>>>>
>>>>>>>         I imagine that claims based access tokens are going to
>>>>>>>         become more popular and the static relationship between
>>>>>>>         one RS and one AS will not be the majority of
>>>>>>>         deployments over time.
>>>>>>>
>>>>>>>         In any case where the client is configured up front to
>>>>>>>         know the RS and the AS it seems like that would not
>>>>>>>         require Phil’s Solution, but that is the only case
>>>>>>>         supported by that discovery.
>>>>>>>         If the client itself is bad there is not much you can do
>>>>>>>         to stop it from passing on the AT in way way it wants. 
>>>>>>>         That however is a different problem and needs claimed
>>>>>>>         URI or attestations to prevent client spoofing.
>>>>>>>         William and I are working on that in the mobile best
>>>>>>>         practices draft.
>>>>>>>
>>>>>>>         John B.
>>>>>>>
>>>>>>>
>>>>>>>>         On Mar 15, 2016, at 12:09 PM, George Fletcher
>>>>>>>>          wrote:
>>>>>>>>
>>>>>>>>         I worry about two directions I see in this thread...
>>>>>>>>
>>>>>>>>         1. Client's accessing resources dynamically so that
>>>>>>>>         discovery is required to know the correct AS, etc. This
>>>>>>>>         is pretty much the classic use case for UMA and I'd
>>>>>>>>         rather not re-invent the wheel.
>>>>>>>>
>>>>>>>>         2. Creating a tight coupling between RS and AS such
>>>>>>>>         that RS endpoint changes must be continually
>>>>>>>>         communicated to the AS. If an RS supports multiple AS's
>>>>>>>>         then the RS has to deal with "guaranteed" delivery. The
>>>>>>>>         AS needs an endpoint to receive such communications. If
>>>>>>>>         not dynamic via APIs, then deployment of the new RS is
>>>>>>>>         bound by the associated AS's getting and deploying the
>>>>>>>>         new endpoints. Can both endpoints of the RS be
>>>>>>>>         supported within the AS for some period of time, etc.
>>>>>>>>         This is an operation nightmare and almost assuredly
>>>>>>>>         going to go wrong in production.
>>>>>>>>
>>>>>>>>         Maybe an OAuth2 "audience binding" spec is what's
>>>>>>>>         needed for those deployments that require this. I
>>>>>>>>         believe that is what John Bradley is suggesting.
>>>>>>>>
>>>>>>>>         Thanks,
>>>>>>>>         George
>>>>>>>>
>>>>>>>>         On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>>>         +1, I've found the very same in OAuth deployments that
>>>>>>>>>         I was involved in; the hard part is to give names and
>>>>>>>>>         descriptions to these concepts so that they cover all
>>>>>>>>>         use cases and can be applied unambiguously
>>>>>>>>>
>>>>>>>>>         Hans.
>>>>>>>>>
>>>>>>>>>         On 3/14/16 10:44 PM, Justin Richer wrote:
>>>>>>>>>>         I agree that this is valuable, and not just for PoP.
>>>>>>>>>>         In all honesty,
>>>>>>>>>>         it’s not even really required for PoP to function in
>>>>>>>>>>         many cases — it’s
>>>>>>>>>>         just an optimization for one particular kind of key
>>>>>>>>>>         distribution
>>>>>>>>>>         mechanism in that case.
>>>>>>>>>>
>>>>>>>>>>         In the years of deployment experience with OAuth 2, I
>>>>>>>>>>         think we’ve really
>>>>>>>>>>         got three different kinds of things that currently
>>>>>>>>>>         get folded into
>>>>>>>>>>         “scope†that we might want to try separating out better:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         - What things do I want to access? (photos, profile)
>>>>>>>>>>         - What actions do I want to take on these things?
>>>>>>>>>>         (read, write, delete)
>>>>>>>>>>         - How long do I want these tokens to work?
>>>>>>>>>>         (offline_access/refresh_token, one time use, next
>>>>>>>>>>         hour, etc)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         I think the first one is close to the
>>>>>>>>>>         audience/resource parameters that
>>>>>>>>>>         have been bandied about a few times, including in the
>>>>>>>>>>         current token
>>>>>>>>>>         exchange document. We should be consistent across
>>>>>>>>>>         drafts in that regard.
>>>>>>>>>>         The second is more traditional scope-ish. The third
>>>>>>>>>>         has been patched in
>>>>>>>>>>         with things like “offline_access†in certain APIs.
>>>>>>>>>>
>>>>>>>>>>         Just another vector to think about if we’re going to
>>>>>>>>>>         be adding things
>>>>>>>>>>         like “audience†or “resource†or both to the token
>>>>>>>>>>         requests.
>>>>>>>>>>
>>>>>>>>>>         — Justin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>         On Mar 14, 2016, at 6:26 PM, John Bradley
>>>>>>>>>>>         >>>>>>>>>>         > wrote:
>>>>>>>>>>>
>>>>>>>>>>>         Yes I will work on another proposal for allowing
>>>>>>>>>>>         clients to specify
>>>>>>>>>>>         what resource they want a token for and providing
>>>>>>>>>>>         the meta-data to the
>>>>>>>>>>>         client about the resources that a token is valid for.
>>>>>>>>>>>
>>>>>>>>>>>         We have part of it in the POP key distribution spec
>>>>>>>>>>>         and talked about
>>>>>>>>>>>         separating it, as it is used more places than just
>>>>>>>>>>>         for assigning keys.
>>>>>>>>>>>         I know some AS use different token formats for
>>>>>>>>>>>         different RS so are
>>>>>>>>>>>         all-ready needing to pass the resource in the
>>>>>>>>>>>         request to avoid making
>>>>>>>>>>>         a mess of scopes.
>>>>>>>>>>>
>>>>>>>>>>>         John B.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>         On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)
>>>>>>>>>>>>         >>>>>>>>>>>         > wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>         Inline
>>>>>>>>>>>>
>>>>>>>>>>>>         Phil
>>>>>>>>>>>>
>>>>>>>>>>>>         On Mar 14, 2016, at 14:13, John Bradley
>>>>>>>>>>>>         >>>>>>>>>>>         > wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>         We had two mandates.  One was to provide a spec
>>>>>>>>>>>>>         for AS metadata.
>>>>>>>>>>>>>         The other was to mitigate the client mixup attack.
>>>>>>>>>>>>>         The request was
>>>>>>>>>>>>>         to do the latter without requiring the former for
>>>>>>>>>>>>>         clients that don’t
>>>>>>>>>>>>>         otherwise need discovery.
>>>>>>>>>>>>         There is no mandate for any of this. See
>>>>>>>>>>>>         http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Returning the issuer and client_id from the
>>>>>>>>>>>>>         authorization endpoint
>>>>>>>>>>>>>         and the client checking them can be done by the
>>>>>>>>>>>>>         client without
>>>>>>>>>>>>>         discovery.
>>>>>>>>>>>>
>>>>>>>>>>>>         How does this address the issue of whether the
>>>>>>>>>>>>         client is talking to
>>>>>>>>>>>>         the wrong endpoint?
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Any client that has the resource and issuer hard
>>>>>>>>>>>>>         coded probably
>>>>>>>>>>>>>         doesn’t need discovery.
>>>>>>>>>>>>         We agree
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>         One of the things that a client will need
>>>>>>>>>>>>>         discovery for is to find
>>>>>>>>>>>>>         the RS, so requiring the client to know the RS URI
>>>>>>>>>>>>>         before getting
>>>>>>>>>>>>>         the AS config seems backwards to me.
>>>>>>>>>>>>         How can you make an assumption on order? You seem
>>>>>>>>>>>>         to be conflating
>>>>>>>>>>>>         authentication with authorization by assuming the
>>>>>>>>>>>>         identity drives
>>>>>>>>>>>>         what the resource is.
>>>>>>>>>>>>
>>>>>>>>>>>>         There are lots of applications that require user
>>>>>>>>>>>>         rights but are not
>>>>>>>>>>>>         identify centric. For example a document service.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Unless the client tells the AS where it intends to
>>>>>>>>>>>>>         use the token we
>>>>>>>>>>>>>         will be leaving a security hole because the bearer
>>>>>>>>>>>>>         tokens will have
>>>>>>>>>>>>>         too loose an audience if they have one at all.
>>>>>>>>>>>>         This is the biggest risk we have IMHO.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         True you are telling the AS (Webfinger service)
>>>>>>>>>>>>>         what the RS is but
>>>>>>>>>>>>>         that is not at a place that is useful in the token
>>>>>>>>>>>>>         production process.
>>>>>>>>>>>>
>>>>>>>>>>>>         This has nothing to do with token production.
>>>>>>>>>>>>
>>>>>>>>>>>>         What we want to ensure is whether an honest client
>>>>>>>>>>>>         is correctly
>>>>>>>>>>>>         configured and has not been mislead - eg by a
>>>>>>>>>>>>         phishing page.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         I also think there are use cases where the AS
>>>>>>>>>>>>>         doesn’t know all the
>>>>>>>>>>>>>         possible RS. That is not something that a out of
>>>>>>>>>>>>>         band check can
>>>>>>>>>>>>>         address.
>>>>>>>>>>>>
>>>>>>>>>>>>         May be. Lets identify them.
>>>>>>>>>>>>
>>>>>>>>>>>>>         There are also cases where a token might be good
>>>>>>>>>>>>>         at multiple RS
>>>>>>>>>>>>>         endpoints intentionally.
>>>>>>>>>>>>
>>>>>>>>>>>>>          In your solution the client would need to make a
>>>>>>>>>>>>>         discovery request
>>>>>>>>>>>>>         for each endpoint.
>>>>>>>>>>>>         Sure. Otherwise how would it know if there is one
>>>>>>>>>>>>         AS or a pool of AS
>>>>>>>>>>>>         servers assigned to each instance?
>>>>>>>>>>>>>         Those requests lack the context of who the client
>>>>>>>>>>>>>         and resource owner
>>>>>>>>>>>>>         are.  I think that will be a problem in some use
>>>>>>>>>>>>>         cases.
>>>>>>>>>>>>
>>>>>>>>>>>>         Not sure I agree. This is about discovering a valid
>>>>>>>>>>>>         set of endpoints.
>>>>>>>>>>>>         For mitm, we mainly want to check the hostname is
>>>>>>>>>>>>         correct. If a
>>>>>>>>>>>>         client choosesevil.com
>>>>>>>>>>>>         the cert can be
>>>>>>>>>>>>         valid and
>>>>>>>>>>>>         TLS will pass. How does it otherwise know it is
>>>>>>>>>>>>         supposed to talk to
>>>>>>>>>>>>         res.example.com
>>>>>>>>>>>>         ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>         If this is added to the token endpoint it would be
>>>>>>>>>>>>>         checked when code
>>>>>>>>>>>>>         or refresh are exchanged, not every time the token
>>>>>>>>>>>>>         is used.
>>>>>>>>>>>>         Your proposal requires rhe client to check. I am
>>>>>>>>>>>>         not clear how the AS
>>>>>>>>>>>>         can know the exact uri. It is far easier to
>>>>>>>>>>>>         validate than to lookup
>>>>>>>>>>>>         since as you say the client may be authorized to
>>>>>>>>>>>>         use multiple ASs.
>>>>>>>>>>>>>         With a out of band check the client would never
>>>>>>>>>>>>>         know if a RS was
>>>>>>>>>>>>>         removed/revoked.
>>>>>>>>>>>>
>>>>>>>>>>>>         Not sure that is in scope.
>>>>>>>>>>>>
>>>>>>>>>>>>         None of the current proposals address this issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         I don’t see checking when refreshing a token as
>>>>>>>>>>>>>         something that is a
>>>>>>>>>>>>>         huge burden.
>>>>>>>>>>>>
>>>>>>>>>>>>         Still its a lot more than once.
>>>>>>>>>>>>
>>>>>>>>>>>>         Why don't you draft another alternative?
>>>>>>>>>>>>>
>>>>>>>>>>>>>         If the server wants to do the check on it’s side
>>>>>>>>>>>>>         then we could
>>>>>>>>>>>>>         require the client to send the RS URI in the token
>>>>>>>>>>>>>         request. that way
>>>>>>>>>>>>>         you really know the client is not going to get a
>>>>>>>>>>>>>         token for the wrong
>>>>>>>>>>>>>         RS endpoint.
>>>>>>>>>>>>>         If you check out of band in discovery you really
>>>>>>>>>>>>>         have no idea if the
>>>>>>>>>>>>>         client is checking.
>>>>>>>>>>>>
>>>>>>>>>>>>         In the new webfinger draft, the client isn't
>>>>>>>>>>>>         checking. The service
>>>>>>>>>>>>         provider simply does not disclose oauth information
>>>>>>>>>>>>         to misconfigured
>>>>>>>>>>>>         clients.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         John B.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>         On Mar 14, 2016, at 3:56 PM, Phil Hunt
>>>>>>>>>>>>>>         >>>>>>>>>>>>>         > wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Thanks to Mike and John for their feedback. I’ll
>>>>>>>>>>>>>>         take each in turn:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Mike,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Regarding your suggested amendments
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Item 1: Returning the config URL would create two
>>>>>>>>>>>>>>         problems. One,it
>>>>>>>>>>>>>>         makes bound discovery a two-step process - that
>>>>>>>>>>>>>>         adds complexity.
>>>>>>>>>>>>>>          It seems far simpler to mandate TLS (which I
>>>>>>>>>>>>>>         think it already does
>>>>>>>>>>>>>>         in the security considerations).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         The two-step process allows the current discovery
>>>>>>>>>>>>>>         process to
>>>>>>>>>>>>>>         continue. I disagree with this. This is why I put
>>>>>>>>>>>>>>         forward an
>>>>>>>>>>>>>>         “alternate" draft that is almost the same but
>>>>>>>>>>>>>>         simply adds the check
>>>>>>>>>>>>>>         before returning the configuration data.  I worry
>>>>>>>>>>>>>>         that developers
>>>>>>>>>>>>>>         would have no incentive to do the two-step
>>>>>>>>>>>>>>         approach. They would
>>>>>>>>>>>>>>         just start at step 2 which in turn puts AS’s at
>>>>>>>>>>>>>>         risk of exposing
>>>>>>>>>>>>>>         tokens because it works. This makes OAuth
>>>>>>>>>>>>>>         promiscuous.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Regarding existing implementations. Most of those
>>>>>>>>>>>>>>         implementations
>>>>>>>>>>>>>>         are for OIDC. I think it makes sense for OIDF to
>>>>>>>>>>>>>>         continue use of
>>>>>>>>>>>>>>         OIDC's discovery spec because the UserInfo
>>>>>>>>>>>>>>         endpoint is well defined
>>>>>>>>>>>>>>         and the likelihood of a client mis-informed about
>>>>>>>>>>>>>>         the resource
>>>>>>>>>>>>>>         endpoint is not there. IMO This does not apply to
>>>>>>>>>>>>>>         the broader
>>>>>>>>>>>>>>         OAuth community.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Item 2:  It may be appropriate to have a separate
>>>>>>>>>>>>>>         configuration
>>>>>>>>>>>>>>         registry specification, but I think we should
>>>>>>>>>>>>>>         hold off until we
>>>>>>>>>>>>>>         have a complete solution and then make the
>>>>>>>>>>>>>>         decision what drafts
>>>>>>>>>>>>>>         should exist and how many pieces.  A big concern
>>>>>>>>>>>>>>         is the perceived
>>>>>>>>>>>>>>         complexity of multiple solutions and multiple drafts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         As to John Bradley’s comments:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Re: Discovery is the wrong place to mitigate threats.
>>>>>>>>>>>>>>         I’m confused by this.  Our mandate was to solve a
>>>>>>>>>>>>>>         security threat
>>>>>>>>>>>>>>         by having a discovery specification to prevent
>>>>>>>>>>>>>>         clients being
>>>>>>>>>>>>>>         mis-lead about endpoints (of which resource
>>>>>>>>>>>>>>         service is one) in an
>>>>>>>>>>>>>>         oauth protected exchange. Maybe what you mean is
>>>>>>>>>>>>>>         we should not use
>>>>>>>>>>>>>>         .well-known of any kind and we should just create
>>>>>>>>>>>>>>         a “/Configâ€
>>>>>>>>>>>>>>         endpoint to OAuth?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Re: Your proposal for MITM mitigation
>>>>>>>>>>>>>>         You propose that instead the resource endpoint
>>>>>>>>>>>>>>         check should be in
>>>>>>>>>>>>>>         the oauth protocol itself.  The difference is
>>>>>>>>>>>>>>         that validation is
>>>>>>>>>>>>>>         transferred back to the client to get it right.
>>>>>>>>>>>>>>         As well, without
>>>>>>>>>>>>>>         the client informing the AS, I can’t see a way
>>>>>>>>>>>>>>         for the AS to know
>>>>>>>>>>>>>>         what endpoint the client is using.  The webfinger
>>>>>>>>>>>>>>         approach does
>>>>>>>>>>>>>>         this once and only requires that the host name be
>>>>>>>>>>>>>>         checked in many
>>>>>>>>>>>>>>         cases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         As a principle, the members have discussed many
>>>>>>>>>>>>>>         times that the AS
>>>>>>>>>>>>>>         service should do validation when possible — this
>>>>>>>>>>>>>>         was particularly
>>>>>>>>>>>>>>         true at the Germany meeting when this came up.
>>>>>>>>>>>>>>         This is why I prefer
>>>>>>>>>>>>>>         the client tell the service provider what it
>>>>>>>>>>>>>>         intends to do and the
>>>>>>>>>>>>>>         service provider can fail that request
>>>>>>>>>>>>>>         immediately if necessary. We
>>>>>>>>>>>>>>         don’t have to depend on the developer getting the
>>>>>>>>>>>>>>         spec correct to
>>>>>>>>>>>>>>         fail the correct way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         I worry that adding more parameters to the authz
>>>>>>>>>>>>>>         and token protocol
>>>>>>>>>>>>>>         flows increases complexity and attack surface. It
>>>>>>>>>>>>>>         also means per
>>>>>>>>>>>>>>         authorization validation has to take place vs. a
>>>>>>>>>>>>>>         one-time
>>>>>>>>>>>>>>         validation at config time. Placing it in the
>>>>>>>>>>>>>>         configuration lookup
>>>>>>>>>>>>>>         phase (whether via web finger or just a special
>>>>>>>>>>>>>>         OAuth endpoint)
>>>>>>>>>>>>>>         seems more appropriate and far less complex - as
>>>>>>>>>>>>>>         the request itself
>>>>>>>>>>>>>>         is simple and has only one parameter. Here we are
>>>>>>>>>>>>>>         not considered
>>>>>>>>>>>>>>         about legitimacy of the client. we’re just
>>>>>>>>>>>>>>         concerned with the issue
>>>>>>>>>>>>>>         "has the client been correctly informed?â€
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         That said, it may be that when we consider all
>>>>>>>>>>>>>>         the use cases, some
>>>>>>>>>>>>>>         combination of AS protocol and discovery may be
>>>>>>>>>>>>>>         both needed. I’m
>>>>>>>>>>>>>>         not ready to make conclusions about this. The current
>>>>>>>>>>>>>>         oauth-discovery spec seems to put future generic
>>>>>>>>>>>>>>         clients at risk
>>>>>>>>>>>>>>         and that is my primary concern.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Best Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Phil
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         @independentid
>>>>>>>>>>>>>>         www.independentid.com
>>>>>>>>>>>>>>         phil.hunt@oracle.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>>>>>>>>>>>         >
>>>>>>>>>>>>>>>         wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         Thanks for posting this, Phil.  It provides a
>>>>>>>>>>>>>>>         concrete example of
>>>>>>>>>>>>>>>         a way that protected resource discovery could be
>>>>>>>>>>>>>>>         added to
>>>>>>>>>>>>>>>         authorization server metadata discovery, and as
>>>>>>>>>>>>>>>         such, should
>>>>>>>>>>>>>>>         provide useful input for working group
>>>>>>>>>>>>>>>         discussions on this topic.
>>>>>>>>>>>>>>>         It’s always great when someone takes the time to
>>>>>>>>>>>>>>>         write an actual
>>>>>>>>>>>>>>>         draft that can be examined and implemented, and
>>>>>>>>>>>>>>>         I appreciate you
>>>>>>>>>>>>>>>         doing that.
>>>>>>>>>>>>>>>         The content of your draft points out that there
>>>>>>>>>>>>>>>         appears to be
>>>>>>>>>>>>>>>         complete agreement on what the authorization
>>>>>>>>>>>>>>>         server metadata
>>>>>>>>>>>>>>>         format should be, which is great!  I’ll note
>>>>>>>>>>>>>>>         that Section 3 of
>>>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00 titled
>>>>>>>>>>>>>>>         “Authorization Server
>>>>>>>>>>>>>>>         Metadata†is an exact copy of Section 2 of
>>>>>>>>>>>>>>>         draft-ietf-oauth-discovery-01 (with the same
>>>>>>>>>>>>>>>         title), modulo
>>>>>>>>>>>>>>>         applying a correction suggested by the working
>>>>>>>>>>>>>>>         group.  To me this
>>>>>>>>>>>>>>>         suggests that the authorization server metadata
>>>>>>>>>>>>>>>         definitions in
>>>>>>>>>>>>>>>         draft-ietf-oauth-discovery (which is now the
>>>>>>>>>>>>>>>         whole normative
>>>>>>>>>>>>>>>         content of the draft) are clearly ready for
>>>>>>>>>>>>>>>         standardization, since
>>>>>>>>>>>>>>>         even your alternative proposal includes them
>>>>>>>>>>>>>>>         verbatim.
>>>>>>>>>>>>>>>         Reading your draft, the problem I have with it
>>>>>>>>>>>>>>>         is that you are
>>>>>>>>>>>>>>>         returning the AS metadata only as a WebFinger
>>>>>>>>>>>>>>>         response, rather
>>>>>>>>>>>>>>>         than as an https-protected resource published by
>>>>>>>>>>>>>>>         the authorization
>>>>>>>>>>>>>>>         server.  The choice to only return this via
>>>>>>>>>>>>>>>         WebFinger makes your
>>>>>>>>>>>>>>>         draft incompatible with most deployed
>>>>>>>>>>>>>>>         implementations of OAuth
>>>>>>>>>>>>>>>         metadata, including the 22 implementations using
>>>>>>>>>>>>>>>         it listed
>>>>>>>>>>>>>>>         athttp://openid.net/certification/(see the “OP
>>>>>>>>>>>>>>>         Config†column in
>>>>>>>>>>>>>>>         the table) andOAuth 2.0 libraries such as
>>>>>>>>>>>>>>>         Microsoft’s “ADALâ€
>>>>>>>>>>>>>>>         library, which uses the metadata path for client
>>>>>>>>>>>>>>>         configuration.
>>>>>>>>>>>>>>>         Without having ASs provide the metadata as an
>>>>>>>>>>>>>>>         https-protected
>>>>>>>>>>>>>>>         resource, implementations such as ADAL can’t use
>>>>>>>>>>>>>>>         it for client
>>>>>>>>>>>>>>>         configuration as the currently do.
>>>>>>>>>>>>>>>         Therefore, I would request that you make these
>>>>>>>>>>>>>>>         minor revisions to
>>>>>>>>>>>>>>>         your draft and republish, so as to provide a
>>>>>>>>>>>>>>>         unified way forward
>>>>>>>>>>>>>>>         that is compatible with all known existing OAuth
>>>>>>>>>>>>>>>         Discovery
>>>>>>>>>>>>>>>         deployments:
>>>>>>>>>>>>>>>         1.Modify your section 2 “Authorization Server
>>>>>>>>>>>>>>>         WebFinger Discoveryâ€
>>>>>>>>>>>>>>>         to have the WebFinger request return the issuer
>>>>>>>>>>>>>>>         identifier for the
>>>>>>>>>>>>>>>         AS as the “WebFinger “rel†value, rather than
>>>>>>>>>>>>>>>         returning the
>>>>>>>>>>>>>>>         metadata values by value as the “properties†value.
>>>>>>>>>>>>>>>         2.Reference the metadata definitions from
>>>>>>>>>>>>>>>         Section 2 of
>>>>>>>>>>>>>>>         draft-ietf-oauth-discovery, rather than
>>>>>>>>>>>>>>>         duplicating them in your
>>>>>>>>>>>>>>>         Section 3.
>>>>>>>>>>>>>>>         That would have the advantage of paring your
>>>>>>>>>>>>>>>         draft down to only
>>>>>>>>>>>>>>>         the new things that it proposes, enabling them
>>>>>>>>>>>>>>>         to be more clearly
>>>>>>>>>>>>>>>         understood and evaluated on their own merits.  I
>>>>>>>>>>>>>>>         look forward to
>>>>>>>>>>>>>>>         the discussions of ways of performing additional
>>>>>>>>>>>>>>>         kinds of OAuth
>>>>>>>>>>>>>>>         discovery, and consider your draft a valuable
>>>>>>>>>>>>>>>         input to those
>>>>>>>>>>>>>>>         discussions.
>>>>>>>>>>>>>>>         Best wishes,
>>>>>>>>>>>>>>>         -- Mike
>>>>>>>>>>>>>>>         *From:*OAuth [mailto:oauth-bounces@ietf.org]*On
>>>>>>>>>>>>>>>         Behalf Of*John Bradley
>>>>>>>>>>>>>>>         *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>>>>>>>>>>>         *To:*Phil Hunt
>>>>>>>>>>>>>>>         >
>>>>>>>>>>>>>>>         *Cc:*oauth >
>>>>>>>>>>>>>>>         *Subject:*Re: [OAUTH-WG] New Version
>>>>>>>>>>>>>>>         Notification for
>>>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>>>>>         As I have told Phil off list.
>>>>>>>>>>>>>>>         Discovery is the wrong place to try and provide
>>>>>>>>>>>>>>>         security against
>>>>>>>>>>>>>>>         man in the middle attacks on the RS.
>>>>>>>>>>>>>>>         This requires the client to know what the RS URI
>>>>>>>>>>>>>>>         is before
>>>>>>>>>>>>>>>         retrieving the information on the AS Configuration.
>>>>>>>>>>>>>>>         The proposal Mike and I have been working on
>>>>>>>>>>>>>>>         requires the client
>>>>>>>>>>>>>>>         to have a notion of what API it is looking for
>>>>>>>>>>>>>>>         and retrieve the
>>>>>>>>>>>>>>>         .well-known file for that API from the issuer.  
>>>>>>>>>>>>>>>         That allows a
>>>>>>>>>>>>>>>         protocol like Connect to register its own config
>>>>>>>>>>>>>>>         file that can
>>>>>>>>>>>>>>>         point to the RS.
>>>>>>>>>>>>>>>         If the API specific well known is not available
>>>>>>>>>>>>>>>         the client can try
>>>>>>>>>>>>>>>         the default oauth-server one.
>>>>>>>>>>>>>>>         That then allows us to deal with restricting
>>>>>>>>>>>>>>>         where AT are
>>>>>>>>>>>>>>>         presented as part of the protocol rather then
>>>>>>>>>>>>>>>         dragging discovery
>>>>>>>>>>>>>>>         in as a requirement.
>>>>>>>>>>>>>>>         In my opinion the resource the token is targeted
>>>>>>>>>>>>>>>         to should be
>>>>>>>>>>>>>>>         separated from the scope and returned as part of
>>>>>>>>>>>>>>>         the meta-data
>>>>>>>>>>>>>>>         about the AT along with scopes granted and
>>>>>>>>>>>>>>>         expiry time.   We
>>>>>>>>>>>>>>>         should also have a input parameter for resources
>>>>>>>>>>>>>>>         so that a client
>>>>>>>>>>>>>>>         can restrict tokens issued to a subset of the
>>>>>>>>>>>>>>>         ones granted by the
>>>>>>>>>>>>>>>         refresh token.   It would then also be possible
>>>>>>>>>>>>>>>         to ask a AS for a
>>>>>>>>>>>>>>>         token for a unregistered RS and have the AS
>>>>>>>>>>>>>>>         produce a JWT access
>>>>>>>>>>>>>>>         token with the resource as an audience if policy
>>>>>>>>>>>>>>>         allows.
>>>>>>>>>>>>>>>         That however was supposed to be dealt with as
>>>>>>>>>>>>>>>         part of the mixed up
>>>>>>>>>>>>>>>         client set of mitigations.
>>>>>>>>>>>>>>>         In that the goal was to mitigate the attacks by
>>>>>>>>>>>>>>>         returning
>>>>>>>>>>>>>>>         meta-data about the tokens, and not to require
>>>>>>>>>>>>>>>         discovery.
>>>>>>>>>>>>>>>         We intend to return “iss†and “cleint_id†for
>>>>>>>>>>>>>>>         the code, and I
>>>>>>>>>>>>>>>         intend to discuss at the F2F returning resource
>>>>>>>>>>>>>>>         for AT as well.
>>>>>>>>>>>>>>>         Those mitigate the attack.
>>>>>>>>>>>>>>>         I will continue to resist mixing up discovery of
>>>>>>>>>>>>>>>         configuration
>>>>>>>>>>>>>>>         meta-data with mitigation of the attacks.
>>>>>>>>>>>>>>>         We return meta-data about the tokens now,
>>>>>>>>>>>>>>>         because AT are opaque to
>>>>>>>>>>>>>>>         the client, we neglected to include some of the
>>>>>>>>>>>>>>>         information for
>>>>>>>>>>>>>>>         the client needs to be secure.   We just need to
>>>>>>>>>>>>>>>         add that in to
>>>>>>>>>>>>>>>         the existing flows.
>>>>>>>>>>>>>>>         While Phil’s proposal is easier for the AS to
>>>>>>>>>>>>>>>         implement as an add
>>>>>>>>>>>>>>>         on, it puts more of a burden on the client
>>>>>>>>>>>>>>>         needing to potentially
>>>>>>>>>>>>>>>         change how it stores the relationships between
>>>>>>>>>>>>>>>         AS and RS to
>>>>>>>>>>>>>>>         prevent compromise, I think the solution should
>>>>>>>>>>>>>>>         be biased towards
>>>>>>>>>>>>>>>         simplicity on the client side.
>>>>>>>>>>>>>>>         If we return the resources as part of the
>>>>>>>>>>>>>>>         existing meta data the
>>>>>>>>>>>>>>>         client checks that against the resource it
>>>>>>>>>>>>>>>         intends to send the
>>>>>>>>>>>>>>>         token to and if it is not in the list then it
>>>>>>>>>>>>>>>         can’t send the
>>>>>>>>>>>>>>>         token.  Simple check every time it gets a new
>>>>>>>>>>>>>>>         AT, no optionality.
>>>>>>>>>>>>>>>         I am not saying anything new Nat has been
>>>>>>>>>>>>>>>         advocating basically
>>>>>>>>>>>>>>>         this for some time, and dis submit a draft.   I
>>>>>>>>>>>>>>>         prefer to return
>>>>>>>>>>>>>>>         the info in the existing format rather than as
>>>>>>>>>>>>>>>         link headers,  but
>>>>>>>>>>>>>>>         that is the largest difference between what Nat
>>>>>>>>>>>>>>>         and I are saying
>>>>>>>>>>>>>>>         with respect to resource.
>>>>>>>>>>>>>>>         That is the core of my problem with Phil’s draft.
>>>>>>>>>>>>>>>         I guess we will need to have a long conversation
>>>>>>>>>>>>>>>         in BA.
>>>>>>>>>>>>>>>         Regards
>>>>>>>>>>>>>>>         John B.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         On Mar 13, 2016, at 8:12 PM, Phil Hunt
>>>>>>>>>>>>>>>         >>>>>>>>>>>>>>         > wrote:
>>>>>>>>>>>>>>>         This draft is a proposed alternate proposal for
>>>>>>>>>>>>>>>         draft-ietf-oauth-discovery. As such, it contains
>>>>>>>>>>>>>>>         the same
>>>>>>>>>>>>>>>         registry for OAuth Config Metadata as the
>>>>>>>>>>>>>>>         authors believe that
>>>>>>>>>>>>>>>         both solutions are not required, or depending on
>>>>>>>>>>>>>>>         WG discussion
>>>>>>>>>>>>>>>         they will be merged. The intent is to provide a
>>>>>>>>>>>>>>>         simple
>>>>>>>>>>>>>>>         complete draft for consideration.
>>>>>>>>>>>>>>>         How it works...
>>>>>>>>>>>>>>>         Given that a client has previously discovered an
>>>>>>>>>>>>>>>         OAuth
>>>>>>>>>>>>>>>         protected resource, the bound configuration
>>>>>>>>>>>>>>>         method allows a
>>>>>>>>>>>>>>>         client to return the configuration for an oauth
>>>>>>>>>>>>>>>         authorization
>>>>>>>>>>>>>>>         server that can issue tokens for the resource
>>>>>>>>>>>>>>>         URI specified by
>>>>>>>>>>>>>>>         the client.  The AS is not required to be in the
>>>>>>>>>>>>>>>         same domain.
>>>>>>>>>>>>>>>         The AS is however required to know if it can
>>>>>>>>>>>>>>>         issue tokens for
>>>>>>>>>>>>>>>         a resource service (which presumes some
>>>>>>>>>>>>>>>         agreement exists on
>>>>>>>>>>>>>>>         tokens etc).
>>>>>>>>>>>>>>>         The draft does not require that the resource
>>>>>>>>>>>>>>>         exist (e.g. for
>>>>>>>>>>>>>>>         unconfigured or new user based resources). It
>>>>>>>>>>>>>>>         only requires
>>>>>>>>>>>>>>>         that the AS service provider agrees it can issue
>>>>>>>>>>>>>>>         tokens.
>>>>>>>>>>>>>>>         From a security perspective, returning the OAuth
>>>>>>>>>>>>>>>         service
>>>>>>>>>>>>>>>         configuration for a specified resource URI
>>>>>>>>>>>>>>>         serves to confirm
>>>>>>>>>>>>>>>         the client is in possession of a valid resource
>>>>>>>>>>>>>>>         URI ensuring
>>>>>>>>>>>>>>>         the client has received a valid set of endpoints
>>>>>>>>>>>>>>>         for the
>>>>>>>>>>>>>>>         resource and the associated oauth services.
>>>>>>>>>>>>>>>         I propose that the WG consider the alternate
>>>>>>>>>>>>>>>         draft carefully
>>>>>>>>>>>>>>>         as well as other submissions and evaluate the
>>>>>>>>>>>>>>>         broader
>>>>>>>>>>>>>>>         discovery problem before proceeding with WGLC on
>>>>>>>>>>>>>>>         OAuth Discovery.
>>>>>>>>>>>>>>>         Thanks!
>>>>>>>>>>>>>>>         Phil
>>>>>>>>>>>>>>>         @independentid
>>>>>>>>>>>>>>>         www.independentid.com
>>>>>>>>>>>>>>>         phil.hunt@oracle.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         Begin forwarded message:
>>>>>>>>>>>>>>>         *From:*internet-drafts@ietf.org
>>>>>>>>>>>>>>>         
>>>>>>>>>>>>>>>         *Subject: New Version Notification for
>>>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt*
>>>>>>>>>>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>>>>>>>>>>         *To:*"Phil Hunt" >>>>>>>>>>>>>>         >, "Anthony Nadalin"
>>>>>>>>>>>>>>>         >,
>>>>>>>>>>>>>>>         "Tony Nadalin" >>>>>>>>>>>>>>         >
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         A new version of I-D,
>>>>>>>>>>>>>>>         draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>>>>>         has been successfully submitted by Phil Hunt and
>>>>>>>>>>>>>>>         posted to the
>>>>>>>>>>>>>>>         IETF repository.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>>>>>>>>>>         Revision:00
>>>>>>>>>>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>>>>>>>>>>         Document date:2016-03-13
>>>>>>>>>>>>>>>         Group:Individual Submission
>>>>>>>>>>>>>>>         Pages:22
>>>>>>>>>>>>>>>         URL:
>>>>>>>>>>>>>>>         https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>>>>>>>>>>         Status:
>>>>>>>>>>>>>>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>>>>>>>>>>         Htmlized:
>>>>>>>>>>>>>>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         Abstract:
>>>>>>>>>>>>>>>         This specification defines a mechanism for the
>>>>>>>>>>>>>>>         client of
>>>>>>>>>>>>>>>         an OAuth 2.0
>>>>>>>>>>>>>>>         protected resource service to obtain the
>>>>>>>>>>>>>>>         configuration
>>>>>>>>>>>>>>>         details of an
>>>>>>>>>>>>>>>         OAuth 2.0 authorization server that is capable of
>>>>>>>>>>>>>>>         authorizing access
>>>>>>>>>>>>>>>         to a specific resource service. The information
>>>>>>>>>>>>>>>         includes the OAuth
>>>>>>>>>>>>>>>         2.0 component endpoint location URIs and as well as
>>>>>>>>>>>>>>>         authorization
>>>>>>>>>>>>>>>         server capabilities.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         Please note that it may take a couple of minutes
>>>>>>>>>>>>>>>         from the
>>>>>>>>>>>>>>>         time of submission
>>>>>>>>>>>>>>>         until the htmlized version and diff are available
>>>>>>>>>>>>>>>         attools.ietf.org
>>>>>>>>>>>>>>>         .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         The IETF Secretariat
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>>>>>         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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         _______________________________________________
>>>>>>>>>>         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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    
    
    
    
    
    On 3/15/16 6:14 PM, John Bradley wrote:
    
    
    
    
    
      
      If the AS is audience restricting the tokens then it just needs to
      put the right audience in the token based on what the client is
      asking for.  
      
    That is safe as the RS wouldn’t be able to replay
        the token someplace else.
    
    
    
    So let's assuming a client sends a token audience restricted to
    GoodRS instead to EvilRS. When EvilRS replays the token at the
    GoodRS endpoint, how does GoodRS reject the token because when
    GoodRS sends the token to the AS for introspection (or does so
    itself) the token will be audience restricted to the GoodRS and it
    will process the token. The only way to prevent this is with
    client-authentication so that the presenter can be matched against
    who is allowed to present the token (aka PoP).
    
    
    
    In the pure bearer token model, I don't see how this can be
    prevented at the protocol level.
    
    
    
      

    
      
    
      
    That would need to be a AS policy if it wanted to do
        that for unknown RS.   
    
      

    
      
    
      
    Allowing more than one audience in a token is a
        convince but a well known security risk with bearer tokens.
    
    
    
    True, but this means clients have to manage many tokens or call the
    token endpoint to get a "downscoped, audience restricted" token
    every time they need one. This is a very different model than what
    most people think of when they think of OAuth2. Not bad, just
    different:)
    
    
    
      

    
      
    
      
    A AS would probably want to have only one audience
        in a AT for a untrusted RS, but may allow multiple if they are
        all trusted.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 6:28 PM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
              
              
     
    
                
    On 3/15/16 3:26 PM, John
                  Bradley wrote:
    
                
    
                
    
                  
                  I think Phil and others are concerned that a developer
                  might get bad info to put in the client , some out of
                  band discovery goes wrong or the user is somehow
                  tricked into specifying a bad resource to the client.
                  

    
                  
    
                  
    So getting a bad resource is a touch
                    hypothetical. 
    
                  
    
                
    
                If we are really trying to solve this problem
                holistically, then we probably need to first describe
                the use cases we want to solve. I'm starting to wonder
                if we are all providing solutions to slightly different
                use cases.
    
                
    
                  

    
                  
    
                  
    For Connect we could suppose that
                    someone publishes a malicious discovery document
                    listing themselves as the RS but all the other
                    endpoints are at the good AS so the client
                    registers, authorizes the user and gives the AT to
                    the bad guy.  The confused client mitigation by
                    returning client_id_and issuer from the
                    authorization endpoint will stop the attack before
                    the token can be given to the token endpoint or RS.
    
                
    
                Agreed and I'm fine with this solution.
    
                
    
                  

    
                  
    
                  
    So protecting the AT at this point is
                    more for a unknown attack that would confuse
                    whatever protocol/API that is using OAuth about what
                    RS to use.
    
                
    
                Yes. This is where we need to describe some use cases
                (preferably real vs contrived) before we propose
                solutions. In most cases the RS endpoints are hard coded
                into the client or maybe pulled from a different central
                config endpoint (which is fixed).
    
                
    
                That's why the only case I could think of is a client
                that works with multiple RS endpoints from different
                providers that server the same content (e.g.
                PortableContacts API). In this use case, the user of the
                client would need to enter the location of the RS they
                wanted to use and then the flow would start from there.
                In reality, most services like this would have a fixed
                set of RS's they work with and again it wouldn't be
                dynamic.
    
                
    
                  

    
                  
    
                  
    In reality this is what PoP is supposed
                    to be for.
    
                  

    
                  
    
                  
    I guess the question is what short of
                    PoP can we do to prevent the client leaking tokens
                    to bad RS that confuse it via the application
                    protocol.
    
                  

    
                  
    
                  
    If we want to del with this in OAuth
                    then we need to tell the AS where the token is going
                    to be used or tel the client where the token can be
                    used. 
    
                  

    
                  
    
                  
    I think letting the client tell the AS
                    where it wants the token used having the AS
                    construct a audience out of that is probably the
                    best thing.  to get around having a pre-established
                    relationship between the AS and RS.
    
                
    
                Even if the client tells the AS where it wants to use
                the token (via some endpoint URL), the AS still needs to
                have a relationship with the RS (at a minimum as an
                endpointURL-to-RS map) otherwise how can it determine if
                it is allowed to issue an access token to the user for
                that RS. This map is what I want to avoid "building"
                into the AS. Do we need "dynamic RS registration" to
                support this?
    
                
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 3:14 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        

    
                            
    
                            I think Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
    
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            I'm not sure passing the full endpoint to
                            the AS will help with my concerns... The AS
                            could potentially do a webfinger on the
                            resource URI and determine if it's an RS
                            that it supports... though that requires all
                            RS's to support webfinger. What I really
                            want to avoid is the AS having this list of
                            URIs to RS that is almost assuredly to get
                            out of sync.
    
                            
    
                            
    
                          
    
                          
    On
                            3/15/16 1:56 PM, John Bradley wrote:
    
                          
    
                          
    I think it is a AS policy decision
                            if it should error or take the requested
                            resource and issue a token audianced for
                            that resource.
    
                          Actually,
                            the error cases are interesting. What if the
                            passed in resource/audience doesn't actually
                            match a requested scope? Or some match and
                            some don't? Is it better to send back a
                            token with less capability? or error the
                            entire request?
                          
    
                            

    
                            
    
                            
    I guess the question is how to
                              transition from now to a future state.  
                              If you cannot upgrade all the clients at
                              once.
    
                            

    
                            
    
                            
    A processing rule on the AS
                              that allowed some clients to not send the
                              requested resource , but would error out
                              for other upgraded clients  with a
                              "resource not allowed†oauth error would
                              work and not require the return of the
                              resources.  
    
                            

    
                            
    
                            
    If you return the resources
                              and let the client error if it is trying
                              to send to the wrong endpoint that make
                              upgrading easier, but gives less control
                              to the AS.
    
                            

    
                            
    
                            
    
                              
    
                                
    I could
                                    live with it ether way.
    
                                

    
                                
    
                                The advantage of always sending it in
                                the token request is that it allows the
                                AS to do the mapping from a resource URI
                                to one or more abstract audience for the
                                token.
    
                            
    
                          
    
                          I
                            thought Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
    
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            The question is how does a client internally
                            reference a resource server? If it's a fixed
                            RS endpoint, then it sort of doesn't matter,
                            the client isn't going to send the token to
                            the wrong endpoint anyway and it can easily
                            reference the audience by an abstract URI.
    
                            
    
                            If the client can dynamically find new RS's
                            to interact with. How does that happen? Does
                            the client get handed an endpoint to use? or
                            does it do some sort of discovery to
                            determine the endpoint? I suppose both are
                            possible.
    
                            
    
                            Could we prescribe that the realm value of
                            RFC 6750 error response be effectively a
                            resource-service-id (like issuer for the
                            AS). The client would then need to do
                            discovery on that value to find the valid
                            endpoints of the RS. This could be done once
                            and the resource-service-id could be used as
                            the "abstract" RS identifier. This requires
                            no more discovery than adding an AS to the
                            client.
    
                              
                          
    
                            
    
                              

    
                              
    
                              
    That might help address
                                George’s concern.
    
                            
    
                          
    
                          I'm
                            not sure passing the full endpoint to the AS
                            will help with my concerns... The AS could
                            potentially do a webfinger on the resource
                            URI and determine if it's an RS that it
                            supports... though that requires all RS's to
                            support webfinger. What I really want to
                            avoid is the AS having this map of URIs to
                            RS that is almost assuredly to get out of
                            sync.
                          
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                              
    
                              

    
                                
    
                                  
    On Mar 15, 2016, at 2:44
                                    PM, Brian Campbell <bcampbell@pingidentity.com>

                                    wrote:
    
                                  
    
                                  
    
                                    
    I was
                                      thinking it'd be simpler to error,
                                      if the requested resource(s)
                                      weren't okay. That puts the burden
                                      of checking in the AS. And doesn't
                                      add anything to the token or
                                      authorization response. I see the
                                      potential similarity to scope but
                                      not sure it's worth it.    
    
                                    

    
                                      
    On Tue,
                                        Mar 15, 2016 at 11:37 AM, John
                                        Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                        
    
                                          
    If the client
                                            specifies the resource it
                                            wants the token for, then
                                            the meta-data would not be
                                            required unless the
                                            resources the token is good
                                            at are different from the
                                            request.  
                                            
    Lat is the
                                              same logic as scopes.
    
                                            

    
                                            
    
                                            
    For backwards
                                              compatibility if the
                                              client is happy with the
                                              default resources based on
                                              scopes then I think it is
                                              a good idea to tell the
                                              client what the resources
                                              are in the response.
    
                                            

    
                                            
    
                                            
    I suspect that
                                              it is simpler with less
                                              optionality and always
                                              return the resources, even
                                              if they are not required.
    
                                            

    
                                            
    
                                            
    John B.
    
                                            
    
                                              
    
                                                

    
                                                
    
                                                
    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:46 PM, Brian
                                                        Campbell <bcampbell@pingidentity.com>

                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
    If
                                                          the client
                                                          specifies the
                                                          desired
                                                          audience(s)/resource(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for. 
    
                                                          
    
                                                          
    
                                                          

    
                                                          
    On

                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                                          
    
                                                          
    Yes,

                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The

                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          audience.
    
                                                          

    
                                                          
    
                                                          
    If

                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time. 
    
                                                          

    
                                                          
    
                                                          
    In

                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil’s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
      
    
                                                          
    If

                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.  That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    William

                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John

                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    On

                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>

                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On

                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously 
    
                                                          
    
                                                          Hans. 
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: 
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty, 
    
                                                          it’s not even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases —
                                                          it’s 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution 
    
                                                          mechanism in
                                                          that case. 
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we’ve
                                                          really 
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into 
    
                                                          “scope†that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: 
    
                                                          
    
                                                          
    
                                                            -
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile) 
    
                                                            -
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete) 
    
                                                            -
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? 
    
                                                          (offline_access/refresh_token,

                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token 
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. 
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in 
    
                                                          with things
                                                          like
                                                          “offline_accessâ€
                                                          in certain
                                                          APIs. 
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we’re going to
                                                          be adding
                                                          things 
    
                                                          like
                                                          “audience†or
                                                          “resource†or
                                                          both to the
                                                          token
                                                          requests. 
    
                                                          
    
                                                            —
                                                          Justin 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: 
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify 
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. 
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are 
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making 
    
                                                          a mess of
                                                          scopes. 
    
                                                          
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>

                                                          wrote: 
    
                                                          
    
                                                          Inline 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: 
    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.  One
                                                          was to provide
                                                          a spec for AS
                                                          metadata. 
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack. 
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don’t 
    
                                                          otherwise need
                                                          discovery. 
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint 
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without 
    
                                                          discovery. 
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to 
    
                                                          the wrong
                                                          endpoint? 
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably 
    
                                                          doesn’t need
                                                          discovery. 
    
                                                          
    
                                                          We agree 
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find 
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating 
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives 
    
                                                          what the
                                                          resource is. 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not 
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service. 
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have 
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. 
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process. 
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production. 
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. 
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn’t
                                                          know all the 
    
                                                          possible RS.  
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can 
    
                                                          address. 
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them. 
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS 
    
                                                          endpoints
                                                          intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request 
    
                                                          for each
                                                          endpoint. 
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS 
    
                                                          servers
                                                          assigned to
                                                          each instance? 
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner 
    
                                                          are.  I think
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. 
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints. 
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a 
    
                                                          client chooses evil.com <http://evil.com/> the cert can be valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to 
    
                                                          res.example.com <http://res.example.com/>? 
    
                                                          

    
                                                          If this is
                                                          added to the
                                                          token endpoint
                                                          it would be
                                                          checked when
                                                          code 
    
                                                          or refresh are
                                                          exchanged, not
                                                          every time the
                                                          token is used. 
    
                                                          
    
                                                          Your proposal
                                                          requires rhe
                                                          client to
                                                          check. I am
                                                          not clear how
                                                          the AS 
    
                                                          can know the
                                                          exact uri. It
                                                          is far easier
                                                          to validate
                                                          than to lookup 
    
                                                          since as you
                                                          say the client
                                                          may be
                                                          authorized to
                                                          use multiple
                                                          ASs. 
    
                                                          
    With
                                                          a out of band
                                                          check the
                                                          client would
                                                          never know if
                                                          a RS was 
    
removed/revoked. 
    
                                                          
    
                                                          
    
                                                          Not sure that
                                                          is in scope. 
    
                                                          
    
                                                          None of the
                                                          current
                                                          proposals
                                                          address this
                                                          issue. 
    
                                                          

    
                                                          I don’t see
                                                          checking when
                                                          refreshing a
                                                          token as
                                                          something that
                                                          is a 
    
                                                          huge burden. 
    
                                                          
    
                                                          
    
                                                          Still its a
                                                          lot more than
                                                          once. 
    
                                                          
    
                                                          Why don't you
                                                          draft another
                                                          alternative? 
    
                                                          

    
                                                          If the server
                                                          wants to do
                                                          the check on
                                                          it’s side then
                                                          we could 
    
                                                          require the
                                                          client to send
                                                          the RS URI in
                                                          the token
                                                          request. that
                                                          way 
    
                                                          you really
                                                          know the
                                                          client is not
                                                          going to get a
                                                          token for the
                                                          wrong 
    
                                                          RS endpoint. 
    
                                                          If you check
                                                          out of band in
                                                          discovery you
                                                          really have no
                                                          idea if the 
    
                                                          client is
                                                          checking. 
    
                                                          
    
                                                          
    
                                                          In the new
                                                          webfinger
                                                          draft, the
                                                          client isn't
                                                          checking. The
                                                          service 
    
                                                          provider
                                                          simply does
                                                          not disclose
                                                          oauth
                                                          information to
                                                          misconfigured 
    
                                                          clients. 
    
                                                          

    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 3:56 PM,
                                                          Phil Hunt <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>

                                                          wrote: 
    
                                                          
    
                                                          Thanks to Mike
                                                          and John for
                                                          their
                                                          feedback. 
                                                          I’ll take each
                                                          in turn: 
    
                                                          
    
                                                          Mike, 
    
                                                          
    
                                                          Regarding your
                                                          suggested
                                                          amendments 
    
                                                          
    
                                                          Item 1:
                                                          Returning the
                                                          config URL
                                                          would create
                                                          two problems.
                                                          One,it 
    
                                                          makes bound
                                                          discovery a
                                                          two-step
                                                          process - that
                                                          adds
                                                          complexity. 
    
                                                           It seems far
                                                          simpler to
                                                          mandate TLS
                                                          (which I think
                                                          it already
                                                          does 
    
                                                          in the
                                                          security
                                                          considerations). 
    
                                                          
    
                                                          The two-step
                                                          process allows
                                                          the current
                                                          discovery
                                                          process to 
    
                                                          continue. I
                                                          disagree with
                                                          this. This is
                                                          why I put
                                                          forward an 
    
                                                          “alternate"
                                                          draft that is
                                                          almost the
                                                          same but
                                                          simply adds
                                                          the check 
    
                                                          before
                                                          returning the
                                                          configuration
                                                          data.  I worry
                                                          that 
                                                          developers 
    
                                                          would have no
                                                          incentive to
                                                          do the
                                                          two-step
                                                          approach. They
                                                          would 
    
                                                          just start at
                                                          step 2 which
                                                          in turn puts
                                                          AS’s at risk
                                                          of exposing 
    
                                                          tokens because
                                                          it works. This
                                                          makes OAuth
                                                          promiscuous. 
    
                                                          
    
                                                          Regarding
                                                          existing
                                                          implementations.
                                                          Most of those
implementations 
    
                                                          are for OIDC. 
                                                          I think it
                                                          makes sense
                                                          for OIDF to
                                                          continue use
                                                          of 
    
                                                          OIDC's
                                                          discovery spec
                                                          because the
                                                          UserInfo
                                                          endpoint is
                                                          well defined 
    
                                                          and the
                                                          likelihood of
                                                          a client
                                                          mis-informed
                                                          about the
                                                          resource 
    
                                                          endpoint is
                                                          not there. 
                                                          IMO This does
                                                          not apply to
                                                          the broader 
    
                                                          OAuth
                                                          community. 
    
                                                          
    
                                                          Item 2:  It
                                                          may be
                                                          appropriate to
                                                          have a
                                                          separate
                                                          configuration 
    
                                                          registry
                                                          specification,
                                                          but I think we
                                                          should hold
                                                          off until we 
    
                                                          have a
                                                          complete
                                                          solution and
                                                          then make the
                                                          decision what
                                                          drafts 
    
                                                          should exist
                                                          and how many
                                                          pieces.  A big
                                                          concern is the
                                                          perceived 
    
                                                          complexity of
                                                          multiple
                                                          solutions and
                                                          multiple
                                                          drafts. 
    
                                                          
    
                                                          As to John
                                                          Bradley’s
                                                          comments: 
    
                                                          
    
                                                          Re: Discovery
                                                          is the wrong
                                                          place to
                                                          mitigate
                                                          threats. 
    
                                                          I’m confused
                                                          by this.  Our
                                                          mandate was to
                                                          solve a
                                                          security
                                                          threat 
    
                                                          by having a
                                                          discovery
                                                          specification
                                                          to prevent
                                                          clients being 
    
                                                          mis-lead about
                                                          endpoints (of
                                                          which resource
                                                          service is
                                                          one) in an 
    
                                                          oauth
                                                          protected
                                                          exchange. 
                                                          Maybe what you
                                                          mean is we
                                                          should not use 
    
                                                          .well-known of
                                                          any kind and
                                                          we should just
                                                          create a
                                                          “/Configâ€Â 
    
                                                          endpoint to
                                                          OAuth? 
    
                                                          
    
                                                          Re: Your
                                                          proposal for
                                                          MITM
                                                          mitigation 
    
                                                          You propose
                                                          that instead
                                                          the resource
                                                          endpoint check
                                                          should be in 
    
                                                          the oauth
                                                          protocol
                                                          itself.  The
                                                          difference is
                                                          that
                                                          validation is 
    
                                                          transferred
                                                          back to the
                                                          client to get
                                                          it right. As
                                                          well, without 
    
                                                          the client
                                                          informing the
                                                          AS, I can’t
                                                          see a way for
                                                          the AS to know 
    
                                                          what endpoint
                                                          the client is
                                                          using.  The
                                                          webfinger
                                                          approach does 
    
                                                          this once and
                                                          only requires
                                                          that the host
                                                          name be
                                                          checked in
                                                          many 
    
                                                          cases. 
    
                                                          
    
                                                          As a
                                                          principle, the
                                                          members have
                                                          discussed many
                                                          times that the
                                                          AS 
    
                                                          service should
                                                          do validation
                                                          when possible
                                                          — this was
                                                          particularly 
    
                                                          true at the
                                                          Germany
                                                          meeting when
                                                          this came up.
                                                          This is why I
                                                          prefer 
    
                                                          the client
                                                          tell the
                                                          service
                                                          provider what
                                                          it intends to
                                                          do and the 
    
                                                          service
                                                          provider can
                                                          fail that
                                                          request
                                                          immediately if
                                                          necessary. We 
    
                                                          don’t have to
                                                          depend on the
                                                          developer
                                                          getting the
                                                          spec correct
                                                          to 
    
                                                          fail the
                                                          correct way. 
    
                                                          
    
                                                          I worry that
                                                          adding more
                                                          parameters to
                                                          the authz and
                                                          token protocol 
    
                                                          flows
                                                          increases
                                                          complexity and
                                                          attack
                                                          surface. It
                                                          also means per 
    
                                                          authorization
                                                          validation has
                                                          to take place
                                                          vs. a one-time 
    
                                                          validation at
                                                          config time. 
                                                          Placing it in
                                                          the
                                                          configuration
                                                          lookup 
    
                                                          phase (whether
                                                          via web finger
                                                          or just a
                                                          special OAuth
                                                          endpoint) 
    
                                                          seems more
                                                          appropriate
                                                          and far less
                                                          complex - as
                                                          the request
                                                          itself 
    
                                                          is simple and
                                                          has only one
                                                          parameter.
                                                          Here we are
                                                          not considered 
    
                                                          about
                                                          legitimacy of
                                                          the client.
                                                          we’re just
                                                          concerned with
                                                          the issue 
    
                                                          "has the
                                                          client been
                                                          correctly
                                                          informed?â€Â 
    
                                                          
    
                                                          That said, it
                                                          may be that
                                                          when we
                                                          consider all
                                                          the use cases,
                                                          some 
    
                                                          combination of
                                                          AS protocol
                                                          and discovery
                                                          may be both
                                                          needed. I’m 
    
                                                          not ready to
                                                          make
                                                          conclusions
                                                          about this. 
                                                          The current 
    
                                                          oauth-discovery

                                                          spec seems to
                                                          put future
                                                          generic
                                                          clients at
                                                          risk 
    
                                                          and that is my
                                                          primary
                                                          concern. 
    
                                                          
    
                                                          Best Regards, 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          @independentid 
    
                                                          www.independentid.com <http://www.independentid.com/> 
    
                                                          phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 13, 2016,
                                                          at 10:28 PM,
                                                          Mike Jones 
    
                                                          <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> 
    
                                                          wrote: 
    
                                                          
    
                                                          Thanks for
                                                          posting this,
                                                          Phil.  It
                                                          provides a
                                                          concrete
                                                          example of 
    
                                                          a way that
                                                          protected
                                                          resource
                                                          discovery
                                                          could be added
                                                          to 
    
                                                          authorization
                                                          server
                                                          metadata
                                                          discovery, and
                                                          as such,
                                                          should 
    
                                                          provide useful
                                                          input for
                                                          working group
                                                          discussions on
                                                          this topic. 
    
                                                          It’s always
                                                          great when
                                                          someone takes
                                                          the time to
                                                          write an
                                                          actual 
    
                                                          draft that can
                                                          be examined
                                                          and
                                                          implemented,
                                                          and I
                                                          appreciate you 
    
                                                          doing that. 
    
                                                          The content of
                                                          your draft
                                                          points out
                                                          that there
                                                          appears to be 
    
                                                          complete
                                                          agreement on
                                                          what the
                                                          authorization
                                                          server
                                                          metadata 
    
                                                          format should
                                                          be, which is
                                                          great!  I’ll
                                                          note that
                                                          Section 3 of 
    
                                                          draft-hunt-oauth-bound-config-00

                                                          titled
                                                          “Authorization
                                                          Server 
    
                                                          Metadata†is
                                                          an exact copy
                                                          of Section 2
                                                          of 
    
                                                          draft-ietf-oauth-discovery-01

                                                          (with the same
                                                          title), modulo 
    
                                                          applying a
                                                          correction
                                                          suggested by
                                                          the working
                                                          group.  To me
                                                          this 
    
                                                          suggests that
                                                          the
                                                          authorization
                                                          server
                                                          metadata
                                                          definitions in 
    
                                                          draft-ietf-oauth-discovery

                                                          (which is now
                                                          the whole
                                                          normative 
    
                                                          content of the
                                                          draft) are
                                                          clearly ready
                                                          for
                                                          standardization,
                                                          since 
    
                                                          even your
                                                          alternative
                                                          proposal
                                                          includes them
                                                          verbatim. 
    
                                                          Reading your
                                                          draft, the
                                                          problem I have
                                                          with it is
                                                          that you are 
    
                                                          returning the
                                                          AS metadata
                                                          only as a
                                                          WebFinger
                                                          response,
                                                          rather 
    
                                                          than as an
                                                          https-protected
                                                          resource
                                                          published by
                                                          the
                                                          authorization 
    
                                                          server.  The
                                                          choice to only
                                                          return this
                                                          via WebFinger
                                                          makes your 
    
                                                          draft
                                                          incompatible
                                                          with most
                                                          deployed
                                                          implementations
                                                          of OAuth 
    
                                                          metadata,
                                                          including the
                                                          22
                                                          implementations
                                                          using it
                                                          listed 
    
                                                          athttp://openid.net/certification/(see

                                                          the “OP
                                                          Config†column
                                                          in 
    
                                                          the table)
                                                          andOAuth 2.0
                                                          libraries such
                                                          as Microsoft’s
                                                          “ADALâ€Â 
    
                                                          library, which
                                                          uses the
                                                          metadata path
                                                          for client
                                                          configuration. 
    
                                                          Without having
                                                          ASs provide
                                                          the metadata
                                                          as an
                                                          https-protected 
    
                                                          resource,
                                                          implementations
                                                          such as ADAL
                                                          can’t use it
                                                          for client 
    
                                                          configuration
                                                          as the
                                                          currently do. 
    
                                                          Therefore, I
                                                          would request
                                                          that you make
                                                          these minor
                                                          revisions to 
    
                                                          your draft and
                                                          republish, so
                                                          as to provide
                                                          a unified way
                                                          forward 
    
                                                          that is
                                                          compatible
                                                          with all known
                                                          existing OAuth
                                                          Discovery 
    
                                                          deployments: 
    
                                                          1.Modify your
                                                          section 2
                                                          “Authorization
                                                          Server
                                                          WebFinger
                                                          Discoveryâ€Â 
    
                                                          to have the
                                                          WebFinger
                                                          request return
                                                          the issuer
                                                          identifier for
                                                          the 
    
                                                          AS as the
                                                          “WebFinger
                                                          “rel†value,
                                                          rather than
                                                          returning the 
    
                                                          metadata
                                                          values by
                                                          value as the
                                                          “propertiesâ€
                                                          value. 
    
                                                          2.Reference
                                                          the metadata
                                                          definitions
                                                          from Section 2
                                                          of 
    
                                                          draft-ietf-oauth-discovery,

                                                          rather than
                                                          duplicating
                                                          them in your 
    
                                                          Section 3. 
    
                                                          That would
                                                          have the
                                                          advantage of
                                                          paring your
                                                          draft down to
                                                          only 
    
                                                          the new things
                                                          that it
                                                          proposes,
                                                          enabling them
                                                          to be more
                                                          clearly 
    
                                                          understood and
                                                          evaluated on
                                                          their own
                                                          merits.  I
                                                          look forward
                                                          to 
    
                                                          the
                                                          discussions of
                                                          ways of
                                                          performing
                                                          additional
                                                          kinds of OAuth 
    
                                                          discovery, and
                                                          consider your
                                                          draft a
                                                          valuable input
                                                          to those 
    
                                                          discussions. 
    
                                                          Best

                                                          wishes, 
    
                                                          --

                                                          Mike 
    
                                                          *From:*OAuth [mailto:oauth-bounces@ietf.org]*On

                                                          Behalf Of*John
                                                          Bradley 
    
                                                          *Sent:*Sunday,
                                                          March 13, 2016
                                                          6:45 PM 
    
                                                          *To:*Phil Hunt
                                                          <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> 
    
                                                          *Cc:*oauth
                                                          <oauth@ietf.org <mailto:oauth@ietf.org>> 
    
                                                          *Subject:*Re:
                                                          [OAUTH-WG] New
                                                          Version
                                                          Notification
                                                          for 
    
draft-hunt-oauth-bound-config-00.txt 
    
                                                          As I have told
                                                          Phil off list. 
    
                                                          Discovery is
                                                          the wrong
                                                          place to try
                                                          and provide
                                                          security
                                                          against 
    
                                                          man in the
                                                          middle attacks
                                                          on the RS. 
    
                                                          This requires
                                                          the client to
                                                          know what the
                                                          RS URI is
                                                          before 
    
                                                          retrieving the
                                                          information on
                                                          the AS
                                                          Configuration. 
    
                                                          The proposal
                                                          Mike and I
                                                          have been
                                                          working on
                                                          requires the
                                                          client 
    
                                                          to have a
                                                          notion of what
                                                          API it is
                                                          looking for
                                                          and retrieve
                                                          the 
    
                                                          .well-known
                                                          file for that
                                                          API from the
                                                          issuer.   That
                                                          allows a 
    
                                                          protocol like
                                                          Connect to
                                                          register its
                                                          own config
                                                          file that can 
    
                                                          point to the
                                                          RS. 
    
                                                          If the API
                                                          specific well
                                                          known is not
                                                          available the
                                                          client can try 
    
                                                          the default
                                                          oauth-server
                                                          one. 
    
                                                          That then
                                                          allows us to
                                                          deal with
                                                          restricting
                                                          where AT are 
    
                                                          presented as
                                                          part of the
                                                          protocol
                                                          rather then
                                                          dragging
                                                          discovery 
    
                                                          in as a
                                                          requirement. 
    
                                                          In my opinion
                                                          the resource
                                                          the token is
                                                          targeted to
                                                          should be 
    
                                                          separated from
                                                          the scope and
                                                          returned as
                                                          part of the
                                                          meta-data 
    
                                                          about the AT
                                                          along with
                                                          scopes granted
                                                          and expiry
                                                          time.   We 
    
                                                          should also
                                                          have a input
                                                          parameter for
                                                          resources so
                                                          that a client 
    
                                                          can restrict
                                                          tokens issued
                                                          to a subset of
                                                          the ones
                                                          granted by the 
    
                                                          refresh
                                                          token.   It
                                                          would then
                                                          also be
                                                          possible to
                                                          ask a AS for a 
    
                                                          token for a
                                                          unregistered
                                                          RS and have
                                                          the AS produce
                                                          a JWT access 
    
                                                          token with the
                                                          resource as an
                                                          audience if
                                                          policy allows. 
    
                                                          That however
                                                          was supposed
                                                          to be dealt
                                                          with as part
                                                          of the mixed
                                                          up 
    
                                                          client set of
                                                          mitigations. 
    
                                                          In that the
                                                          goal was to
                                                          mitigate the
                                                          attacks by
                                                          returning 
    
                                                          meta-data
                                                          about the
                                                          tokens, and
                                                          not to require
                                                          discovery. 
    
                                                          We intend to
                                                          return “issâ€
                                                          and
                                                          “cleint_idâ€
                                                          for the code,
                                                          and I 
    
                                                          intend to
                                                          discuss at the
                                                          F2F returning
                                                          resource for
                                                          AT as well. 
    
                                                          Those mitigate
                                                          the attack. 
    
                                                          I will
                                                          continue to
                                                          resist mixing
                                                          up discovery
                                                          of
                                                          configuration 
    
                                                          meta-data with
                                                          mitigation of
                                                          the attacks. 
    
                                                          We return
                                                          meta-data
                                                          about the
                                                          tokens now,
                                                          because AT are
                                                          opaque to 
    
                                                          the client, we
                                                          neglected to
                                                          include some
                                                          of the
                                                          information
                                                          for 
    
                                                          the client
                                                          needs to be
                                                          secure.   We
                                                          just need to
                                                          add that in to 
    
                                                          the existing
                                                          flows. 
    
                                                          While Phil’s
                                                          proposal is
                                                          easier for the
                                                          AS to
                                                          implement as
                                                          an add 
    
                                                          on, it puts
                                                          more of a
                                                          burden on the
                                                          client needing
                                                          to potentially 
    
                                                          change how it
                                                          stores the
                                                          relationships
                                                          between AS and
                                                          RS to 
    
                                                          prevent
                                                          compromise, I
                                                          think the
                                                          solution
                                                          should be
                                                          biased towards 
    
                                                          simplicity on
                                                          the client
                                                          side. 
    
                                                          If we return
                                                          the resources
                                                          as part of the
                                                          existing meta
                                                          data the 
    
                                                          client checks
                                                          that against
                                                          the resource
                                                          it intends to
                                                          send the 
    
                                                          token to and
                                                          if it is not
                                                          in the list
                                                          then it can’t
                                                          send the 
    
                                                          token.  Simple
                                                          check every
                                                          time it gets a
                                                          new AT, no
                                                          optionality. 
    
                                                          I am not
                                                          saying
                                                          anything new
                                                          Nat has been
                                                          advocating
                                                          basically 
    
                                                          this for some
                                                          time, and dis
                                                          submit a
                                                          draft.   I
                                                          prefer to
                                                          return 
    
                                                          the info in
                                                          the existing
                                                          format rather
                                                          than as link
                                                          headers,  but 
    
                                                          that is the
                                                          largest
                                                          difference
                                                          between what
                                                          Nat and I are
                                                          saying 
    
                                                          with respect
                                                          to resource. 
    
                                                          That is the
                                                          core of my
                                                          problem with
                                                          Phil’s draft. 
    
                                                          I guess we
                                                          will need to
                                                          have a long
                                                          conversation
                                                          in BA. 
    
                                                          Regards 
    
                                                          John B. 
    
                                                          
    
                                                              On

                                                          Mar 13, 2016,
                                                          at 8:12 PM,
                                                          Phil Hunt <phil.hunt@oracle.com 
    
                                                              <mailto:phil.hunt@oracle.com>>

                                                          wrote: 
    
                                                              This

                                                          draft is a
                                                          proposed
                                                          alternate
                                                          proposal for 
    
                                                              draft-ietf-oauth-discovery. 

                                                          As such, it
                                                          contains the
                                                          same 
    
                                                              registry

                                                          for OAuth
                                                          Config
                                                          Metadata as
                                                          the authors
                                                          believe that 
    
                                                              both

                                                          solutions are
                                                          not required,
                                                          or depending
                                                          on WG
                                                          discussion 
    
                                                              they

                                                          will be
                                                          merged. The
                                                          intent is to
                                                          provide a
                                                          simple 
    
                                                              complete

                                                          draft for
                                                          consideration. 
    
                                                              How

                                                          it works... 
    
                                                              Given

                                                          that a client
                                                          has previously
                                                          discovered an
                                                          OAuth 
    
                                                              protected

                                                          resource, the
                                                          bound
                                                          configuration
                                                          method allows
                                                          a 
    
                                                              client

                                                          to return the
                                                          configuration
                                                          for an oauth
                                                          authorization 
    
                                                              server

                                                          that can issue
                                                          tokens for the
                                                          resource URI
                                                          specified by 
    
                                                              the

                                                          client.  The
                                                          AS is not
                                                          required to be
                                                          in the same
                                                          domain. 
    
                                                               The

                                                          AS is however
                                                          required to
                                                          know if it can
                                                          issue tokens
                                                          for 
    
                                                              a
                                                          resource
                                                          service (which
                                                          presumes some
                                                          agreement
                                                          exists on 
    
                                                              tokens

                                                          etc). 
    
                                                              The

                                                          draft does not
                                                          require that
                                                          the resource
                                                          exist (e.g.
                                                          for 
    
                                                              unconfigured

                                                          or new user
                                                          based
                                                          resources). It
                                                          only requires 
    
                                                              that

                                                          the AS service
                                                          provider
                                                          agrees it can
                                                          issue tokens. 
    
                                                              From

                                                          a security
                                                          perspective,
                                                          returning the
                                                          OAuth service 
    
                                                              configuration

                                                          for a
                                                          specified
                                                          resource URI
                                                          serves to
                                                          confirm 
    
                                                              the

                                                          client is in
                                                          possession of
                                                          a valid
                                                          resource URI
                                                          ensuring 
    
                                                              the

                                                          client has
                                                          received a
                                                          valid set of
                                                          endpoints for
                                                          the 
    
                                                              resource

                                                          and the
                                                          associated
                                                          oauth
                                                          services. 
    
                                                              I
                                                          propose that
                                                          the WG
                                                          consider the
                                                          alternate
                                                          draft
                                                          carefully 
    
                                                              as

                                                          well as other
                                                          submissions
                                                          and evaluate
                                                          the broader 
    
                                                              discovery

                                                          problem before
                                                          proceeding
                                                          with WGLC on
                                                          OAuth
                                                          Discovery. 
    
                                                              Thanks! 
    
                                                              Phil 
    
                                                              @independentid 
    
                                                              www.independentid.com <http://www.independentid.com/> 
    
                                                              phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> 
    
                                                          
    
                                                          
    
                                                                  Begin

                                                          forwarded
                                                          message: 
    
                                                                  *From:*internet-drafts@ietf.org 
    
                                                                  <mailto:internet-drafts@ietf.org> 
    
                                                                  *Subject:

                                                          New Version
                                                          Notification
                                                          for 
    
                                                                  draft-hunt-oauth-bound-config-00.txt* 
    
                                                                  *Date:*March

                                                          13, 2016 at
                                                          3:53:37 PM PDT 
    
                                                                  *To:*"Phil

                                                          Hunt" <phil.hunt@yahoo.com 
    
                                                                  <mailto:phil.hunt@yahoo.com>>,

                                                          "Anthony
                                                          Nadalin" 
    
                                                                  <tonynad@microsoft.com <mailto:tonynad@microsoft.com>>, 
    
                                                                  "Tony

                                                          Nadalin" <tonynad@microsoft.com 
    
                                                                  <mailto:tonynad@microsoft.com>> 
    
                                                          
    
                                                          
    
                                                                  A
                                                          new version of
                                                          I-D,
                                                          draft-hunt-oauth-bound-config-00.txt 
    
                                                                  has

                                                          been
                                                          successfully
                                                          submitted by
                                                          Phil Hunt and
                                                          posted to the 
    
                                                                  IETF

                                                          repository. 
    
                                                          
    
                                                                  Name:draft-hunt-oauth-bound-config 
    
                                                                  Revision:00 
    
                                                                  Title:OAuth

                                                          2.0 Bound
                                                          Configuration
                                                          Lookup 
    
                                                                  Document
date:2016-03-13 
    
                                                                  Group:Individual

                                                          Submission 
    
                                                                  Pages:22 
    
                                                                  URL: 
    
                                                                  https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
    
                                                                  Status: 
    
                                                                  https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ 
    
                                                                  Htmlized: 
    
                                                                  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 
    
                                                          
    
                                                          
    
                                                                  Abstract: 
    
                                                                    This specification defines a
                                                          mechanism for
                                                          the client of 
    
                                                                  an

                                                          OAuth 2.0 
    
                                                                    protected resource service to
                                                          obtain the
                                                          configuration 
    
                                                                  details

                                                          of an 
    
                                                                    OAuth 2.0 authorization server
                                                          that is
                                                          capable of 
    
                                                                  authorizing

                                                          access 
    
                                                                    to a specific resource service. 
                                                          The
                                                          information 
    
                                                                  includes

                                                          the OAuth 
    
                                                                    2.0 component endpoint location
                                                          URIs and as
                                                          well as 
    
                                                                  authorization 
    
                                                                    server capabilities. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                                  Please

                                                          note that it
                                                          may take a
                                                          couple of
                                                          minutes from
                                                          the 
    
                                                                  time

                                                          of submission 
    
                                                                  until

                                                          the htmlized
                                                          version and
                                                          diff are
                                                          available 
    
                                                                  attools.ietf.org <http://tools.ietf.org/>. 
    
                                                          
    
                                                                  The

                                                          IETF
                                                          Secretariat 
    
                                                          
    
                                                              _______________________________________________ 
    
                                                              OAuth

                                                          mailing list 
    
                                                              OAuth@ietf.org <mailto:OAuth@ietf.org> 
    
                                                              https://www.ietf.org/mailman/listinfo/oauth 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
_______________________________________________ 
    
                                                          OAuth mailing
                                                          list 
    
                                                          OAuth@ietf.org <mailto:OAuth@ietf.org> 
    
                                                          https://www.ietf.org/mailman/listinfo/oauth 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
_______________________________________________ 
    
                                                          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
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                        
    
                                                      
    
                                                    
    
                                                  
    
                                                  
    
                                                
    
                                              
    
                                            
    
                                          
    
                                        
    
                                      
    
                                      
    
                                    
    
                                  
    
                                
    
                              
    
                              
    
                            
    
                          
    
                        
    
                      
    
                    
    
                  
    
                
    
                
    
              
    
            
    
          
    
        
    
        
    
      
    
    
    
    
    
    
    -- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

    
  


--------------040601010606090806010003--


From nobody Wed Mar 16 07:46:15 2016
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 C4F9412D5A3 for ; Wed, 16 Mar 2016 07:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.34
X-Spam-Level: 
X-Spam-Status: No, score=-2.34 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 NCUK6SQZi_sW for ; Wed, 16 Mar 2016 07:46:08 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 6E77E12D97D for ; Wed, 16 Mar 2016 07:46:08 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id h129so64468214ywb.1 for ; Wed, 16 Mar 2016 07:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7YvhY1lJjoOYpfeL2XDn015YspPcgSebara6HfJr9iU=; b=Fb6zy77abpXbXODfmKggvXetHamvq2clfTYCeEUNdi1TvH7Ky0ea8wV1DnMHOYfbco wMU0HqSuUzoYjq0PGzU7YL3JFpFAVaPcy8ugiK4NBEQXr2JBfoUaIa8BcYk079XDN7H1 NCnLB4O+2/4F1Vow/CfDQTLYZPGis3Q43psmtFkqGt+n7oMQKTUOqlGEZyoAEvtmgzAp DcaoWymXTimDoXjE0ZqXgVM0xOgdWES1Ks2RmZj26lrl9/QyY8xHrbSIlus2UjLZd3v+ cU4QMePxhwVu0CKKWKQjSxx0/l0nHSvwPMBSyxkJKBJPc7WsgiX+KlLH2Z1tjJW+guRB GJig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7YvhY1lJjoOYpfeL2XDn015YspPcgSebara6HfJr9iU=; b=eUgTbV54H02a59BT4RAnpx6/o6N9eK3VJ1GDjSYHtYOEjjmvTswOPh5EAxzCttdccM PGyHQg9smguFh7I+oi5Rtdfw7N6GBuvtfhh82HCZJQZ6d4BgJ5/9tyxXVGoOPboa6nem q+yfvpYuT8eT2cj6pCrw2KKVlOdYB3P4XMmi+uuxSAwbQLXwxLzMgwdq1Lg2tlLk0j51 P3pgNy65D57adr/pVSCvy1cCsqy9rF/upJ8hmSMv2hYhKaMyWEyHbrMjCfd3PkhGYu2j 0f4lFzLV4D3e+T3BoZfeRyodMJfBrl0wKXoZeU9nqwCk0SKbAClfl65zgFpsovPL+5yT /j3w==
X-Gm-Message-State: AD7BkJL3Hl45LoWwfL4+KgRsRVdFkohL8rk4DhyTXKxoTQ1Ag+cKCIkU+AyP3rwIFgo2hfRldgcYnTHedPkflA==
MIME-Version: 1.0
X-Received: by 10.13.231.132 with SMTP id q126mr1925434ywe.203.1458139567454;  Wed, 16 Mar 2016 07:46:07 -0700 (PDT)
Received: by 10.37.214.130 with HTTP; Wed, 16 Mar 2016 07:46:06 -0700 (PDT)
Received: by 10.37.214.130 with HTTP; Wed, 16 Mar 2016 07:46:06 -0700 (PDT)
In-Reply-To: <56E96D48.90704@aol.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>  <56E96D48.90704@aol.com>
Date: Wed, 16 Mar 2016 11:46:06 -0300
Message-ID: 
From: John Bradley 
To: George Fletcher 
Content-Type: multipart/alternative; boundary=94eb2c088c1ef3c71c052e2b9298
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 14:46:14 -0000

--94eb2c088c1ef3c71c052e2b9298
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If the client sends the uri of the resource it intends to send the token to
in the token request the bad guy would get only a token audianced to itself
and not to good RS.

You can't solve the problem of bearer tokens with multiple audiences
leaking.   That is a risk inherent in using that sort of token.
Compromise in one RS will impact all of them.

The only safe way with bearer to deal with a RS the AS dosen't trust a RS
is to only have one audianced in the token. (or by introspection)

We have always known that and left it up to clients to make sure they are
secure by not sending tokens to bad RS.

Now people want a AS check to prevent clients from being tricked if
developers are given bad info statically or dynamically.

What you are doing is safe as long as your developers don't make any
mistakes.
If you want to be safe and not have to preconfigure the AS you need to use
the refresh to get single audianced tokens, or PoP.

John B.
On Mar 16, 2016 11:27 AM, "George Fletcher"  wrote:

>
>
> On 3/15/16 6:14 PM, John Bradley wrote:
>
> If the AS is audience restricting the tokens then it just needs to put th=
e
> right audience in the token based on what the client is asking for.
> That is safe as the RS wouldn=E2=80=99t be able to replay the token somep=
lace else.
>
> So let's assuming a client sends a token audience restricted to GoodRS
> instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint,
> how does GoodRS reject the token because when GoodRS sends the token to t=
he
> AS for introspection (or does so itself) the token will be audience
> restricted to the GoodRS and it will process the token. The only way to
> prevent this is with client-authentication so that the presenter can be
> matched against who is allowed to present the token (aka PoP).
>
> In the pure bearer token model, I don't see how this can be prevented at
> the protocol level.
>
>
> That would need to be a AS policy if it wanted to do that for unknown RS.
>
>
> Allowing more than one audience in a token is a convince but a well known
> security risk with bearer tokens.
>
> True, but this means clients have to manage many tokens or call the token
> endpoint to get a "downscoped, audience restricted" token every time they
> need one. This is a very different model than what most people think of
> when they think of OAuth2. Not bad, just different:)
>
>
> A AS would probably want to have only one audience in a AT for a untruste=
d
> RS, but may allow multiple if they are all trusted.
>
> John B.
>
>
> On Mar 15, 2016, at 6:28 PM, George Fletcher  wrote:
>
>
> On 3/15/16 3:26 PM, John Bradley wrote:
>
> I think Phil and others are concerned that a developer might get bad info
> to put in the client , some out of band discovery goes wrong or the user =
is
> somehow tricked into specifying a bad resource to the client.
>
> So getting a bad resource is a touch hypothetical.
>
> If we are really trying to solve this problem holistically, then we
> probably need to first describe the use cases we want to solve. I'm
> starting to wonder if we are all providing solutions to slightly differen=
t
> use cases.
>
>
> For Connect we could suppose that someone publishes a malicious discovery
> document listing themselves as the RS but all the other endpoints are at
> the good AS so the client registers, authorizes the user and gives the AT
> to the bad guy.  The confused client mitigation by returning client_id_an=
d
> issuer from the authorization endpoint will stop the attack before the
> token can be given to the token endpoint or RS.
>
> Agreed and I'm fine with this solution.
>
>
> So protecting the AT at this point is more for a unknown attack that woul=
d
> confuse whatever protocol/API that is using OAuth about what RS to use.
>
> Yes. This is where we need to describe some use cases (preferably real vs
> contrived) before we propose solutions. In most cases the RS endpoints ar=
e
> hard coded into the client or maybe pulled from a different central confi=
g
> endpoint (which is fixed).
>
> That's why the only case I could think of is a client that works with
> multiple RS endpoints from different providers that server the same conte=
nt
> (e.g. PortableContacts API). In this use case, the user of the client wou=
ld
> need to enter the location of the RS they wanted to use and then the flow
> would start from there. In reality, most services like this would have a
> fixed set of RS's they work with and again it wouldn't be dynamic.
>
>
> In reality this is what PoP is supposed to be for.
>
> I guess the question is what short of PoP can we do to prevent the client
> leaking tokens to bad RS that confuse it via the application protocol.
>
> If we want to del with this in OAuth then we need to tell the AS where th=
e
> token is going to be used or tel the client where the token can be used.
>
> I think letting the client tell the AS where it wants the token used
> having the AS construct a audience out of that is probably the best thing=
.
>  to get around having a pre-established relationship between the AS and R=
S.
>
> Even if the client tells the AS where it wants to use the token (via some
> endpoint URL), the AS still needs to have a relationship with the RS (at =
a
> minimum as an endpointURL-to-RS map) otherwise how can it determine if it
> is allowed to issue an access token to the user for that RS. This map is
> what I want to avoid "building" into the AS. Do we need "dynamic RS
> registration" to support this?
>
>
> John B.
>
> On Mar 15, 2016, at 3:14 PM, George Fletcher  wrote:
>
>
>
> I think Justin provided a good break down of the different aspects a
> client wants to specify about the requested token. (my paraphrase)
>   1. what RS's the token will be used at
>   2. authorization privilege requests
>   3. token-timing adjustments
>
> I'm not sure passing the full endpoint to the AS will help with my
> concerns... The AS could potentially do a webfinger on the resource URI a=
nd
> determine if it's an RS that it supports... though that requires all RS's
> to support webfinger. What I really want to avoid is the AS having this
> list of URIs to RS that is almost assuredly to get out of sync.
>
>
>
> On 3/15/16 1:56 PM, John Bradley wrote:
>
> I think it is a AS policy decision if it should error or take the
> requested resource and issue a token audianced for that resource.
>
> Actually, the error cases are interesting. What if the passed in
> resource/audience doesn't actually match a requested scope? Or some match
> and some don't? Is it better to send back a token with less capability? o=
r
> error the entire request?
>
>
> I guess the question is how to transition from now to a future state.   I=
f
> you cannot upgrade all the clients at once.
>
> A processing rule on the AS that allowed some clients to not send the
> requested resource , but would error out for other upgraded clients  with=
 a
> "resource not allowed=E2=80=9D oauth error would work and not require the=
 return of
> the resources.
>
> If you return the resources and let the client error if it is trying to
> send to the wrong endpoint that make upgrading easier, but gives less
> control to the AS.
>
> I could live with it ether way.
>
> The advantage of always sending it in the token request is that it allows
> the AS to do the mapping from a resource URI to one or more abstract
> audience for the token.
>
> I thought Justin provided a good break down of the different aspects a
> client wants to specify about the requested token. (my paraphrase)
>   1. what RS's the token will be used at
>   2. authorization privilege requests
>   3. token-timing adjustments
>
> The question is how does a client internally reference a resource server?
> If it's a fixed RS endpoint, then it sort of doesn't matter, the client
> isn't going to send the token to the wrong endpoint anyway and it can
> easily reference the audience by an abstract URI.
>
> If the client can dynamically find new RS's to interact with. How does
> that happen? Does the client get handed an endpoint to use? or does it do
> some sort of discovery to determine the endpoint? I suppose both are
> possible.
>
> Could we prescribe that the realm value of RFC 6750 error response be
> effectively a resource-service-id (like issuer for the AS). The client
> would then need to do discovery on that value to find the valid endpoints
> of the RS. This could be done once and the resource-service-id could be
> used as the "abstract" RS identifier. This requires no more discovery tha=
n
> adding an AS to the client.
>
>
> That might help address George=E2=80=99s concern.
>
> I'm not sure passing the full endpoint to the AS will help with my
> concerns... The AS could potentially do a webfinger on the resource URI a=
nd
> determine if it's an RS that it supports... though that requires all RS's
> to support webfinger. What I really want to avoid is the AS having this m=
ap
> of URIs to RS that is almost assuredly to get out of sync.
>
>
> John B.
>
>
> On Mar 15, 2016, at 2:44 PM, Brian Campbell 
> wrote:
>
> I was thinking it'd be simpler to error, if the requested resource(s)
> weren't okay. That puts the burden of checking in the AS. And doesn't add
> anything to the token or authorization response. I see the potential
> similarity to scope but not sure it's worth it.
>
> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley  wrote:
>
>> If the client specifies the resource it wants the token for, then the
>> meta-data would not be required unless the resources the token is good a=
t
>> are different from the request.
>> Lat is the same logic as scopes.
>>
>> For backwards compatibility if the client is happy with the default
>> resources based on scopes then I think it is a good idea to tell the cli=
ent
>> what the resources are in the response.
>>
>> I suspect that it is simpler with less optionality and always return the
>> resources, even if they are not required.
>>
>> John B.
>>
>> On Mar 15, 2016, at 12:46 PM, Brian Campbell 
>> wrote:
>>
>> If the client specifies the desired audience(s)/resource(s), is that
>> metadata to the client needed? The AS can audience restrict the token as
>> needed or respond with an error if it can't or wont issue a token for th=
e
>> resource the client asked for.
>>
>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  wrote:
>>
>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>
>>> The AS needs to infer an audience from the scopes snd/or have the clien=
t
>>> specify the desired audience.
>>>
>>> If the AT has a audience or audiences then as long as the endpoint URI
>>> are provided as meta-data with the token, the client can determine if i=
t is
>>> sending the token to the correct place.
>>>
>>> I think Phil would prefer the server rather than the client do the
>>> check, but the client always needs to take some responsibility to not l=
eak
>>> tokens giving them to the wrong RS or the code to the wrong token endpo=
int
>>> is leaking.
>>>
>>> I imagine that claims based access tokens are going to become more
>>> popular and the static relationship between one RS and one AS will not =
be
>>> the majority of deployments over time.
>>>
>>> In any case where the client is configured up front to know the RS and
>>> the AS it seems like that would not require Phil=E2=80=99s Solution, bu=
t that is
>>> the only case supported by that discovery.
>>>
>>> If the client itself is bad there is not much you can do to stop it fro=
m
>>> passing on the AT in way way it wants.  That however is a different pro=
blem
>>> and needs claimed URI or attestations to prevent client spoofing.
>>> William and I are working on that in the mobile best practices draft.
>>>
>>> John B.
>>>
>>>
>>> On Mar 15, 2016, at 12:09 PM, George Fletcher  wrote:
>>>
>>> I worry about two directions I see in this thread...
>>>
>>> 1. Client's accessing resources dynamically so that discovery is
>>> required to know the correct AS, etc. This is pretty much the classic u=
se
>>> case for UMA and I'd rather not re-invent the wheel.
>>>
>>> 2. Creating a tight coupling between RS and AS such that RS endpoint
>>> changes must be continually communicated to the AS. If an RS supports
>>> multiple AS's then the RS has to deal with "guaranteed" delivery. The A=
S
>>> needs an endpoint to receive such communications. If not dynamic via AP=
Is,
>>> then deployment of the new RS is bound by the associated AS's getting a=
nd
>>> deploying the new endpoints. Can both endpoints of the RS be supported
>>> within the AS for some period of time, etc. This is an operation nightm=
are
>>> and almost assuredly going to go wrong in production.
>>>
>>> Maybe an OAuth2 "audience binding" spec is what's needed for those
>>> deployments that require this. I believe that is what John Bradley is
>>> suggesting.
>>>
>>> Thanks,
>>> George
>>>
>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>
>>> +1, I've found the very same in OAuth deployments that I was involved
>>> in; the hard part is to give names and descriptions to these concepts s=
o
>>> that they cover all use cases and can be applied unambiguously
>>>
>>> Hans.
>>>
>>> On 3/14/16 10:44 PM, Justin Richer wrote:
>>>
>>> I agree that this is valuable, and not just for PoP. In all honesty,
>>> it=E2=80=99s not even really required for PoP to function in many cases=
 =E2=80=94 it=E2=80=99s
>>> just an optimization for one particular kind of key distribution
>>> mechanism in that case.
>>>
>>> In the years of deployment experience with OAuth 2, I think we=E2=80=99=
ve really
>>>
>>> got three different kinds of things that currently get folded into
>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out better=
:
>>>
>>>
>>>   - What things do I want to access? (photos, profile)
>>>   - What actions do I want to take on these things? (read, write,
>>> delete)
>>>   - How long do I want these tokens to work?
>>> (offline_access/refresh_token, one time use, next hour, etc)
>>>
>>>
>>> I think the first one is close to the audience/resource parameters that
>>> have been bandied about a few times, including in the current token
>>> exchange document. We should be consistent across drafts in that regard=
.
>>>
>>> The second is more traditional scope-ish. The third has been patched in
>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.
>>>
>>> Just another vector to think about if we=E2=80=99re going to be adding =
things
>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or both t=
o the token requests.
>>>
>>>   =E2=80=94 Justin
>>>
>>>
>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>   >
>>> wrote:
>>>
>>> Yes I will work on another proposal for allowing clients to specify
>>> what resource they want a token for and providing the meta-data to the
>>> client about the resources that a token is valid for.
>>>
>>> We have part of it in the POP key distribution spec and talked about
>>> separating it, as it is used more places than just for assigning keys.
>>> I know some AS use different token formats for different RS so are
>>> all-ready needing to pass the resource in the request to avoid making
>>> a mess of scopes.
>>>
>>> John B.
>>>
>>>
>>>
>>>
>>>
>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>  
>>> > wrote:
>>>
>>> Inline
>>>
>>> Phil
>>>
>>> On Mar 14, 2016, at 14:13, John Bradley >>   >
>>> wrote:
>>>
>>> We had two mandates.  One was to provide a spec for AS metadata.
>>> The other was to mitigate the client mixup attack.  The request was
>>> to do the latter without requiring the former for clients that don=E2=
=80=99t
>>> otherwise need discovery.
>>>
>>> There is no mandate for any of this. See
>>> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22=
.txt
>>>
>>>
>>>
>>> Returning the issuer and client_id from the authorization endpoint
>>> and the client checking them can be done by the client without
>>> discovery.
>>>
>>>
>>> How does this address the issue of whether the client is talking to
>>> the wrong endpoint?
>>>
>>>
>>> Any client that has the resource and issuer hard coded probably
>>> doesn=E2=80=99t need discovery.
>>>
>>> We agree
>>>
>>>
>>> One of the things that a client will need discovery for is to find
>>> the RS, so requiring the client to know the RS URI before getting
>>> the AS config seems backwards to me.
>>>
>>> How can you make an assumption on order? You seem to be conflating
>>> authentication with authorization by assuming the identity drives
>>> what the resource is.
>>>
>>> There are lots of applications that require user rights but are not
>>> identify centric. For example a document service.
>>>
>>>
>>> Unless the client tells the AS where it intends to use the token we
>>> will be leaving a security hole because the bearer tokens will have
>>> too loose an audience if they have one at all.
>>>
>>> This is the biggest risk we have IMHO.
>>>
>>>
>>> True you are telling the AS (Webfinger service) what the RS is but
>>> that is not at a place that is useful in the token production process.
>>>
>>>
>>> This has nothing to do with token production.
>>>
>>> What we want to ensure is whether an honest client is correctly
>>> configured and has not been mislead - eg by a phishing page.
>>>
>>>
>>> I also think there are use cases where the AS doesn=E2=80=99t know all =
the
>>> possible RS.   That is not something that a out of band check can
>>> address.
>>>
>>>
>>> May be. Lets identify them.
>>>
>>> There are also cases where a token might be good at multiple RS
>>> endpoints intentionally.
>>>
>>>
>>>  In your solution the client would need to make a discovery request
>>> for each endpoint.
>>>
>>> Sure. Otherwise how would it know if there is one AS or a pool of AS
>>> servers assigned to each instance?
>>>
>>> Those requests lack the context of who the client and resource owner
>>> are.  I think that will be a problem in some use cases.
>>>
>>>
>>> Not sure I agree. This is about discovering a valid set of endpoints.
>>> For mitm, we mainly want to check the hostname is correct. If a
>>> client chooses evil.com  
>>>  the cert can be valid and
>>> TLS will pass. How does it otherwise know it is supposed to talk to
>>> res.example.com  ?
>>>
>>>
>>> If this is
>>>
>>> ...

--94eb2c088c1ef3c71c052e2b9298
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    If the client sends the uri of the resource it intends to se=
nd the token to in the token request the bad guy would get only a token aud=
ianced to itself and not to good RS.=C2=A0 
    

    You can't solve the problem of bearer tokens with multip=
le audiences leaking.=C2=A0=C2=A0 That is a risk inherent in using that sor=
t of token.=C2=A0=C2=A0 Compromise in one RS will impact all of them.=C2=A0=
 
    

    The only safe way with bearer to deal with a RS the AS dosen=
't trust a RS is to only have one audianced in the token. (or by intros=
pection)
    

    We have always known that and left it up to clients to make =
sure they are secure by not sending tokens to bad RS.=C2=A0 
    

    Now people want a AS check to prevent clients from being tri=
cked if developers are given bad info statically or dynamically. 
    

    What you are doing is safe as long as your developers don=
9;t make any mistakes. 
    
If you want to be safe and not have to preconfigure the AS you need to use =
the refresh to get single audianced tokens, or PoP.
    

    John B. 
    

    On Mar 16, 2016 11:27 AM, "George Fletcher&=
quot; <gffletch@aol.com> wrot=
e:
    
 =20
   =20
 =20
  
    
    
    
    
    
    
    On 3/15/16 6:14 PM, John Bradley wrote:
    
    
    
    
    
     =20
      If the AS is audience restricting the tokens then it just needs to
      put the right audience in the token based on what the client is
      asking for. =C2=A0
      
    That is safe as the RS wouldn=E2=80=99t be able to replay
        the token someplace else.
    
    
    
    So let's assuming a client sends a token audience restricted to
    GoodRS instead to EvilRS. When EvilRS replays the token at the
    GoodRS endpoint, how does GoodRS reject the token because when
    GoodRS sends the token to the AS for introspection (or does so
    itself) the token will be audience restricted to the GoodRS and it
    will process the token. The only way to prevent this is with
    client-authentication so that the presenter can be matched against
    who is allowed to present the token (aka PoP).
    
    
    
    In the pure bearer token model, I don't see how this can be
    prevented at the protocol level.
    
    
    
      

    
      
    
      
    That would need to be a AS policy if it wanted to do
        that for unknown RS. =C2=A0=C2=A0
    
      

    
      
    
      
    Allowing more than one audience in a token is a
        convince but a well known security risk with bearer tokens.
    
    
    
    True, but this means clients have to manage many tokens or call the
    token endpoint to get a "downscoped, audience restricted" tok=
en
    every time they need one. This is a very different model than what
    most people think of when they think of OAuth2. Not bad, just
    different:)
    
    
    
      

    
      
    
      
    A AS would probably want to have only one audience
        in a AT for a untrusted RS, but may allow multiple if they are
        all trusted.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 6:28 PM, George Fletcher
              <gff=
letch@aol.com>
              wrote:
    
            
    
            
    
             =20
              
     
    
                
    On 3/15/16 3:26 PM, John
                  Bradley wrote:
    
                
    
                
    
                 =20
                  I think Phil and others are concerned that a developer
                  might get bad info to put in the client , some out of
                  band discovery goes wrong or the user is somehow
                  tricked into specifying a bad resource to the client.
                  

    
                  
    
                  
    So getting a bad resource is a touch
                    hypothetical. 
    
                  
    
                
    
                If we are really trying to solve this problem
                holistically, then we probably need to first describe
                the use cases we want to solve. I'm starting to wonder
                if we are all providing solutions to slightly different
                use cases.
    
                
    
                  

    
                  
    
                  
    For Connect we could suppose that
                    someone publishes a malicious discovery document
                    listing themselves as the RS but all the other
                    endpoints are at the good AS so the client
                    registers, authorizes the user and gives the AT to
                    the bad guy.=C2=A0 The confused client mitigation by
                    returning client_id_and issuer from the
                    authorization endpoint will stop the attack before
                    the token can be given to the token endpoint or RS.
                
    
                Agreed and I'm fine with this solution.
    
                
    
                  

    
                  
    
                  
    So protecting the AT at this point is
                    more for a unknown attack that would confuse
                    whatever protocol/API that is using OAuth about what
                    RS to use.
    
                
    
                Yes. This is where we need to describe some use cases
                (preferably real vs contrived) before we propose
                solutions. In most cases the RS endpoints are hard coded
                into the client or maybe pulled from a different central
                config endpoint (which is fixed).
    
                
    
                That's why the only case I could think of is a client
                that works with multiple RS endpoints from different
                providers that server the same content (e.g.
                PortableContacts API). In this use case, the user of the
                client would need to enter the location of the RS they
                wanted to use and then the flow would start from there.
                In reality, most services like this would have a fixed
                set of RS's they work with and again it wouldn't be
                dynamic.
    
                
    
                  

    
                  
    
                  
    In reality this is what PoP is supposed
                    to be for.
    
                  

    
                  
    
                  
    I guess the question is what short of
                    PoP can we do to prevent the client leaking tokens
                    to bad RS that confuse it via the application
                    protocol.
    
                  

    
                  
    
                  
    If we want to del with this in OAuth
                    then we need to tell the AS where the token is going
                    to be used or tel the client where the token can be
                    used.=C2=A0
    
                  

    
                  
    
                  
    I think letting the client tell the AS
                    where it wants the token used having the AS
                    construct a audience out of that is probably the
                    best thing. =C2=A0to get around having a pre-establishe=
d
                    relationship between the AS and RS.
    
                
    
                Even if the client tells the AS where it wants to use
                the token (via some endpoint URL), the AS still needs to
                have a relationship with the RS (at a minimum as an
                endpointURL-to-RS map) otherwise how can it determine if
                it is allowed to issue an access token to the user for
                that RS. This map is what I want to avoid "building&qu=
ot;
                into the AS. Do we need "dynamic RS registration"=
 to
                support this?
    
                
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 3:14 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        
    =

    
                            
    
                            I think Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                            =C2=A0 1. what RS's the token will be used =
at
    
                            =C2=A0 2. authorization privilege requests
    
                            =C2=A0 3. token-timing adjustments
    
                            
    
                            I'm not sure passing the full endpoint to
                            the AS will help with my concerns... The AS
                            could potentially do a webfinger on the
                            resource URI and determine if it's an RS
                            that it supports... though that requires all
                            RS's to support webfinger. What I really
                            want to avoid is the AS having this list of
                            URIs to RS that is almost assuredly to get
                            out of sync.
    
                            
    
                            
    
                          
    
                          
    On
                            3/15/16 1:56 PM, John Bradley wrote:
    
                          
    
                          
    I think it is a AS policy decision
                            if it should error or take the requested
                            resource and issue a token audianced for
                            that resource.
    
                          Act=
ually,
                            the error cases are interesting. What if the
                            passed in resource/audience doesn't actuall=
y
                            match a requested scope? Or some match and
                            some don't? Is it better to send back a
                            token with less capability? or error the
                            entire request?
                          
    
                            

    
                            
    
                            
    I guess the question is how to
                              transition from now to a future state. =C2=A0
                              If you cannot upgrade all the clients at
                              once.
    
                            

    
                            
    
                            
    A processing rule on the AS
                              that allowed some clients to not send the
                              requested resource , but would error out
                              for other upgraded clients =C2=A0with a
                              "resource not allowed=E2=80=9D oauth err=
or would
                              work and not require the return of the
                              resources. =C2=A0
    
                            

    
                            
    
                            
    If you return the resources
                              and let the client error if it is trying
                              to send to the wrong endpoint that make
                              upgrading easier, but gives less control
                              to the AS.
    
                            

    
                            
    
                            
    
                              
    
                                
    I could
                                    live with it ether way.
    
                                

    
                                
    
                                The advantage of always sending it in
                                the token request is that it allows the
                                AS to do the mapping from a resource URI
                                to one or more abstract audience for the
                                token.
    
                            
    
                          
    
                          I
                            thought Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                            =C2=A0 1. what RS's the token will be used =
at
    
                            =C2=A0 2. authorization privilege requests
    
                            =C2=A0 3. token-timing adjustments
    
                            
    
                            The question is how does a client internally
                            reference a resource server? If it's a fixe=
d
                            RS endpoint, then it sort of doesn't matter=
,
                            the client isn't going to send the token to
                            the wrong endpoint anyway and it can easily
                            reference the audience by an abstract URI.
    
                            
    
                            If the client can dynamically find new RS's
                            to interact with. How does that happen? Does
                            the client get handed an endpoint to use? or
                            does it do some sort of discovery to
                            determine the endpoint? I suppose both are
                            possible.
    
                            
    
                            Could we prescribe that the realm value of
                            RFC 6750 error response be effectively a
                            resource-service-id (like issuer for the
                            AS). The client would then need to do
                            discovery on that value to find the valid
                            endpoints of the RS. This could be done once
                            and the resource-service-id could be used as
                            the "abstract" RS identifier. This re=
quires
                            no more discovery than adding an AS to the
                            client.
    
                              
                          
    
                            
    
                              

    
                              
    
                              
    That might help address
                                George=E2=80=99s concern.
    
                            
    
                          
    
                          I&#=
39;m
                            not sure passing the full endpoint to the AS
                            will help with my concerns... The AS could
                            potentially do a webfinger on the resource
                            URI and determine if it's an RS that it
                            supports... though that requires all RS's t=
o
                            support webfinger. What I really want to
                            avoid is the AS having this map of URIs to
                            RS that is almost assuredly to get out of
                            sync.
                          
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                              
    
                              

    
                                
    
                                  
    On Mar 15, 2016, at 2:44
                                    PM, Brian Campbell <bcampbell@pingidentity.com>

                                    wrote:
    
                                  
    
                                  
    
                                    
    I was
                                      thinking it'd be simpler to error=
,
                                      if the requested resource(s)
                                      weren't okay. That puts the burde=
n
                                      of checking in the AS. And doesn'=
t
                                      add anything to the token or
                                      authorization response. I see the
                                      potential similarity to scope but
                                      not sure it's worth it.=C2=A0 =C2=
=A0=C2=A0
    
                                    

    
                                      
    On Tue,
                                        Mar 15, 2016 at 11:37 AM, John
                                        Bradley=C2=A0<ve7jtb@ve7jtb.com&g=
t;=C2=A0wrote:
    
                                        
    
                                          
    If the client
                                            specifies the resource it
                                            wants the token for, then
                                            the meta-data would not be
                                            required unless the
                                            resources the token is good
                                            at are different from the
                                            request. =C2=A0
                                            
    Lat is the
                                              same logic as scopes.
    
                                            

    
                                            
    
                                            
    For backwards
                                              compatibility if the
                                              client is happy with the
                                              default resources based on
                                              scopes then I think it is
                                              a good idea to tell the
                                              client what the resources
                                              are in the response.
    
                                            

    
                                            
    
                                            
    I suspect that
                                              it is simpler with less
                                              optionality and always
                                              return the resources, even
                                              if they are not required.
                                            

    
                                            
    
                                            
    John B.
    
                                            
    
                                              
    
                                                

    
                                                
    
                                                
    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:46 PM, Brian
                                                        Campbell <bcampbell@pingidentity.com>

                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
    If
                                                          the client
                                                          specifies the
                                                          desired
                                                          audience(s)/resou=
rce(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for.=C2=A0<=
/span>
    
                                                          
    
                                                          
    
                                                          

    
                                                          
    On

                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley=C2=
=A0<ve7jtb@v=
e7jtb.com>=C2=A0wrote:
    
                                                          
    
                                                          
    Yes,

                                                          =C2=A0I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The

                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          audience.
    
                                                          

    
                                                          
    
                                                          
    If

                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time.=C2=A0<=
/div>
                                                          

    
                                                          
    
                                                          
    In

                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil=E2=
=80=99s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
    =C2=A0=C2=A0=

    
                                                          
    If

                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.=C2=A0 That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    William

                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John

                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    On

                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>

                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed&=
quot;
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spe=
c
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On

                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found th=
e
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously=C2=A0
    
                                                          
    
                                                          Hans.=C2=A0=

    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote:=C2=
=A0
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty,=C2=
=A0
    
                                                          it=E2=80=99s not =
even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases =E2=80=
=94
                                                          it=E2=80=99s=C2=A0
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution=C2=A0
    
                                                          mechanism in
                                                          that case.=
=C2=A0
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we=E2=80=
=99ve
                                                          really=C2=
=A0
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into=
=C2=A0
    
                                                          =E2=80=9Cscope=E2=
=80=9D that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better:=C2=
=A0
    
                                                          
    
                                                          
    
                                                          =C2=A0=C2=
=A0-
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile)=C2=
=A0
    
                                                          =C2=A0=C2=
=A0-
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete)=C2=A0
    
                                                          =C2=A0=C2=
=A0-
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work?=C2=A0=

    
                                                          (offline_access/r=
efresh_token,

                                                          one time use,
                                                          next hour,
                                                          etc)=C2=A0<=
/span>
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that=C2=A0<=
/span>
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token=C2=A0=

    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard.=C2=
=A0
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in=
=C2=A0
    
                                                          with things
                                                          like
                                                          =E2=80=9Coffline_=
access=E2=80=9D
                                                          in certain
                                                          APIs.=C2=A0=

    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we=E2=80=99re goi=
ng to
                                                          be adding
                                                          things=C2=
=A0
    
                                                          like
                                                          =E2=80=9Caudience=
=E2=80=9D or
                                                          =E2=80=9Cresource=
=E2=80=9D or
                                                          both to the
                                                          token
                                                          requests.=
=C2=A0
    
                                                          
    
                                                          =C2=A0=C2=
=A0=E2=80=94
                                                          Justin=C2=
=A0
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com=C2=A0
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote:=C2=
=A0
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify=C2=
=A0
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the=C2=A0
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for.=C2=A0
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about=C2=A0
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys.=C2=A0=

    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are=
=C2=A0
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making=C2=A0
    
                                                          a mess of
                                                          scopes.=C2=
=A0
    
                                                          
    
                                                          John B.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com=C2=A0<=
/span>
    
                                                          <mailto:phil.hunt@oracle.com>>

                                                          wrote:=C2=
=A0
    
                                                          
    
                                                          Inline=C2=
=A0
    
                                                          
    
                                                          Phil=C2=A0<=
/span>
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com=C2=A0<=
br>
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote:=C2=
=A0
    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.=C2=A0 O=
ne
                                                          was to provide
                                                          a spec for AS
                                                          metadata.=
=C2=A0
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack.=C2=
=A0
                                                          The request
                                                          was=C2=A0
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don=E2=80=99t=C2=A0
    
                                                          otherwise need
                                                          discovery.=
=C2=A0
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See=C2=A0
    
                                                          http://tools.ietf.org/wg/oauth=
/charters?item=3Dcharter-oauth-2016-01-22.txt=C2=A0
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint=C2=
=A0
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without=C2=
=A0
    
                                                          discovery.=
=C2=A0
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to=
=C2=A0
    
                                                          the wrong
                                                          endpoint?=
=C2=A0
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably=C2=A0
    
                                                          doesn=E2=80=99t n=
eed
                                                          discovery.=
=C2=A0
    
                                                          
    
                                                          We agree=C2=
=A0
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find=
=C2=A0
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting=C2=A0
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me.=C2=A0
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating=
=C2=A0
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives=C2=
=A0
    
                                                          what the
                                                          resource is.=C2=A0
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not=
=C2=A0
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service.=C2=
=A0
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we=C2=A0
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have=
=C2=A0
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all.=C2=
=A0
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO.=C2=A0
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but=C2=A0
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production.=
=C2=A0
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly=C2=A0
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page.=C2=A0=

    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn=E2=
=80=99t
                                                          know all the=C2=A0
    
                                                          possible RS.=C2=
=A0=C2=A0
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can=
=C2=A0
    
                                                          address.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them.=C2=A0
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS=C2=A0
    
                                                          endpoints
                                                          intentionally.=C2=A0
    
                                                          
    
                                                          
    
                                                          
    =C2=A0In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request=C2=
=A0
    
                                                          for each
                                                          endpoint.=
=C2=A0
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS=
=C2=A0
    
                                                          servers
                                                          assigned to
                                                          each instance?=C2=A0
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner=C2=A0=

    
                                                          are.=C2=A0 I thin=
k
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints.=
=C2=A0
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a=C2=A0
    
                                                          client chooses=C2=A0evil.com=
=C2=A0<http://evil.com/>=C2=A0the cert can be valid and=C2=A0
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to=
=C2=A0
    
                                                          res.example.com=C2=A0=
<http://res.exampl=
e.com/>?=C2=A0
    
                                                          

    
                                                          If this is
             
    =

    =

    =

    ...
    

--94eb2c088c1ef3c71c052e2b9298--


From nobody Wed Mar 16 08:01:44 2016
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 509AF12D9AD for ; Wed, 16 Mar 2016 08:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, 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=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 ur232StU9Gap for ; Wed, 16 Mar 2016 08:01:36 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 7C53D12D97C for ; Wed, 16 Mar 2016 08:01:17 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id av4so118129890igc.1 for ; Wed, 16 Mar 2016 08:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WxWeBQ/0GbLiO4JVy9B84uS+4Ujy7DMAxhTiSsw+rdo=; b=CwZlsUNc+q3QuTpKxw8oPf+SplsbBwcelVwi33P8IJnFPL7S4jAiHDra3yaRX9eCIK zT/olDFY0Ngmg3flr2SRpmXrPq2RtiriIo1RXc+R/9SCJjzMz6EH2+rQpdzmQTfi3xnQ t7FMeECUxkOk1KBXf7MbOqWcNuYnPiYy5Lllo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WxWeBQ/0GbLiO4JVy9B84uS+4Ujy7DMAxhTiSsw+rdo=; b=J34HJJ9FajQp6OFAdCLdu3FZV7MDQPt4r7qn+e4Y735wpEJaLNZ6TsiWKYA3MO2thj u9KJMi8InqkWrU6yrPWnmVWvcPkgHijSbRWdJ0Zwak6TGGxQpLZhOjDbbpfrBT7+WzO/ BZXkE0LEU9CVvUXNkaZEUn2b6p/3UnNTCvDao+6TsFjEQJ0EqU74h0KBVz7yWYCDY2Os yl8lDBdDHYOtTZFZ3g1WtOHec7CcDpfBBbNdJCxdQ3MHtWVQ/FQfgUln5zn0DfW7uJo7 8fpeBhn8B8lUFAPkOka0RYhsajMxkecOgdZPq/t7qm/n/TqRmg7q5IVzb9ArLbDSpWdU uzIQ==
X-Gm-Message-State: AD7BkJLLixikm0ElQQcmUliQM2itomFeq/0BQNWhzQQHL1jaAmqw70uDTRyifjwrD4VXVwAjgB3hTDI20G0TMS8P
X-Received: by 10.50.119.103 with SMTP id kt7mr6174731igb.49.1458140476601; Wed, 16 Mar 2016 08:01:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Wed, 16 Mar 2016 08:00:46 -0700 (PDT)
In-Reply-To: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>  <56E96D48.90704@aol.com> 
From: Brian Campbell 
Date: Wed, 16 Mar 2016 09:00:46 -0600
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=089e010d9378241b35052e2bc9dc
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 15:01:41 -0000

--089e010d9378241b35052e2bc9dc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Right, if the client asks for a token to use at https://evil.rs then the AS
can audience restrict the token to https://evil.rs so that it wouldn't be
usable at https://good.rs.



On Wed, Mar 16, 2016 at 8:46 AM, John Bradley  wrote:

> If the client sends the uri of the resource it intends to send the token
> to in the token request the bad guy would get only a token audianced to
> itself and not to good RS.
>
> You can't solve the problem of bearer tokens with multiple audiences
> leaking.   That is a risk inherent in using that sort of token.
> Compromise in one RS will impact all of them.
>
> The only safe way with bearer to deal with a RS the AS dosen't trust a RS
> is to only have one audianced in the token. (or by introspection)
>
> We have always known that and left it up to clients to make sure they are
> secure by not sending tokens to bad RS.
>
> Now people want a AS check to prevent clients from being tricked if
> developers are given bad info statically or dynamically.
>
> What you are doing is safe as long as your developers don't make any
> mistakes.
> If you want to be safe and not have to preconfigure the AS you need to us=
e
> the refresh to get single audianced tokens, or PoP.
>
> John B.
> On Mar 16, 2016 11:27 AM, "George Fletcher"  wrote:
>
>>
>>
>> On 3/15/16 6:14 PM, John Bradley wrote:
>>
>> If the AS is audience restricting the tokens then it just needs to put
>> the right audience in the token based on what the client is asking for.
>> That is safe as the RS wouldn=E2=80=99t be able to replay the token some=
place
>> else.
>>
>> So let's assuming a client sends a token audience restricted to GoodRS
>> instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint,
>> how does GoodRS reject the token because when GoodRS sends the token to =
the
>> AS for introspection (or does so itself) the token will be audience
>> restricted to the GoodRS and it will process the token. The only way to
>> prevent this is with client-authentication so that the presenter can be
>> matched against who is allowed to present the token (aka PoP).
>>
>> In the pure bearer token model, I don't see how this can be prevented at
>> the protocol level.
>>
>>
>> That would need to be a AS policy if it wanted to do that for unknown RS=
.
>>
>>
>> Allowing more than one audience in a token is a convince but a well know=
n
>> security risk with bearer tokens.
>>
>> True, but this means clients have to manage many tokens or call the toke=
n
>> endpoint to get a "downscoped, audience restricted" token every time the=
y
>> need one. This is a very different model than what most people think of
>> when they think of OAuth2. Not bad, just different:)
>>
>>
>> A AS would probably want to have only one audience in a AT for a
>> untrusted RS, but may allow multiple if they are all trusted.
>>
>> John B.
>>
>>
>> On Mar 15, 2016, at 6:28 PM, George Fletcher  wrote:
>>
>>
>> On 3/15/16 3:26 PM, John Bradley wrote:
>>
>> I think Phil and others are concerned that a developer might get bad inf=
o
>> to put in the client , some out of band discovery goes wrong or the user=
 is
>> somehow tricked into specifying a bad resource to the client.
>>
>> So getting a bad resource is a touch hypothetical.
>>
>> If we are really trying to solve this problem holistically, then we
>> probably need to first describe the use cases we want to solve. I'm
>> starting to wonder if we are all providing solutions to slightly differe=
nt
>> use cases.
>>
>>
>> For Connect we could suppose that someone publishes a malicious discover=
y
>> document listing themselves as the RS but all the other endpoints are at
>> the good AS so the client registers, authorizes the user and gives the A=
T
>> to the bad guy.  The confused client mitigation by returning client_id_a=
nd
>> issuer from the authorization endpoint will stop the attack before the
>> token can be given to the token endpoint or RS.
>>
>> Agreed and I'm fine with this solution.
>>
>>
>> So protecting the AT at this point is more for a unknown attack that
>> would confuse whatever protocol/API that is using OAuth about what RS to
>> use.
>>
>> Yes. This is where we need to describe some use cases (preferably real v=
s
>> contrived) before we propose solutions. In most cases the RS endpoints a=
re
>> hard coded into the client or maybe pulled from a different central conf=
ig
>> endpoint (which is fixed).
>>
>> That's why the only case I could think of is a client that works with
>> multiple RS endpoints from different providers that server the same cont=
ent
>> (e.g. PortableContacts API). In this use case, the user of the client wo=
uld
>> need to enter the location of the RS they wanted to use and then the flo=
w
>> would start from there. In reality, most services like this would have a
>> fixed set of RS's they work with and again it wouldn't be dynamic.
>>
>>
>> In reality this is what PoP is supposed to be for.
>>
>> I guess the question is what short of PoP can we do to prevent the clien=
t
>> leaking tokens to bad RS that confuse it via the application protocol.
>>
>> If we want to del with this in OAuth then we need to tell the AS where
>> the token is going to be used or tel the client where the token can be
>> used.
>>
>> I think letting the client tell the AS where it wants the token used
>> having the AS construct a audience out of that is probably the best thin=
g.
>>  to get around having a pre-established relationship between the AS and =
RS.
>>
>> Even if the client tells the AS where it wants to use the token (via som=
e
>> endpoint URL), the AS still needs to have a relationship with the RS (at=
 a
>> minimum as an endpointURL-to-RS map) otherwise how can it determine if i=
t
>> is allowed to issue an access token to the user for that RS. This map is
>> what I want to avoid "building" into the AS. Do we need "dynamic RS
>> registration" to support this?
>>
>>
>> John B.
>>
>> On Mar 15, 2016, at 3:14 PM, George Fletcher  wrote:
>>
>>
>>
>> I think Justin provided a good break down of the different aspects a
>> client wants to specify about the requested token. (my paraphrase)
>>   1. what RS's the token will be used at
>>   2. authorization privilege requests
>>   3. token-timing adjustments
>>
>> I'm not sure passing the full endpoint to the AS will help with my
>> concerns... The AS could potentially do a webfinger on the resource URI =
and
>> determine if it's an RS that it supports... though that requires all RS'=
s
>> to support webfinger. What I really want to avoid is the AS having this
>> list of URIs to RS that is almost assuredly to get out of sync.
>>
>>
>>
>> On 3/15/16 1:56 PM, John Bradley wrote:
>>
>> I think it is a AS policy decision if it should error or take the
>> requested resource and issue a token audianced for that resource.
>>
>> Actually, the error cases are interesting. What if the passed in
>> resource/audience doesn't actually match a requested scope? Or some matc=
h
>> and some don't? Is it better to send back a token with less capability? =
or
>> error the entire request?
>>
>>
>> I guess the question is how to transition from now to a future state.
>> If you cannot upgrade all the clients at once.
>>
>> A processing rule on the AS that allowed some clients to not send the
>> requested resource , but would error out for other upgraded clients  wit=
h a
>> "resource not allowed=E2=80=9D oauth error would work and not require th=
e return of
>> the resources.
>>
>> If you return the resources and let the client error if it is trying to
>> send to the wrong endpoint that make upgrading easier, but gives less
>> control to the AS.
>>
>> I could live with it ether way.
>>
>> The advantage of always sending it in the token request is that it allow=
s
>> the AS to do the mapping from a resource URI to one or more abstract
>> audience for the token.
>>
>> I thought Justin provided a good break down of the different aspects a
>> client wants to specify about the requested token. (my paraphrase)
>>   1. what RS's the token will be used at
>>   2. authorization privilege requests
>>   3. token-timing adjustments
>>
>> The question is how does a client internally reference a resource server=
?
>> If it's a fixed RS endpoint, then it sort of doesn't matter, the client
>> isn't going to send the token to the wrong endpoint anyway and it can
>> easily reference the audience by an abstract URI.
>>
>> If the client can dynamically find new RS's to interact with. How does
>> that happen? Does the client get handed an endpoint to use? or does it d=
o
>> some sort of discovery to determine the endpoint? I suppose both are
>> possible.
>>
>> Could we prescribe that the realm value of RFC 6750 error response be
>> effectively a resource-service-id (like issuer for the AS). The client
>> would then need to do discovery on that value to find the valid endpoint=
s
>> of the RS. This could be done once and the resource-service-id could be
>> used as the "abstract" RS identifier. This requires no more discovery th=
an
>> adding an AS to the client.
>>
>>
>> That might help address George=E2=80=99s concern.
>>
>> I'm not sure passing the full endpoint to the AS will help with my
>> concerns... The AS could potentially do a webfinger on the resource URI =
and
>> determine if it's an RS that it supports... though that requires all RS'=
s
>> to support webfinger. What I really want to avoid is the AS having this =
map
>> of URIs to RS that is almost assuredly to get out of sync.
>>
>>
>> John B.
>>
>>
>> On Mar 15, 2016, at 2:44 PM, Brian Campbell <
>> bcampbell@pingidentity.com> wrote:
>>
>> I was thinking it'd be simpler to error, if the requested resource(s)
>> weren't okay. That puts the burden of checking in the AS. And doesn't ad=
d
>> anything to the token or authorization response. I see the potential
>> similarity to scope but not sure it's worth it.
>>
>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley < 
>> ve7jtb@ve7jtb.com> wrote:
>>
>>> If the client specifies the resource it wants the token for, then the
>>> meta-data would not be required unless the resources the token is good =
at
>>> are different from the request.
>>> Lat is the same logic as scopes.
>>>
>>> For backwards compatibility if the client is happy with the default
>>> resources based on scopes then I think it is a good idea to tell the cl=
ient
>>> what the resources are in the response.
>>>
>>> I suspect that it is simpler with less optionality and always return th=
e
>>> resources, even if they are not required.
>>>
>>> John B.
>>>
>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell <
>>> bcampbell@pingidentity.com> wrote:
>>>
>>> If the client specifies the desired audience(s)/resource(s), is that
>>> metadata to the client needed? The AS can audience restrict the token a=
s
>>> needed or respond with an error if it can't or wont issue a token for t=
he
>>> resource the client asked for.
>>>
>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley < 
>>> ve7jtb@ve7jtb.com> wrote:
>>>
>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>
>>>> The AS needs to infer an audience from the scopes snd/or have the
>>>> client specify the desired audience.
>>>>
>>>> If the AT has a audience or audiences then as long as the endpoint URI
>>>> are provided as meta-data with the token, the client can determine if =
it is
>>>> sending the token to the correct place.
>>>>
>>>> I think Phil would prefer the server rather than the client do the
>>>> check, but the client always needs to take some responsibility to not =
leak
>>>> tokens giving them to the wrong RS or the code to the wrong token endp=
oint
>>>> is leaking.
>>>>
>>>> I imagine that claims based access tokens are going to become more
>>>> popular and the static relationship between one RS and one AS will not=
 be
>>>> the majority of deployments over time.
>>>>
>>>> In any case where the client is configured up front to know the RS and
>>>> the AS it seems like that would not require Phil=E2=80=99s Solution, b=
ut that is
>>>> the only case supported by that discovery.
>>>>
>>>> If the client itself is bad there is not much you can do to stop it
>>>> from passing on the AT in way way it wants.  That however is a differe=
nt
>>>> problem and needs claimed URI or attestations to prevent client spoofi=
ng.
>>>> William and I are working on that in the mobile best practices draft.
>>>>
>>>> John B.
>>>>
>>>>
>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher < 
>>>> gffletch@aol.com> wrote:
>>>>
>>>> I worry about two directions I see in this thread...
>>>>
>>>> 1. Client's accessing resources dynamically so that discovery is
>>>> required to know the correct AS, etc. This is pretty much the classic =
use
>>>> case for UMA and I'd rather not re-invent the wheel.
>>>>
>>>> 2. Creating a tight coupling between RS and AS such that RS endpoint
>>>> changes must be continually communicated to the AS. If an RS supports
>>>> multiple AS's then the RS has to deal with "guaranteed" delivery. The =
AS
>>>> needs an endpoint to receive such communications. If not dynamic via A=
PIs,
>>>> then deployment of the new RS is bound by the associated AS's getting =
and
>>>> deploying the new endpoints. Can both endpoints of the RS be supported
>>>> within the AS for some period of time, etc. This is an operation night=
mare
>>>> and almost assuredly going to go wrong in production.
>>>>
>>>> Maybe an OAuth2 "audience binding" spec is what's needed for those
>>>> deployments that require this. I believe that is what John Bradley is
>>>> suggesting.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>
>>>> +1, I've found the very same in OAuth deployments that I was involved
>>>> in; the hard part is to give names and descriptions to these concepts =
so
>>>> that they cover all use cases and can be applied unambiguously
>>>>
>>>> Hans.
>>>>
>>>> On 3/14/16 10:44 PM, Justin Richer wrote:
>>>>
>>>> I agree that this is valuable, and not just for PoP. In all honesty,
>>>> it=E2=80=99s not even really required for PoP to function in many case=
s =E2=80=94 it=E2=80=99s
>>>> just an optimization for one particular kind of key distribution
>>>> mechanism in that case.
>>>>
>>>> In the years of deployment experience with OAuth 2, I think we=E2=80=
=99ve really
>>>>
>>>> got three different kinds of things that currently get folded into
>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating out bette=
r:
>>>>
>>>>
>>>>   - What things do I want to access? (photos, profile)
>>>>   - What actions do I want to take on these things? (read, write,
>>>> delete)
>>>>   - How long do I want these tokens to work?
>>>> (offline_access/refresh_token, one time use, next hour, etc)
>>>>
>>>>
>>>> I think the first one is close to the audience/resource parameters tha=
t
>>>>
>>>> have been bandied about a few times, including in the current token
>>>> exchange document. We should be consistent across drafts in that regar=
d.
>>>>
>>>> The second is more traditional scope-ish. The third has been patched i=
n
>>>>
>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain APIs.
>>>>
>>>> Just another vector to think about if we=E2=80=99re going to be adding=
 things
>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D or both =
to the token requests.
>>>>
>>>>   =E2=80=94 Justin
>>>>
>>>>
>>>> On Mar 14, 2016, at 6:26 PM, John Bradley < 
>>>> ve7jtb@ve7jtb.com
>>>>  >
>>>> wrote:
>>>>
>>>> Yes I will work on another proposal for allowing clients to specify
>>>> what resource they want a token for and providing the meta-data to the
>>>> client about the resources that a token is valid for.
>>>>
>>>> We have part of it in the POP key distribution spec and talked about
>>>> separating it, as it is used more places than just for assigning keys.
>>>> I know some AS use different token formats for different RS so are
>>>> all-ready needing to pass the resource in the request to avoid making
>>>> a mess of scopes.
>>>>
>>>> John B.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) < 
>>>> phil.hunt@oracle.com
>>>> 
>>>> > wrote:
>>>>
>>>> Inline
>>>>
>>>> Phil
>>>>
>>>> On Mar 14, 2016, at 14:13, John Bradley < 
>>>> ve7jtb@ve7jtb.com
>>>>  >
>>>> wrote:
>>>>
>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>> The other was to mitigate the client mixup attack.  The request was
>>>> to do the latter without requiring the former for clients that don=E2=
=80=99t
>>>> otherwise need discovery.
>>>>
>>>> There is no mandate for any of this. See
>>>>
>>>> 
>>>> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-2=
2.txt
>>>>
>>>>
>>>>
>>>> Returning the issuer and client_id from the authorization endpoint
>>>> and the client checking them can be done by the client without
>>>> discovery.
>>>>
>>>>
>>>> How does this address the issue of whether the client is talking to
>>>> the wrong endpoint?
>>>>
>>>>
>>>> Any client that has the resource and issuer hard coded probably
>>>> doesn=E2=80=99t need discovery.
>>>>
>>>> We agree
>>>>
>>>>
>>>> One of the things that a client will need discovery for is to find
>>>> the RS, so requiring the client to know the RS URI before getting
>>>> the AS config seems backwards to me.
>>>>
>>>> How can you make an assumption on order? You seem to be conflating
>>>> authentication with authorization by assuming the identity drives
>>>> what the resource is.
>>>>
>>>> There are lots of applications that require user rights but are not
>>>> identify centric. For example a document service.
>>>>
>>>>
>>>> Unless the client tells the AS where it intends to use the token we
>>>> will be leaving a security hole because the bearer tokens will have
>>>> too loose an audience if they have one at all.
>>>>
>>>> This is the biggest risk we have IMHO.
>>>>
>>>>
>>>> True you are telling the AS (Webfinger service) what the RS is but
>>>> that is not at a place that is useful in the token production process.
>>>>
>>>>
>>>> This has nothing to do with token production.
>>>>
>>>> What we want to ensure is whether an honest client is correctly
>>>> configured and has not been mislead - eg by a phishing page.
>>>>
>>>>
>>>> I also think there are use cases where the AS doesn=E2=80=99t know all=
 the
>>>> possible RS.   That is not something that a out of band check can
>>>> address.
>>>>
>>>>
>>>> May be. Lets identify them.
>>>>
>>>> There are also cases where a token might be good at multiple RS
>>>> endpoints intentionally.
>>>>
>>>>
>>>>  In your solution the client would need to make a discovery request
>>>> for each endpoint.
>>>>
>>>> Sure. Otherwise how would it know if there is one AS or a pool of AS
>>>> servers assigned to each instance?
>>>>
>>>> Those requests lack the context of who the client and resource owner
>>>> are.  I think that will be a problem in some use cases.
>>>>
>>>>
>>>> Not sure I agree. This is about discovering a valid set of endpoints.
>>>> For mitm, we mainly want to check the hostname is correct. If a
>>>> client chooses evil.com  
>>>>  the cert can be valid and
>>>> TLS will pass. How does it otherwise know it is supposed to talk to
>>>> res.example.com  ?
>>>>
>>>>
>>>> If this is
>>>>
>>>> ...
>
>

--089e010d9378241b35052e2bc9dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Right, if the client asks for a token to use at https://evil.rs then the AS can audience restrict the=
 token to https://evil.rs so that it wouldn=
't be usable at https://good.rs. 
    =C2=A0

    On Wed, Mar 16, 2016 at 8:46 AM, John Bradley <ve7jtb@ve7jtb.com><=
/span> wrote:
    If the clien=
t sends the uri of the resource it intends to send the token to in the toke=
n request the bad guy would get only a token audianced to itself and not to=
 good RS.=C2=A0 
    

    You can't solve the problem of bearer tokens with multip=
le audiences leaking.=C2=A0=C2=A0 That is a risk inherent in using that sor=
t of token.=C2=A0=C2=A0 Compromise in one RS will impact all of them.=C2=A0=
 
    

    The only safe way with bearer to deal with a RS the AS dosen=
't trust a RS is to only have one audianced in the token. (or by intros=
pection)
    

    We have always known that and left it up to clients to make =
sure they are secure by not sending tokens to bad RS.=C2=A0 
    

    Now people want a AS check to prevent clients from being tri=
cked if developers are given bad info statically or dynamically. 
    

    What you are doing is safe as long as your developers don=
9;t make any mistakes. 
    
If you want to be safe and not have to preconfigure the AS you need to use =
the refresh to get single audianced tokens, or PoP.
    

    John B. 
    

    On Mar 16, 2016 11:27 AM,=
 "George Fletcher" <gffletch@aol.com> wrote:
    <=
/div>
    
 =20
   =20
 =20
  
    
    
    
    
    
    
    On 3/15/16 6:14 PM, John Bradley wrote:
    
    
    
    
    
     =20
      If the AS is audience restricting the tokens then it just needs to
      put the right audience in the token based on what the client is
      asking for. =C2=A0
      
    That is safe as the RS wouldn=E2=80=99t be able to replay
        the token someplace else.
    
    
    
    So let's assuming a client sends a token audience restricted to
    GoodRS instead to EvilRS. When EvilRS replays the token at the
    GoodRS endpoint, how does GoodRS reject the token because when
    GoodRS sends the token to the AS for introspection (or does so
    itself) the token will be audience restricted to the GoodRS and it
    will process the token. The only way to prevent this is with
    client-authentication so that the presenter can be matched against
    who is allowed to present the token (aka PoP).
    
    
    
    In the pure bearer token model, I don't see how this can be
    prevented at the protocol level.
    
    
    
      

    
      
    
      
    That would need to be a AS policy if it wanted to do
        that for unknown RS. =C2=A0=C2=A0
    
      

    
      
    
      
    Allowing more than one audience in a token is a
        convince but a well known security risk with bearer tokens.
    
    
    
    True, but this means clients have to manage many tokens or call the
    token endpoint to get a "downscoped, audience restricted" tok=
en
    every time they need one. This is a very different model than what
    most people think of when they think of OAuth2. Not bad, just
    different:)
    
    
    
      

    
      
    
      
    A AS would probably want to have only one audience
        in a AT for a untrusted RS, but may allow multiple if they are
        all trusted.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 6:28 PM, George Fletcher
              <gff=
letch@aol.com>
              wrote:
    
            
    
            
    
             =20
              
     
    
                
    On 3/15/16 3:26 PM, John
                  Bradley wrote:
    
                
    
                
    
                 =20
                  I think Phil and others are concerned that a developer
                  might get bad info to put in the client , some out of
                  band discovery goes wrong or the user is somehow
                  tricked into specifying a bad resource to the client.
                  

    
                  
    
                  
    So getting a bad resource is a touch
                    hypothetical. 
    
                  
    
                
    
                If we are really trying to solve this problem
                holistically, then we probably need to first describe
                the use cases we want to solve. I'm starting to wonder
                if we are all providing solutions to slightly different
                use cases.
    
                
    
                  

    
                  
    
                  
    For Connect we could suppose that
                    someone publishes a malicious discovery document
                    listing themselves as the RS but all the other
                    endpoints are at the good AS so the client
                    registers, authorizes the user and gives the AT to
                    the bad guy.=C2=A0 The confused client mitigation by
                    returning client_id_and issuer from the
                    authorization endpoint will stop the attack before
                    the token can be given to the token endpoint or RS.
                
    
                Agreed and I'm fine with this solution.
    
                
    
                  

    
                  
    
                  
    So protecting the AT at this point is
                    more for a unknown attack that would confuse
                    whatever protocol/API that is using OAuth about what
                    RS to use.
    
                
    
                Yes. This is where we need to describe some use cases
                (preferably real vs contrived) before we propose
                solutions. In most cases the RS endpoints are hard coded
                into the client or maybe pulled from a different central
                config endpoint (which is fixed).
    
                
    
                That's why the only case I could think of is a client
                that works with multiple RS endpoints from different
                providers that server the same content (e.g.
                PortableContacts API). In this use case, the user of the
                client would need to enter the location of the RS they
                wanted to use and then the flow would start from there.
                In reality, most services like this would have a fixed
                set of RS's they work with and again it wouldn't be
                dynamic.
    
                
    
                  

    
                  
    
                  
    In reality this is what PoP is supposed
                    to be for.
    
                  

    
                  
    
                  
    I guess the question is what short of
                    PoP can we do to prevent the client leaking tokens
                    to bad RS that confuse it via the application
                    protocol.
    
                  

    
                  
    
                  
    If we want to del with this in OAuth
                    then we need to tell the AS where the token is going
                    to be used or tel the client where the token can be
                    used.=C2=A0
    
                  

    
                  
    
                  
    I think letting the client tell the AS
                    where it wants the token used having the AS
                    construct a audience out of that is probably the
                    best thing. =C2=A0to get around having a pre-establishe=
d
                    relationship between the AS and RS.
    
                
    
                Even if the client tells the AS where it wants to use
                the token (via some endpoint URL), the AS still needs to
                have a relationship with the RS (at a minimum as an
                endpointURL-to-RS map) otherwise how can it determine if
                it is allowed to issue an access token to the user for
                that RS. This map is what I want to avoid "building&qu=
ot;
                into the AS. Do we need "dynamic RS registration"=
 to
                support this?
    
                
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 3:14 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        
    =

    
                            
    
                            I think Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                            =C2=A0 1. what RS's the token will be used =
at
    
                            =C2=A0 2. authorization privilege requests
    
                            =C2=A0 3. token-timing adjustments
    
                            
    
                            I'm not sure passing the full endpoint to
                            the AS will help with my concerns... The AS
                            could potentially do a webfinger on the
                            resource URI and determine if it's an RS
                            that it supports... though that requires all
                            RS's to support webfinger. What I really
                            want to avoid is the AS having this list of
                            URIs to RS that is almost assuredly to get
                            out of sync.
    
                            
    
                            
    
                          
    
                          
    On
                            3/15/16 1:56 PM, John Bradley wrote:
    
                          
    
                          
    I think it is a AS policy decision
                            if it should error or take the requested
                            resource and issue a token audianced for
                            that resource.
    
                          Act=
ually,
                            the error cases are interesting. What if the
                            passed in resource/audience doesn't actuall=
y
                            match a requested scope? Or some match and
                            some don't? Is it better to send back a
                            token with less capability? or error the
                            entire request?
                          
    
                            

    
                            
    
                            
    I guess the question is how to
                              transition from now to a future state. =C2=A0
                              If you cannot upgrade all the clients at
                              once.
    
                            

    
                            
    
                            
    A processing rule on the AS
                              that allowed some clients to not send the
                              requested resource , but would error out
                              for other upgraded clients =C2=A0with a
                              "resource not allowed=E2=80=9D oauth err=
or would
                              work and not require the return of the
                              resources. =C2=A0
    
                            

    
                            
    
                            
    If you return the resources
                              and let the client error if it is trying
                              to send to the wrong endpoint that make
                              upgrading easier, but gives less control
                              to the AS.
    
                            

    
                            
    
                            
    
                              
    
                                
    I could
                                    live with it ether way.
    
                                

    
                                
    
                                The advantage of always sending it in
                                the token request is that it allows the
                                AS to do the mapping from a resource URI
                                to one or more abstract audience for the
                                token.
    
                            
    
                          
    
                          I
                            thought Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                            =C2=A0 1. what RS's the token will be used =
at
    
                            =C2=A0 2. authorization privilege requests
    
                            =C2=A0 3. token-timing adjustments
    
                            
    
                            The question is how does a client internally
                            reference a resource server? If it's a fixe=
d
                            RS endpoint, then it sort of doesn't matter=
,
                            the client isn't going to send the token to
                            the wrong endpoint anyway and it can easily
                            reference the audience by an abstract URI.
    
                            
    
                            If the client can dynamically find new RS's
                            to interact with. How does that happen? Does
                            the client get handed an endpoint to use? or
                            does it do some sort of discovery to
                            determine the endpoint? I suppose both are
                            possible.
    
                            
    
                            Could we prescribe that the realm value of
                            RFC 6750 error response be effectively a
                            resource-service-id (like issuer for the
                            AS). The client would then need to do
                            discovery on that value to find the valid
                            endpoints of the RS. This could be done once
                            and the resource-service-id could be used as
                            the "abstract" RS identifier. This re=
quires
                            no more discovery than adding an AS to the
                            client.
    
                              
                          
    
                            
    
                              

    
                              
    
                              
    That might help address
                                George=E2=80=99s concern.
    
                            
    
                          
    
                          I&#=
39;m
                            not sure passing the full endpoint to the AS
                            will help with my concerns... The AS could
                            potentially do a webfinger on the resource
                            URI and determine if it's an RS that it
                            supports... though that requires all RS's t=
o
                            support webfinger. What I really want to
                            avoid is the AS having this map of URIs to
                            RS that is almost assuredly to get out of
                            sync.
                          
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                              
    
                              

    
                                
    
                                  
    On Mar 15, 2016, at 2:44
                                    PM, Brian Campbell <bcampbell@pingidentity.com>

                                    wrote:
    
                                  
    
                                  
    
                                    
    I was
                                      thinking it'd be simpler to error=
,
                                      if the requested resource(s)
                                      weren't okay. That puts the burde=
n
                                      of checking in the AS. And doesn'=
t
                                      add anything to the token or
                                      authorization response. I see the
                                      potential similarity to scope but
                                      not sure it's worth it.=C2=A0 =C2=
=A0=C2=A0
    
                                    

    
                                      
    On Tue,
                                        Mar 15, 2016 at 11:37 AM, John
                                        Bradley=C2=A0<ve7jtb@ve7jtb.com&g=
t;=C2=A0wrote:
    
                                        
    
                                          
    If the client
                                            specifies the resource it
                                            wants the token for, then
                                            the meta-data would not be
                                            required unless the
                                            resources the token is good
                                            at are different from the
                                            request. =C2=A0
                                            
    Lat is the
                                              same logic as scopes.
    
                                            

    
                                            
    
                                            
    For backwards
                                              compatibility if the
                                              client is happy with the
                                              default resources based on
                                              scopes then I think it is
                                              a good idea to tell the
                                              client what the resources
                                              are in the response.
    
                                            

    
                                            
    
                                            
    I suspect that
                                              it is simpler with less
                                              optionality and always
                                              return the resources, even
                                              if they are not required.
                                            

    
                                            
    
                                            
    John B.
    
                                            
    
                                              
    
                                                

    
                                                
    
                                                
    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:46 PM, Brian
                                                        Campbell <bcampbell@pingidentity.c=
om>

                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
    If
                                                          the client
                                                          specifies the
                                                          desired
                                                          audience(s)/resou=
rce(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for.=C2=A0<=
/span>
    
                                                          
    
                                                          
    
                                                          

    
                                                          
    On

                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley=C2=
=A0<ve7j=
tb@ve7jtb.com>=C2=A0wrote:
    
                                                          
    
                                                          
    Yes,

                                                          =C2=A0I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The

                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          audience.
    
                                                          

    
                                                          
    
                                                          
    If

                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time.=C2=A0<=
/div>
                                                          

    
                                                          
    
                                                          
    In

                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil=E2=
=80=99s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
    =C2=A0=C2=A0=

    
                                                          
    If

                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.=C2=A0 That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    William

                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John

                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    On

                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>

                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed&=
quot;
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spe=
c
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On

                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found th=
e
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously=C2=A0
    
                                                          
    
                                                          Hans.=C2=A0=

    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote:=C2=
=A0
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty,=C2=
=A0
    
                                                          it=E2=80=99s not =
even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases =E2=80=
=94
                                                          it=E2=80=99s=C2=A0
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution=C2=A0
    
                                                          mechanism in
                                                          that case.=
=C2=A0
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we=E2=80=
=99ve
                                                          really=C2=
=A0
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into=
=C2=A0
    
                                                          =E2=80=9Cscope=E2=
=80=9D that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better:=C2=
=A0
    
                                                          
    
                                                          
    
                                                          =C2=A0=C2=
=A0-
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile)=C2=
=A0
    
                                                          =C2=A0=C2=
=A0-
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete)=C2=A0
    
                                                          =C2=A0=C2=
=A0-
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work?=C2=A0=

    
                                                          (offline_access/r=
efresh_token,

                                                          one time use,
                                                          next hour,
                                                          etc)=C2=A0<=
/span>
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that=C2=A0<=
/span>
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token=C2=A0=

    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard.=C2=
=A0
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in=
=C2=A0
    
                                                          with things
                                                          like
                                                          =E2=80=9Coffline_=
access=E2=80=9D
                                                          in certain
                                                          APIs.=C2=A0=

    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we=E2=80=99re goi=
ng to
                                                          be adding
                                                          things=C2=
=A0
    
                                                          like
                                                          =E2=80=9Caudience=
=E2=80=9D or
                                                          =E2=80=9Cresource=
=E2=80=9D or
                                                          both to the
                                                          token
                                                          requests.=
=C2=A0
    
                                                          
    
                                                          =C2=A0=C2=
=A0=E2=80=94
                                                          Justin=C2=
=A0
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com=C2=A0
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote:=C2=
=A0
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify=C2=
=A0
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the=C2=A0
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for.=C2=A0
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about=C2=A0
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys.=C2=A0=

    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are=
=C2=A0
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making=C2=A0
    
                                                          a mess of
                                                          scopes.=C2=
=A0
    
                                                          
    
                                                          John B.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com=C2=A0<=
/span>
    
                                                          <mailto:phil.hunt@oracle.com>>

                                                          wrote:=C2=
=A0
    
                                                          
    
                                                          Inline=C2=
=A0
    
                                                          
    
                                                          Phil=C2=A0<=
/span>
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com=C2=A0<=
br>
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote:=C2=
=A0
    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.=C2=A0 O=
ne
                                                          was to provide
                                                          a spec for AS
                                                          metadata.=
=C2=A0
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack.=C2=
=A0
                                                          The request
                                                          was=C2=A0
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don=E2=80=99t=C2=A0
    
                                                          otherwise need
                                                          discovery.=
=C2=A0
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See=C2=A0
    
                                                          http://tools.ietf.org/wg=
/oauth/charters?item=3Dcharter-oauth-2016-01-22.txt=C2=A0<=
br>
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint=C2=
=A0
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without=C2=
=A0
    
                                                          discovery.=
=C2=A0
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to=
=C2=A0
    
                                                          the wrong
                                                          endpoint?=
=C2=A0
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably=C2=A0
    
                                                          doesn=E2=80=99t n=
eed
                                                          discovery.=
=C2=A0
    
                                                          
    
                                                          We agree=C2=
=A0
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find=
=C2=A0
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting=C2=A0
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me.=C2=A0
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating=
=C2=A0
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives=C2=
=A0
    
                                                          what the
                                                          resource is.=C2=A0
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not=
=C2=A0
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service.=C2=
=A0
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we=C2=A0
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have=
=C2=A0
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all.=C2=
=A0
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO.=C2=A0
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but=C2=A0
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production.=
=C2=A0
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly=C2=A0
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page.=C2=A0=

    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn=E2=
=80=99t
                                                          know all the=C2=A0
    
                                                          possible RS.=C2=
=A0=C2=A0
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can=
=C2=A0
    
                                                          address.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them.=C2=A0
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS=C2=A0
    
                                                          endpoints
                                                          intentionally.=C2=A0
    
                                                          
    
                                                          
    
                                                          
    =C2=A0In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request=C2=
=A0
    
                                                          for each
                                                          endpoint.=
=C2=A0
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS=
=C2=A0
    
                                                          servers
                                                          assigned to
                                                          each instance?=C2=A0
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner=C2=A0=

    
                                                          are.=C2=A0 I thin=
k
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases.=C2=
=A0
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints.=
=C2=A0
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a=C2=A0
    
                                                          client chooses=C2=A0evil.com=
=C2=A0<http://evil.com/>=C2=A0the cert can be valid and=C2=A0
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to=
=C2=A0
    
                                                          res.example.com=C2=A0=
<http://res.exampl=
e.com/>?=C2=A0
    
                                                          

    
                                                          If this is
             
    =

    =

    =

    ...
    


    

--089e010d9378241b35052e2bc9dc--


From nobody Wed Mar 16 08:23:17 2016
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 20D2512D9C0 for ; Wed, 16 Mar 2016 08:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 Q5B80iMAE7d7 for ; Wed, 16 Mar 2016 08:23:07 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 8B5CB12D9C7 for ; Wed, 16 Mar 2016 08:22:17 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2GFMBbO021315 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2016 15:22:11 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2GFMBDF014772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 15:22:11 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2GFMAYS001457; Wed, 16 Mar 2016 15:22:11 GMT
Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Mar 2016 08:22:09 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-E1FD9CCC-54C2-4500-A6E6-6E0BC59147BC
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Wed, 16 Mar 2016 08:22:07 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <4032B3D5-C3EF-4269-82B2-C640D09A6A44@oracle.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>  <56E96D48.90704@aol.com> 
To: John Bradley 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 15:23:15 -0000

--Apple-Mail-E1FD9CCC-54C2-4500-A6E6-6E0BC59147BC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Your solution seems to require resourceuri =3D audience.=20

Bound config avoids trying to require conversion or urls into aud and vice v=
ersa.=20

Phil

> On Mar 16, 2016, at 07:46, John Bradley  wrote:
>=20
> If the client sends the uri of the resource it intends to send the token t=
o in the token request the bad guy would get only a token audianced to itsel=
f and not to good RS.=20
>=20
> You can't solve the problem of bearer tokens with multiple audiences leaki=
ng.   That is a risk inherent in using that sort of token.   Compromise in o=
ne RS will impact all of them.=20
>=20
> The only safe way with bearer to deal with a RS the AS dosen't trust a RS i=
s to only have one audianced in the token. (or by introspection)
>=20
> We have always known that and left it up to clients to make sure they are s=
ecure by not sending tokens to bad RS.=20
>=20
> Now people want a AS check to prevent clients from being tricked if develo=
pers are given bad info statically or dynamically.
>=20
> What you are doing is safe as long as your developers don't make any mista=
kes.=20
> If you want to be safe and not have to preconfigure the AS you need to use=
 the refresh to get single audianced tokens, or PoP.
>=20
> John B.
>=20
>> On Mar 16, 2016 11:27 AM, "George Fletcher"  wrote:
>>=20
>>=20
>>> On 3/15/16 6:14 PM, John Bradley wrote:
>>> If the AS is audience restricting the tokens then it just needs to put t=
he right audience in the token based on what the client is asking for. =20
>>> That is safe as the RS wouldn=E2=80=99t be able to replay the token some=
place else.
>> So let's assuming a client sends a token audience restricted to GoodRS in=
stead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, how d=
oes GoodRS reject the token because when GoodRS sends the token to the AS fo=
r introspection (or does so itself) the token will be audience restricted to=
 the GoodRS and it will process the token. The only way to prevent this is w=
ith client-authentication so that the presenter can be matched against who i=
s allowed to present the token (aka PoP).
>>=20
>> In the pure bearer token model, I don't see how this can be prevented at t=
he protocol level.
>>>=20
>>> That would need to be a AS policy if it wanted to do that for unknown RS=
.  =20
>>>=20
>>> Allowing more than one audience in a token is a convince but a well know=
n security risk with bearer tokens.
>> True, but this means clients have to manage many tokens or call the token=
 endpoint to get a "downscoped, audience restricted" token every time they n=
eed one. This is a very different model than what most people think of when t=
hey think of OAuth2. Not bad, just different:)
>>>=20
>>> A AS would probably want to have only one audience         in a AT for a=
 untrusted RS, but may allow multiple if they are all trusted.
>>>=20
>>> John B.
>>>=20
>>>=20
>>>> On Mar 15, 2016, at 6:28 PM, George Fletcher  wrote:
>>>>=20
>>>>=20
>>>>> On 3/15/16 3:26 PM, John Bradley wrote:
>>>>> I think Phil and others are concerned that a developer might get bad i=
nfo to put in the client , some out of band discovery goes wrong or the user=
 is somehow tricked into specifying a bad resource to the client.
>>>>>=20
>>>>> So getting a bad resource is a touch hypothetical.
>>>> If we are really trying to solve this problem holistically, then we pro=
bably need to first describe the use cases we want to solve. I'm starting to=
 wonder if we are all providing solutions to slightly different use cases.
>>>>>=20
>>>>> For Connect we could suppose that someone publishes a malicious discov=
ery document listing themselves as the RS but all the other endpoints are at=
 the good AS so the client registers, authorizes the user and gives the AT t=
o the bad guy.  The confused client mitigation by returning client_id_and is=
suer from the authorization endpoint will stop the attack before the token c=
an be given to the token endpoint or RS.
>>>> Agreed and I'm fine with this solution.
>>>>>=20
>>>>> So protecting the AT at this point is more for a unknown attack that w=
ould confuse whatever protocol/API that is using OAuth about what RS to use.=

>>>> Yes. This is where we need to describe some use cases (preferably real v=
s contrived) before we propose solutions. In most cases the RS endpoints are=
 hard coded                 into the client or maybe pulled from a different=
 central config endpoint (which is fixed).
>>>>=20
>>>> That's why the only case I could think of is a client that works with m=
ultiple RS endpoints from different providers that server the same content (=
e.g. PortableContacts API). In this use case, the user of the client would n=
eed to enter the location of the RS they wanted to use and then the flow wou=
ld start from there. In reality, most services like this would have a fixed s=
et of RS's they work with and again it wouldn't be dynamic.
>>>>>=20
>>>>> In reality this is what PoP is supposed to be for.
>>>>>=20
>>>>> I guess the question is what short of PoP can we do to prevent the cli=
ent leaking tokens to bad RS that confuse it via the application protocol.
>>>>>=20
>>>>> If we want to del with this in OAuth then we need to tell the AS where=
 the token is going to be used or tel the client where the token can be used=
.=20
>>>>>=20
>>>>> I think letting the client tell the AS where it wants the token used h=
aving the AS construct a audience out of that is probably the best thing.  t=
o get around having a pre-established relationship between the AS and RS.
>>>> Even if the client tells the AS where it wants to use the token (via so=
me endpoint URL), the AS still needs to have a relationship with the RS (at a=
 minimum as an endpointURL-to-RS map) otherwise how can it determine if it i=
s allowed to issue an access token to the user for that RS. This map is what=
 I want to avoid "building" into the AS. Do we need "dynamic RS registration=
" to support this?
>>>>=20
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>> On Mar 15, 2016, at 3:14 PM, George Fletcher  wrote=
:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> I think Justin provided a good break down of the different aspects a c=
lient wants to specify about the requested token. (my paraphrase)
>>>>>>   1. what RS's the token will be used at
>>>>>>   2. authorization privilege requests
>>>>>>   3. token-timing adjustments
>>>>>>=20
>>>>>> I'm not sure passing the full endpoint to the AS will help with my co=
ncerns... The AS could potentially do a webfinger on the resource URI and de=
termine if it's an RS that it supports... though that requires all RS's to s=
upport webfinger. What I really want to avoid is the AS having this list of U=
RIs to RS that is almost assuredly to get out of sync.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 3/15/16 1:56 PM, John Bradley wrote:
>>>>>>> I think it is a AS policy decision if it should error or take the re=
quested resource and issue a token audianced for that resource.
>>>>>> Actually, the error cases are interesting. What if the passed in reso=
urce/audience doesn't actually match a requested scope? Or some match and so=
me don't? Is it better to send back a token with less capability? or error t=
he entire request?
>>>>>>>=20
>>>>>>>=20
>>>>>>> I guess the question is how to transition from now to a future state=
.   If you cannot upgrade all the clients at once.
>>>>>>>=20
>>>>>>> A processing rule on the AS that allowed some clients to not send th=
e requested resource , but would error out for other upgraded clients  with a=
 "resource not allowed=E2=80=9D oauth error would work and not require the r=
eturn of the resources. =20
>>>>>>>=20
>>>>>>> If you return the resources and let the client error if it is trying=
 to send to the wrong endpoint that make upgrading easier, but gives less co=
ntrol to the AS.
>>>>>>>=20
>>>>>>> I could live with it ether way.
>>>>>>>=20
>>>>>>> The advantage of always sending it in the token request is that it a=
llows the AS to do the mapping from a resource URI to one or more abstract a=
udience for the token.
>>>>>> I thought Justin provided a good break down of                       =
      the different aspects a client wants to specify about the requested to=
ken. (my paraphrase)
>>>>>>   1. what RS's the token will be used at
>>>>>>   2. authorization privilege requests
>>>>>>   3. token-timing adjustments
>>>>>>=20
>>>>>> The question is how does a client internally reference a resource ser=
ver? If it's a fixed RS endpoint, then it sort of doesn't matter, the client=
 isn't going to send the token to the wrong endpoint anyway and it can easil=
y reference the audience by an abstract URI.
>>>>>>=20
>>>>>> If the client can dynamically find new RS's to interact with. How doe=
s that happen? Does the client get handed an endpoint to use? or does it do s=
ome sort of discovery to determine the endpoint? I suppose both are possible=
.
>>>>>>=20
>>>>>> Could we prescribe that the realm value of RFC 6750 error response be=
 effectively a resource-service-id (like issuer for the AS). The client woul=
d then need to do discovery on that value to find the valid endpoints of the=
 RS. This could be done once and the resource-service-id could be used as th=
e "abstract" RS identifier. This requires no more discovery than adding an A=
S to the client.
>>>>>>>=20
>>>>>>> That might help address George=E2=80=99s concern.
>>>>>> I'm not sure passing the full endpoint to the AS will help with my co=
ncerns... The AS could potentially do a webfinger on the resource URI and de=
termine if it's an RS that it supports... though that requires all RS's to s=
upport webfinger. What I really want to avoid is the AS having this map of U=
RIs to RS that is almost assuredly to get out of sync.
>>>>>>>=20
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell  wrote:
>>>>>>>>=20
>>>>>>>> I was thinking it'd be simpler to error, if the requested resource(=
s) weren't okay. That puts the burden of checking in the AS. And doesn't add=
 anything to the token or authorization response. I see the potential simila=
rity to scope but not sure it's worth it.   =20
>>>>>>>>=20
>>>>>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley =
 wrote:
>>>>>>>>> If the client specifies the resource it wants the token for, then t=
he meta-data would not be required unless the resources the token is good at=
 are different from the request. =20
>>>>>>>>> Lat is the same logic as scopes.
>>>>>>>>>=20
>>>>>>>>> For backwards compatibility if the client is happy with the defaul=
t resources based on scopes then I think it is a good idea to tell the clien=
t what the resources are in the response.
>>>>>>>>>=20
>>>>>>>>> I suspect that it is simpler with less optionality and always retu=
rn the resources, even if they are not required.
>>>>>>>>>=20
>>>>>>>>> John B.
>>>>>>>>>=20
>>>>>>>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell  wrote:
>>>>>>>>>>=20
>>>>>>>>>> If the client specifies the desired audience(s)/resource(s), is t=
hat metadata to the client needed? The AS can audience restrict the token as=
 needed or respond with an error if it can't or wont issue a token for the r=
esource the client asked for.=20
>>>>>>>>>>=20
>>>>>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  wrote:
>>>>>>>>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>>>>>>>=20
>>>>>>>>>>> The AS needs to infer an audience from the scopes snd/or have th=
e client specify the desired audience.
>>>>>>>>>>>=20
>>>>>>>>>>> If the AT has a audience or audiences then as long as the endpoi=
nt URI are provided as meta-data with the token, the                        =
                                   client can determine if it is sending the=
 token to the correct place.
>>>>>>>>>>>=20
>>>>>>>>>>> I think Phil would prefer the server rather than the client do t=
he check, but the client                                                    =
       always needs to take some responsibility to not leak tokens giving th=
em to the wrong RS or the code to the wrong token endpoint is leaking.
>>>>>>>>>>>=20
>>>>>>>>>>> I imagine that claims based access tokens are going to become mo=
re popular and the static relationship between one RS and one AS will not be=
 the majority of deployments over time.=20
>>>>>>>>>>>=20
>>>>>>>>>>> In any case where the client is configured up front to know the R=
S and the AS it seems like that would not require Phil=E2=80=99s Solution, b=
ut that is the only case supported by that discovery.
>>>>>>>>>>>  =20
>>>>>>>>>>> If the client itself is bad there is not much you can do to stop=
 it from passing on the AT in way way it wants.  That however is a different=
 problem and needs claimed URI or attestations to prevent client spoofing.
>>>>>>>>>>> William and I are working on that in the mobile best practices d=
raft.
>>>>>>>>>>>=20
>>>>>>>>>>> John B.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher  wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>> I worry about two directions I see in this thread...
>>>>>>>>>>>>=20
>>>>>>>>>>>> 1. Client's accessing resources dynamically so that discovery i=
s required to know the correct AS, etc. This is pretty much the classic use c=
ase for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>>>=20
>>>>>>>>>>>> 2. Creating a tight coupling between RS and AS such that RS end=
point changes must be continually communicated to the AS. If an RS supports m=
ultiple AS's then the RS has to deal with "guaranteed" delivery. The AS need=
s an endpoint to receive such communications. If not dynamic via APIs, then d=
eployment of the new RS is bound by the associated AS's getting and deployin=
g the new endpoints. Can both endpoints of the RS be supported within the AS=
 for some period of time, etc. This is an operation nightmare and almost ass=
uredly going to go wrong in production.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Maybe an OAuth2 "audience binding" spec is what's needed for th=
ose deployments that require this. I believe that is what John Bradley is su=
ggesting.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> George
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>>>>>>> +1, I've found the very same in OAuth deployments that I was i=
nvolved in; the hard part is to give names and descriptions to these concept=
s so that they cover all use cases and can be applied unambiguously=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Hans.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>>>>>>>>>>> I agree that this is valuable, and not just for PoP. In all h=
onesty,=20
>>>>>>>>>>>>>> it=E2=80=99s not even really required for PoP to function in m=
any cases =E2=80=94 it=E2=80=99s=20
>>>>>>>>>>>>>> just an optimization for one particular kind of key distribut=
ion=20
>>>>>>>>>>>>>> mechanism in that case.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> In the years of deployment experience                        =
                                   with OAuth 2, I think we=E2=80=99ve reall=
y=20
>>>>>>>>>>>>>> got three different kinds of things that currently get folded=
 into=20
>>>>>>>>>>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating o=
ut better:=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>>>>>>>>>>   - What actions do I want to take on these things? (read, wr=
ite, delete)=20
>>>>>>>>>>>>>>   - How long do I want these tokens to                       =
                                    work?=20
>>>>>>>>>>>>>> (offline_access/refresh_token, one time use, next hour, etc)=20=

>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I think the first one is close to the audience/resource param=
eters that=20
>>>>>>>>>>>>>> have been bandied about a few times,                         =
                                  including in the current token=20
>>>>>>>>>>>>>> exchange document. We should be consistent across drafts in t=
hat regard.=20
>>>>>>>>>>>>>> The second is more traditional scope-ish. The third has been p=
atched in=20
>>>>>>>>>>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain A=
PIs.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Just another vector to think about if we=E2=80=99re going to b=
e adding things=20
>>>>>>>>>>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D=
 or both to the token requests.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>   =E2=80=94 Justin=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Yes I will work on another proposal for allowing clients to s=
pecify=20
>>>>>>>>>>>>>>> what resource they want a token for and providing the meta-d=
ata to the=20
>>>>>>>>>>>>>>> client about the resources that a token is valid for.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> We have part of it in the POP key distribution spec and talk=
ed about=20
>>>>>>>>>>>>>>> separating it, as it is used more places than just for assig=
ning keys.=20
>>>>>>>>>>>>>>> I know some AS use different token formats for different RS s=
o are=20
>>>>>>>>>>>>>>> all-ready needing to pass the resource in the request to avo=
id making=20
>>>>>>>>>>>>>>> a mess of scopes.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> John B.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Inline=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Phil=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> We had two mandates.  One was to provide a spec for AS met=
adata.=20
>>>>>>>>>>>>>>>>> The other was to mitigate the client mixup attack.  The re=
quest was=20
>>>>>>>>>>>>>>>>> to do the latter without requiring the former for clients t=
hat don=E2=80=99t=20
>>>>>>>>>>>>>>>>> otherwise need discovery.=20
>>>>>>>>>>>>>>>> There is no mandate for any of this.                       =
                                    See=20
>>>>>>>>>>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oaut=
h-2016-01-22.txt=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Returning the issuer and client_id from the authorization e=
ndpoint=20
>>>>>>>>>>>>>>>>> and the client checking them can be done by the client wit=
hout=20
>>>>>>>>>>>>>>>>> discovery.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> How does this address the issue of whether the client is ta=
lking to=20
>>>>>>>>>>>>>>>> the wrong endpoint?=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Any client that has the resource and issuer hard coded pro=
bably=20
>>>>>>>>>>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>>>>>>>>>>> We agree=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> One of the things that a client will need discovery for is=
 to find=20
>>>>>>>>>>>>>>>>> the RS, so requiring the client to know the RS URI before g=
etting=20
>>>>>>>>>>>>>>>>> the AS config seems backwards to                          =
                                 me.=20
>>>>>>>>>>>>>>>> How can you make an assumption on order? You seem to be con=
flating=20
>>>>>>>>>>>>>>>> authentication with authorization by assuming the identity d=
rives=20
>>>>>>>>>>>>>>>> what the resource is.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> There are lots of applications that require user rights but=
 are not=20
>>>>>>>>>>>>>>>> identify centric. For example a document service.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Unless the client tells the AS where it intends to use the=
 token we=20
>>>>>>>>>>>>>>>>> will be leaving a security hole because the bearer tokens w=
ill have=20
>>>>>>>>>>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>>>>>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> True you are telling the AS (Webfinger service) what the R=
S is but=20
>>>>>>>>>>>>>>>>> that is not at a place that is useful in the token product=
ion process.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> This has nothing to do with token production.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> What we want to ensure is whether an honest client is corre=
ctly=20
>>>>>>>>>>>>>>>> configured and has not been mislead - eg by a phishing page=
.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99=
t know all the=20
>>>>>>>>>>>>>>>>> possible RS.   That is not something that a out of band ch=
eck can=20
>>>>>>>>>>>>>>>>> address.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> May be. Lets identify them.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> There are also cases where a token might be good at multip=
le RS=20
>>>>>>>>>>>>>>>>> endpoints intentionally.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>  In your solution the client would need to make a discover=
y request=20
>>>>>>>>>>>>>>>>> for each endpoint.=20
>>>>>>>>>>>>>>>> Sure. Otherwise how would it know if there is one AS or a p=
ool of AS=20
>>>>>>>>>>>>>>>> servers assigned to each instance?=20
>>>>>>>>>>>>>>>>> Those requests lack the context of                        =
                                   who the client and resource owner=20
>>>>>>>>>>>>>>>>> are.  I think that will be a problem in some use cases.=20=

>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Not sure I agree. This is about discovering a valid set of e=
ndpoints.=20
>>>>>>>>>>>>>>>> For mitm, we mainly want to check the hostname is correct. I=
f a=20
>>>>>>>>>>>>>>>> client chooses evil.com  the cert can be v=
alid and=20
>>>>>>>>>>>>>>>> TLS will pass. How does it otherwise know it is supposed to=
 talk to=20
>>>>>>>>>>>>>>>> res.example.com ?=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> If this is
>> ...
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-E1FD9CCC-54C2-4500-A6E6-6E0BC59147BC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Your solution seems to require resourc=
euri =3D audience. 

    Bound config avoids trying to require conver=
sion or urls into aud and vice versa. 

    Phil

    On Mar 16, 2=
016, at 07:46, John Bradley <ve7jtb@=
ve7jtb.com> wrote:

    If the client sends the uri of the resource it intends to send the t=
oken to in the token request the bad guy would get only a token audianced to=
 itself and not to good RS.  
    

    You can't solve the problem of bearer tokens with multiple au=
diences leaking.   That is a risk inherent in using that sort of t=
oken.   Compromise in one RS will impact all of them.  
    

    The only safe way with bearer to deal with a RS the AS dosen'=
t trust a RS is to only have one audianced in the token. (or by introspectio=
n)
    

    We have always known that and left it up to clients to make s=
ure they are secure by not sending tokens to bad RS.  
    

    Now people want a AS check to prevent clients from being tric=
ked if developers are given bad info statically or dynamically. 
    

    What you are doing is safe as long as your developers don't m=
ake any mistakes. 
    
If you want to be safe and not have to preconfigure the AS you need to use t=
he refresh to get single audianced tokens, or PoP.
    

    John B. 
    

    On Mar 16, 2016 11:27 AM, "George Fletcher" <<=
a href=3D"mailto:gffletch@aol.com">gffletch@aol.com> wrote:
    
 =20
   =20
 =20
  
    
    
    
    
    
    
    On 3/15/16 6:14 PM, John Bradley wrote:
    
    
    
    
    
     =20
      If the AS is audience restricting the tokens then it just needs to
      put the right audience in the token based on what the client is
      asking for.  
      
    That is safe as the RS wouldn=E2=80=99t be able to replay
        the token someplace else.
    
    
    
    So let's assuming a client sends a token audience restricted to
    GoodRS instead to EvilRS. When EvilRS replays the token at the
    GoodRS endpoint, how does GoodRS reject the token because when
    GoodRS sends the token to the AS for introspection (or does so
    itself) the token will be audience restricted to the GoodRS and it
    will process the token. The only way to prevent this is with
    client-authentication so that the presenter can be matched against
    who is allowed to present the token (aka PoP).
    
    
    
    In the pure bearer token model, I don't see how this can be
    prevented at the protocol level.
    
    
    
      

    
      
    
      
    That would need to be a AS policy if it wanted to do
        that for unknown RS.   
    
      

    
      
    
      
    Allowing more than one audience in a token is a
        convince but a well known security risk with bearer tokens.
    
    
    
    True, but this means clients have to manage many tokens or call the
    token endpoint to get a "downscoped, audience restricted" token
    every time they need one. This is a very different model than what
    most people think of when they think of OAuth2. Not bad, just
    different:)
    
    
    
      

    
      
    
      
    A AS would probably want to have only one audience
        in a AT for a untrusted RS, but may allow multiple if they are
        all trusted.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 6:28 PM, George Fletcher
              <gffl=
etch@aol.com>
              wrote:
    
            
    
            
    
             =20
              
     
    
                
    On 3/15/16 3:26 PM, John
                  Bradley wrote:
    
                
    
                
    
                 =20
                  I think Phil and others are concerned that a developer
                  might get bad info to put in the client , some out of
                  band discovery goes wrong or the user is somehow
                  tricked into specifying a bad resource to the client.
                  

    
                  
    
                  
    So getting a bad resource is a touch
                    hypothetical. 
    
                  
    
                
    
                If we are really trying to solve this problem
                holistically, then we probably need to first describe
                the use cases we want to solve. I'm starting to wonder
                if we are all providing solutions to slightly different
                use cases.
    
                
    
                  

    
                  
    
                  
    For Connect we could suppose that
                    someone publishes a malicious discovery document
                    listing themselves as the RS but all the other
                    endpoints are at the good AS so the client
                    registers, authorizes the user and gives the AT to
                    the bad guy.  The confused client mitigation by
                    returning client_id_and issuer from the
                    authorization endpoint will stop the attack before
                    the token can be given to the token endpoint or RS.
                
    
                Agreed and I'm fine with this solution.
    
                
    
                  

    
                  
    
                  
    So protecting the AT at this point is
                    more for a unknown attack that would confuse
                    whatever protocol/API that is using OAuth about what
                    RS to use.
    
                
    
                Yes. This is where we need to describe some use cases
                (preferably real vs contrived) before we propose
                solutions. In most cases the RS endpoints are hard coded
                into the client or maybe pulled from a different central
                config endpoint (which is fixed).
    
                
    
                That's why the only case I could think of is a client
                that works with multiple RS endpoints from different
                providers that server the same content (e.g.
                PortableContacts API). In this use case, the user of the
                client would need to enter the location of the RS they
                wanted to use and then the flow would start from there.
                In reality, most services like this would have a fixed
                set of RS's they work with and again it wouldn't be
                dynamic.
    
                
    
                  

    
                  
    
                  
    In reality this is what PoP is supposed
                    to be for.
    
                  

    
                  
    
                  
    I guess the question is what short of
                    PoP can we do to prevent the client leaking tokens
                    to bad RS that confuse it via the application
                    protocol.
    
                  

    
                  
    
                  
    If we want to del with this in OAuth
                    then we need to tell the AS where the token is going
                    to be used or tel the client where the token can be
                    used. 
    
                  

    
                  
    
                  
    I think letting the client tell the AS
                    where it wants the token used having the AS
                    construct a audience out of that is probably the
                    best thing.  to get around having a pre-established=

                    relationship between the AS and RS.
    
                
    
                Even if the client tells the AS where it wants to use
                the token (via some endpoint URL), the AS still needs to
                have a relationship with the RS (at a minimum as an
                endpointURL-to-RS map) otherwise how can it determine if
                it is allowed to issue an access token to the user for
                that RS. This map is what I want to avoid "building"
                into the AS. Do we need "dynamic RS registration" to
                support this?
    
                
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 3:14 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        

    =

                            
    
                            I think Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            I'm not sure passing the full endpoint to
                            the AS will help with my concerns... The AS
                            could potentially do a webfinger on the
                            resource URI and determine if it's an RS
                            that it supports... though that requires all
                            RS's to support webfinger. What I really
                            want to avoid is the AS having this list of
                            URIs to RS that is almost assuredly to get
                            out of sync.
    
                            
    
                            
    
                          
    
                          
    On
                            3/15/16 1:56 PM, John Bradley wrote:
    
                          
    
                          
    I t=
hink it is a AS policy decision
                            if it should error or take the requested
                            resource and issue a token audianced for
                            that resource.
    
                          Actuall=
y,
                            the error cases are interesting. What if the
                            passed in resource/audience doesn't actually
                            match a requested scope? Or some match and
                            some don't? Is it better to send back a
                            token with less capability? or error the
                            entire request?
                          
    
                            

    
                            
    
                            
    I guess the question is how to
                              transition from now to a future state.  
                              If you cannot upgrade all the clients at
                              once.
    
                            

    
                            
    
                            
    A processing rule on the AS
                              that allowed some clients to not send the
                              requested resource , but would error out
                              for other upgraded clients  with a
                              "resource not allowed=E2=80=9D oauth error wou=
ld
                              work and not require the return of the
                              resources.  
    
                            

    
                            
    
                            
    If you return the resources
                              and let the client error if it is trying
                              to send to the wrong endpoint that make
                              upgrading easier, but gives less control
                              to the AS.
    
                            

    
                            
    
                            
    
                              
    
                                
    I could
                                    live with it ether way.
    
                                

    
                                
    
                                The advantage of always sending it in
                                the token request is that it allows the
                                AS to do the mapping from a resource URI
                                to one or more abstract audience for the
                                token.
    
                            
    
                          
    
                          I
                            thought Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            The question is how does a client internally
                            reference a resource server? If it's a fixed
                            RS endpoint, then it sort of doesn't matter,
                            the client isn't going to send the token to
                            the wrong endpoint anyway and it can easily
                            reference the audience by an abstract URI.
    
                            
    
                            If the client can dynamically find new RS's
                            to interact with. How does that happen? Does
                            the client get handed an endpoint to use? or
                            does it do some sort of discovery to
                            determine the endpoint? I suppose both are
                            possible.
    
                            
    
                            Could we prescribe that the realm value of
                            RFC 6750 error response be effectively a
                            resource-service-id (like issuer for the
                            AS). The client would then need to do
                            discovery on that value to find the valid
                            endpoints of the RS. This could be done once
                            and the resource-service-id could be used as
                            the "abstract" RS identifier. This requires
                            no more discovery than adding an AS to the
                            client.
    
                              
                          
    
                            
    
                              

    
                              
    
                              
    That might help address
                                George=E2=80=99s concern.
    
                            
    
                          
    
                          I'm
                            not sure passing the full endpoint to the AS
                            will help with my concerns... The AS could
                            potentially do a webfinger on the resource
                            URI and determine if it's an RS that it
                            supports... though that requires all RS's to
                            support webfinger. What I really want to
                            avoid is the AS having this map of URIs to
                            RS that is almost assuredly to get out of
                            sync.
                          
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                              
    
                              

    
                                
    
                                  
    On Mar 15, 2016, at 2:44
                                    PM, Brian Campbell <bcampbell@pingidentity.com>

                                    wrote:
    
                                  
    
                                  
    
                                    
    I was
                                      thinking it'd be simpler to error,
                                      if the requested resource(s)
                                      weren't okay. That puts the burden
                                      of checking in the AS. And doesn't
                                      add anything to the token or
                                      authorization response. I see the
                                      potential similarity to scope but
                                      not sure it's worth it.    
    
                                    

    
                                      
    On Tue,
                                        Mar 15, 2016 at 11:37 AM, John
                                        Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                        
    
                                          
    If the client
                                            specifies the resource it
                                            wants the token for, then
                                            the meta-data would not be
                                            required unless the
                                            resources the token is good
                                            at are different from the
                                            request.  
                                            
    Lat is the
                                              same logic as scopes.
    
                                            

    
                                            
    
                                            
    For backwards
                                              compatibility if the
                                              client is happy with the
                                              default resources based on
                                              scopes then I think it is
                                              a good idea to tell the
                                              client what the resources
                                              are in the response.
    
                                            

    
                                            
    
                                            
    I suspect that
                                              it is simpler with less
                                              optionality and always
                                              return the resources, even
                                              if they are not required.
                                            

    
                                            
    
                                            
    John B.
    
                                            
    
                                              
    
                                                

    
                                                
    
                                                
    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:46 PM, Brian
                                                        Campbell <bcampbell@pingidentity.com<=
/a>>

                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
    If
                                                          the client
                                                          specifies the
                                                          desired
                                                          audience(s)/resour=
ce(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for. 
    
                                                          
    
                                                          
    
                                                          

    
                                                          
    On

                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley =
;<ve7jtb@v=
e7jtb.com> wrote:
    
                                                          
    
                                                          
    Yes,

                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The

                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          audience.
    
                                                          

    
                                                          
    
                                                          
    If

                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time. 
                                                          

    
                                                          
    
                                                          
    In

                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil=E2=80=
=99s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
      <=
/div>
                                                          
    If

                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.  That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    William

                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John

                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    On

                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>

                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On

                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously 
    
                                                          
    
                                                          Hans. <=
/span>
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: =

    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty,&nbs=
p;
    
                                                          it=E2=80=99s not e=
ven
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases =E2=80=94=

                                                          it=E2=80=99s=
 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution=
 
    
                                                          mechanism in
                                                          that case.&n=
bsp;
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we=E2=80=99=
ve
                                                          really =

    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into&=
nbsp;
    
                                                          =E2=80=9Cscope=E2=80=
=9D that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: =
;
    
                                                          
    
                                                          
    
                                                            =
-
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile)&nbs=
p;
    
                                                            =
-
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete) 
    
                                                            =
-
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? <=
/span>
    
                                                          (offline_access/re=
fresh_token,

                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token <=
/span>
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. =
;
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in&n=
bsp;
    
                                                          with things
                                                          like
                                                          =E2=80=9Coffline_a=
ccess=E2=80=9D
                                                          in certain
                                                          APIs. <=
/span>
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we=E2=80=99re goin=
g to
                                                          be adding
                                                          things =

    
                                                          like
                                                          =E2=80=9Caudience=E2=
=80=9D or
                                                          =E2=80=9Cresource=E2=
=80=9D or
                                                          both to the
                                                          token
                                                          requests.&nb=
sp;
    
                                                          
    
                                                            =
=E2=80=94
                                                          Justin =

    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: =

    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify =
;
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about=
 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. <=
/span>
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are&nb=
sp;
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making=
 
    
                                                          a mess of
                                                          scopes. =
;
    
                                                          
    
                                                          John B. =
;
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>

                                                          wrote: =

    
                                                          
    
                                                          Inline =

    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com 
    =

                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: =

    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.  On=
e
                                                          was to provide
                                                          a spec for AS
                                                          metadata.&nb=
sp;
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack. =
;
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don=E2=80=99t 
    
                                                          otherwise need
                                                          discovery.&n=
bsp;
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth=
/charters?item=3Dcharter-oauth-2016-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint&nbs=
p;
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without =
;
    
                                                          discovery.&n=
bsp;
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to&n=
bsp;
    
                                                          the wrong
                                                          endpoint?&nb=
sp;
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably 
    
                                                          doesn=E2=80=99t ne=
ed
                                                          discovery.&n=
bsp;
    
                                                          
    
                                                          We agree&nbs=
p;
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find&n=
bsp;
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating&n=
bsp;
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives =

    
                                                          what the
                                                          resource is.=
 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not&=
nbsp;
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service.&nbs=
p;
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have&nb=
sp;
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. =
;
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process.&nbs=
p;
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production.&=
nbsp;
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly=
 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. <=
/span>
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn=E2=80=
=99t
                                                          know all the=
 
    
                                                          possible RS. =
 
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can&nb=
sp;
    
                                                          address.&nbs=
p;
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them. 
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS 
    
                                                          endpoints
                                                          intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request =
;
    
                                                          for each
                                                          endpoint.&nb=
sp;
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS&n=
bsp;
    
                                                          servers
                                                          assigned to
                                                          each instance? 
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner <=
/span>
    
                                                          are.  I think=

                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. =

    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints.&n=
bsp;
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a 
    
                                                          client chooses evil.com <http://evil.com/> =
;the cert can be valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to&n=
bsp;
    
                                                          res.example.com <http://res.example.c=
om/>? 
    
                                                          

    
                                                          If this is
             
    =

    ...
    

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

--Apple-Mail-E1FD9CCC-54C2-4500-A6E6-6E0BC59147BC--


From nobody Wed Mar 16 08:30:48 2016
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 325F312D6F5 for ; Wed, 16 Mar 2016 08:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 gXBf6JXXrBQ9 for ; Wed, 16 Mar 2016 08:30:37 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 766B112D53C for ; Wed, 16 Mar 2016 08:30:15 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2GFUAhO001128 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2016 15:30:11 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2GFUAdF011484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 15:30:10 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2GFU7BB029146; Wed, 16 Mar 2016 15:30:08 GMT
Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Mar 2016 08:30:05 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-31459CDC-7934-4141-B7C9-D3D21E1D8909
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Wed, 16 Mar 2016 08:30:03 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <4128BA28-F6B1-43E7-A6DB-8A8CC3425095@oracle.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>  <56E96D48.90704@aol.com> 
To: John Bradley 
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 15:30:46 -0000

--Apple-Mail-31459CDC-7934-4141-B7C9-D3D21E1D8909
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

John,

Mis configured token endpoint and resource endpoint is the same client misco=
nfiguration issue where a client is mis-informed by mistake or mis-deed.=20

Why do you propose to solve token endpoint in config discovery but feel reso=
urce endpoint must be reverified each time in the core protocol?=20

Phil

> On Mar 16, 2016, at 07:46, John Bradley  wrote:
>=20
> If the client sends the uri of the resource it intends to send the token t=
o in the token request the bad guy would get only a token audianced to itsel=
f and not to good RS.=20
>=20
> You can't solve the problem of bearer tokens with multiple audiences leaki=
ng.   That is a risk inherent in using that sort of token.   Compromise in o=
ne RS will impact all of them.=20
>=20
> The only safe way with bearer to deal with a RS the AS dosen't trust a RS i=
s to only have one audianced in the token. (or by introspection)
>=20
> We have always known that and left it up to clients to make sure they are s=
ecure by not sending tokens to bad RS.=20
>=20
> Now people want a AS check to prevent clients from being tricked if develo=
pers are given bad info statically or dynamically.
>=20
> What you are doing is safe as long as your developers don't make any mista=
kes.=20
> If you want to be safe and not have to preconfigure the AS you need to use=
 the refresh to get single audianced tokens, or PoP.
>=20
> John B.
>=20
>> On Mar 16, 2016 11:27 AM, "George Fletcher"  wrote:
>>=20
>>=20
>>> On 3/15/16 6:14 PM, John Bradley wrote:
>>> If the AS is audience restricting the tokens then it just needs to put t=
he right audience in the token based on what the client is asking for. =20
>>> That is safe as the RS wouldn=E2=80=99t be able to replay the token some=
place else.
>> So let's assuming a client sends a token audience restricted to GoodRS in=
stead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, how d=
oes GoodRS reject the token because when GoodRS sends the token to the AS fo=
r introspection (or does so itself) the token will be audience restricted to=
 the GoodRS and it will process the token. The only way to prevent this is w=
ith client-authentication so that the presenter can be matched against who i=
s allowed to present the token (aka PoP).
>>=20
>> In the pure bearer token model, I don't see how this can be prevented at t=
he protocol level.
>>>=20
>>> That would need to be a AS policy if it wanted to do that for unknown RS=
.  =20
>>>=20
>>> Allowing more than one audience in a token is a convince but a well know=
n security risk with bearer tokens.
>> True, but this means clients have to manage many tokens or call the token=
 endpoint to get a "downscoped, audience restricted" token every time they n=
eed one. This is a very different model than what most people think of when t=
hey think of OAuth2. Not bad, just different:)
>>>=20
>>> A AS would probably want to have only one audience         in a AT for a=
 untrusted RS, but may allow multiple if they are all trusted.
>>>=20
>>> John B.
>>>=20
>>>=20
>>>> On Mar 15, 2016, at 6:28 PM, George Fletcher  wrote:
>>>>=20
>>>>=20
>>>>> On 3/15/16 3:26 PM, John Bradley wrote:
>>>>> I think Phil and others are concerned that a developer might get bad i=
nfo to put in the client , some out of band discovery goes wrong or the user=
 is somehow tricked into specifying a bad resource to the client.
>>>>>=20
>>>>> So getting a bad resource is a touch hypothetical.
>>>> If we are really trying to solve this problem holistically, then we pro=
bably need to first describe the use cases we want to solve. I'm starting to=
 wonder if we are all providing solutions to slightly different use cases.
>>>>>=20
>>>>> For Connect we could suppose that someone publishes a malicious discov=
ery document listing themselves as the RS but all the other endpoints are at=
 the good AS so the client registers, authorizes the user and gives the AT t=
o the bad guy.  The confused client mitigation by returning client_id_and is=
suer from the authorization endpoint will stop the attack before the token c=
an be given to the token endpoint or RS.
>>>> Agreed and I'm fine with this solution.
>>>>>=20
>>>>> So protecting the AT at this point is more for a unknown attack that w=
ould confuse whatever protocol/API that is using OAuth about what RS to use.=

>>>> Yes. This is where we need to describe some use cases (preferably real v=
s contrived) before we propose solutions. In most cases the RS endpoints are=
 hard coded                 into the client or maybe pulled from a different=
 central config endpoint (which is fixed).
>>>>=20
>>>> That's why the only case I could think of is a client that works with m=
ultiple RS endpoints from different providers that server the same content (=
e.g. PortableContacts API). In this use case, the user of the client would n=
eed to enter the location of the RS they wanted to use and then the flow wou=
ld start from there. In reality, most services like this would have a fixed s=
et of RS's they work with and again it wouldn't be dynamic.
>>>>>=20
>>>>> In reality this is what PoP is supposed to be for.
>>>>>=20
>>>>> I guess the question is what short of PoP can we do to prevent the cli=
ent leaking tokens to bad RS that confuse it via the application protocol.
>>>>>=20
>>>>> If we want to del with this in OAuth then we need to tell the AS where=
 the token is going to be used or tel the client where the token can be used=
.=20
>>>>>=20
>>>>> I think letting the client tell the AS where it wants the token used h=
aving the AS construct a audience out of that is probably the best thing.  t=
o get around having a pre-established relationship between the AS and RS.
>>>> Even if the client tells the AS where it wants to use the token (via so=
me endpoint URL), the AS still needs to have a relationship with the RS (at a=
 minimum as an endpointURL-to-RS map) otherwise how can it determine if it i=
s allowed to issue an access token to the user for that RS. This map is what=
 I want to avoid "building" into the AS. Do we need "dynamic RS registration=
" to support this?
>>>>=20
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>> On Mar 15, 2016, at 3:14 PM, George Fletcher  wrote=
:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> I think Justin provided a good break down of the different aspects a c=
lient wants to specify about the requested token. (my paraphrase)
>>>>>>   1. what RS's the token will be used at
>>>>>>   2. authorization privilege requests
>>>>>>   3. token-timing adjustments
>>>>>>=20
>>>>>> I'm not sure passing the full endpoint to the AS will help with my co=
ncerns... The AS could potentially do a webfinger on the resource URI and de=
termine if it's an RS that it supports... though that requires all RS's to s=
upport webfinger. What I really want to avoid is the AS having this list of U=
RIs to RS that is almost assuredly to get out of sync.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 3/15/16 1:56 PM, John Bradley wrote:
>>>>>>> I think it is a AS policy decision if it should error or take the re=
quested resource and issue a token audianced for that resource.
>>>>>> Actually, the error cases are interesting. What if the passed in reso=
urce/audience doesn't actually match a requested scope? Or some match and so=
me don't? Is it better to send back a token with less capability? or error t=
he entire request?
>>>>>>>=20
>>>>>>>=20
>>>>>>> I guess the question is how to transition from now to a future state=
.   If you cannot upgrade all the clients at once.
>>>>>>>=20
>>>>>>> A processing rule on the AS that allowed some clients to not send th=
e requested resource , but would error out for other upgraded clients  with a=
 "resource not allowed=E2=80=9D oauth error would work and not require the r=
eturn of the resources. =20
>>>>>>>=20
>>>>>>> If you return the resources and let the client error if it is trying=
 to send to the wrong endpoint that make upgrading easier, but gives less co=
ntrol to the AS.
>>>>>>>=20
>>>>>>> I could live with it ether way.
>>>>>>>=20
>>>>>>> The advantage of always sending it in the token request is that it a=
llows the AS to do the mapping from a resource URI to one or more abstract a=
udience for the token.
>>>>>> I thought Justin provided a good break down of                       =
      the different aspects a client wants to specify about the requested to=
ken. (my paraphrase)
>>>>>>   1. what RS's the token will be used at
>>>>>>   2. authorization privilege requests
>>>>>>   3. token-timing adjustments
>>>>>>=20
>>>>>> The question is how does a client internally reference a resource ser=
ver? If it's a fixed RS endpoint, then it sort of doesn't matter, the client=
 isn't going to send the token to the wrong endpoint anyway and it can easil=
y reference the audience by an abstract URI.
>>>>>>=20
>>>>>> If the client can dynamically find new RS's to interact with. How doe=
s that happen? Does the client get handed an endpoint to use? or does it do s=
ome sort of discovery to determine the endpoint? I suppose both are possible=
.
>>>>>>=20
>>>>>> Could we prescribe that the realm value of RFC 6750 error response be=
 effectively a resource-service-id (like issuer for the AS). The client woul=
d then need to do discovery on that value to find the valid endpoints of the=
 RS. This could be done once and the resource-service-id could be used as th=
e "abstract" RS identifier. This requires no more discovery than adding an A=
S to the client.
>>>>>>>=20
>>>>>>> That might help address George=E2=80=99s concern.
>>>>>> I'm not sure passing the full endpoint to the AS will help with my co=
ncerns... The AS could potentially do a webfinger on the resource URI and de=
termine if it's an RS that it supports... though that requires all RS's to s=
upport webfinger. What I really want to avoid is the AS having this map of U=
RIs to RS that is almost assuredly to get out of sync.
>>>>>>>=20
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell  wrote:
>>>>>>>>=20
>>>>>>>> I was thinking it'd be simpler to error, if the requested resource(=
s) weren't okay. That puts the burden of checking in the AS. And doesn't add=
 anything to the token or authorization response. I see the potential simila=
rity to scope but not sure it's worth it.   =20
>>>>>>>>=20
>>>>>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley =
 wrote:
>>>>>>>>> If the client specifies the resource it wants the token for, then t=
he meta-data would not be required unless the resources the token is good at=
 are different from the request. =20
>>>>>>>>> Lat is the same logic as scopes.
>>>>>>>>>=20
>>>>>>>>> For backwards compatibility if the client is happy with the defaul=
t resources based on scopes then I think it is a good idea to tell the clien=
t what the resources are in the response.
>>>>>>>>>=20
>>>>>>>>> I suspect that it is simpler with less optionality and always retu=
rn the resources, even if they are not required.
>>>>>>>>>=20
>>>>>>>>> John B.
>>>>>>>>>=20
>>>>>>>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell  wrote:
>>>>>>>>>>=20
>>>>>>>>>> If the client specifies the desired audience(s)/resource(s), is t=
hat metadata to the client needed? The AS can audience restrict the token as=
 needed or respond with an error if it can't or wont issue a token for the r=
esource the client asked for.=20
>>>>>>>>>>=20
>>>>>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  wrote:
>>>>>>>>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>>>>>>>=20
>>>>>>>>>>> The AS needs to infer an audience from the scopes snd/or have th=
e client specify the desired audience.
>>>>>>>>>>>=20
>>>>>>>>>>> If the AT has a audience or audiences then as long as the endpoi=
nt URI are provided as meta-data with the token, the                        =
                                   client can determine if it is sending the=
 token to the correct place.
>>>>>>>>>>>=20
>>>>>>>>>>> I think Phil would prefer the server rather than the client do t=
he check, but the client                                                    =
       always needs to take some responsibility to not leak tokens giving th=
em to the wrong RS or the code to the wrong token endpoint is leaking.
>>>>>>>>>>>=20
>>>>>>>>>>> I imagine that claims based access tokens are going to become mo=
re popular and the static relationship between one RS and one AS will not be=
 the majority of deployments over time.=20
>>>>>>>>>>>=20
>>>>>>>>>>> In any case where the client is configured up front to know the R=
S and the AS it seems like that would not require Phil=E2=80=99s Solution, b=
ut that is the only case supported by that discovery.
>>>>>>>>>>>  =20
>>>>>>>>>>> If the client itself is bad there is not much you can do to stop=
 it from passing on the AT in way way it wants.  That however is a different=
 problem and needs claimed URI or attestations to prevent client spoofing.
>>>>>>>>>>> William and I are working on that in the mobile best practices d=
raft.
>>>>>>>>>>>=20
>>>>>>>>>>> John B.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher  wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>> I worry about two directions I see in this thread...
>>>>>>>>>>>>=20
>>>>>>>>>>>> 1. Client's accessing resources dynamically so that discovery i=
s required to know the correct AS, etc. This is pretty much the classic use c=
ase for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>>>=20
>>>>>>>>>>>> 2. Creating a tight coupling between RS and AS such that RS end=
point changes must be continually communicated to the AS. If an RS supports m=
ultiple AS's then the RS has to deal with "guaranteed" delivery. The AS need=
s an endpoint to receive such communications. If not dynamic via APIs, then d=
eployment of the new RS is bound by the associated AS's getting and deployin=
g the new endpoints. Can both endpoints of the RS be supported within the AS=
 for some period of time, etc. This is an operation nightmare and almost ass=
uredly going to go wrong in production.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Maybe an OAuth2 "audience binding" spec is what's needed for th=
ose deployments that require this. I believe that is what John Bradley is su=
ggesting.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> George
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>>>>>>> +1, I've found the very same in OAuth deployments that I was i=
nvolved in; the hard part is to give names and descriptions to these concept=
s so that they cover all use cases and can be applied unambiguously=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Hans.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>>>>>>>>>>> I agree that this is valuable, and not just for PoP. In all h=
onesty,=20
>>>>>>>>>>>>>> it=E2=80=99s not even really required for PoP to function in m=
any cases =E2=80=94 it=E2=80=99s=20
>>>>>>>>>>>>>> just an optimization for one particular kind of key distribut=
ion=20
>>>>>>>>>>>>>> mechanism in that case.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> In the years of deployment experience                        =
                                   with OAuth 2, I think we=E2=80=99ve reall=
y=20
>>>>>>>>>>>>>> got three different kinds of things that currently get folded=
 into=20
>>>>>>>>>>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separating o=
ut better:=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>>>>>>>>>>   - What actions do I want to take on these things? (read, wr=
ite, delete)=20
>>>>>>>>>>>>>>   - How long do I want these tokens to                       =
                                    work?=20
>>>>>>>>>>>>>> (offline_access/refresh_token, one time use, next hour, etc)=20=

>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I think the first one is close to the audience/resource param=
eters that=20
>>>>>>>>>>>>>> have been bandied about a few times,                         =
                                  including in the current token=20
>>>>>>>>>>>>>> exchange document. We should be consistent across drafts in t=
hat regard.=20
>>>>>>>>>>>>>> The second is more traditional scope-ish. The third has been p=
atched in=20
>>>>>>>>>>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certain A=
PIs.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Just another vector to think about if we=E2=80=99re going to b=
e adding things=20
>>>>>>>>>>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D=
 or both to the token requests.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>   =E2=80=94 Justin=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Yes I will work on another proposal for allowing clients to s=
pecify=20
>>>>>>>>>>>>>>> what resource they want a token for and providing the meta-d=
ata to the=20
>>>>>>>>>>>>>>> client about the resources that a token is valid for.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> We have part of it in the POP key distribution spec and talk=
ed about=20
>>>>>>>>>>>>>>> separating it, as it is used more places than just for assig=
ning keys.=20
>>>>>>>>>>>>>>> I know some AS use different token formats for different RS s=
o are=20
>>>>>>>>>>>>>>> all-ready needing to pass the resource in the request to avo=
id making=20
>>>>>>>>>>>>>>> a mess of scopes.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> John B.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Inline=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Phil=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> We had two mandates.  One was to provide a spec for AS met=
adata.=20
>>>>>>>>>>>>>>>>> The other was to mitigate the client mixup attack.  The re=
quest was=20
>>>>>>>>>>>>>>>>> to do the latter without requiring the former for clients t=
hat don=E2=80=99t=20
>>>>>>>>>>>>>>>>> otherwise need discovery.=20
>>>>>>>>>>>>>>>> There is no mandate for any of this.                       =
                                    See=20
>>>>>>>>>>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oaut=
h-2016-01-22.txt=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Returning the issuer and client_id from the authorization e=
ndpoint=20
>>>>>>>>>>>>>>>>> and the client checking them can be done by the client wit=
hout=20
>>>>>>>>>>>>>>>>> discovery.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> How does this address the issue of whether the client is ta=
lking to=20
>>>>>>>>>>>>>>>> the wrong endpoint?=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Any client that has the resource and issuer hard coded pro=
bably=20
>>>>>>>>>>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>>>>>>>>>>> We agree=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> One of the things that a client will need discovery for is=
 to find=20
>>>>>>>>>>>>>>>>> the RS, so requiring the client to know the RS URI before g=
etting=20
>>>>>>>>>>>>>>>>> the AS config seems backwards to                          =
                                 me.=20
>>>>>>>>>>>>>>>> How can you make an assumption on order? You seem to be con=
flating=20
>>>>>>>>>>>>>>>> authentication with authorization by assuming the identity d=
rives=20
>>>>>>>>>>>>>>>> what the resource is.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> There are lots of applications that require user rights but=
 are not=20
>>>>>>>>>>>>>>>> identify centric. For example a document service.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Unless the client tells the AS where it intends to use the=
 token we=20
>>>>>>>>>>>>>>>>> will be leaving a security hole because the bearer tokens w=
ill have=20
>>>>>>>>>>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>>>>>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> True you are telling the AS (Webfinger service) what the R=
S is but=20
>>>>>>>>>>>>>>>>> that is not at a place that is useful in the token product=
ion process.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> This has nothing to do with token production.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> What we want to ensure is whether an honest client is corre=
ctly=20
>>>>>>>>>>>>>>>> configured and has not been mislead - eg by a phishing page=
.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99=
t know all the=20
>>>>>>>>>>>>>>>>> possible RS.   That is not something that a out of band ch=
eck can=20
>>>>>>>>>>>>>>>>> address.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> May be. Lets identify them.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> There are also cases where a token might be good at multip=
le RS=20
>>>>>>>>>>>>>>>>> endpoints intentionally.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>  In your solution the client would need to make a discover=
y request=20
>>>>>>>>>>>>>>>>> for each endpoint.=20
>>>>>>>>>>>>>>>> Sure. Otherwise how would it know if there is one AS or a p=
ool of AS=20
>>>>>>>>>>>>>>>> servers assigned to each instance?=20
>>>>>>>>>>>>>>>>> Those requests lack the context of                        =
                                   who the client and resource owner=20
>>>>>>>>>>>>>>>>> are.  I think that will be a problem in some use cases.=20=

>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Not sure I agree. This is about discovering a valid set of e=
ndpoints.=20
>>>>>>>>>>>>>>>> For mitm, we mainly want to check the hostname is correct. I=
f a=20
>>>>>>>>>>>>>>>> client chooses evil.com  the cert can be v=
alid and=20
>>>>>>>>>>>>>>>> TLS will pass. How does it otherwise know it is supposed to=
 talk to=20
>>>>>>>>>>>>>>>> res.example.com ?=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> If this is
>> ...
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-31459CDC-7934-4141-B7C9-D3D21E1D8909
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    John,

    Mis configured token endpoint a=
nd resource endpoint is the same client misconfiguration issue where a clien=
t is mis-informed by mistake or mis-deed. 

    Why do you propose to solve=
 token endpoint in config discovery but feel resource endpoint must be rever=
ified each time in the core protocol? 

    Phil

    On Mar 16, 2016, at 07:46, John Bradley <<=
a href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com> wrote:

    =

    If the client sends the u=
ri of the resource it intends to send the token to in the token request the b=
ad guy would get only a token audianced to itself and not to good RS.  <=
/p>

    You can't solve the problem of bearer tokens with multiple au=
diences leaking.   That is a risk inherent in using that sort of t=
oken.   Compromise in one RS will impact all of them.  
    

    The only safe way with bearer to deal with a RS the AS dosen'=
t trust a RS is to only have one audianced in the token. (or by introspectio=
n)
    

    We have always known that and left it up to clients to make s=
ure they are secure by not sending tokens to bad RS.  
    

    Now people want a AS check to prevent clients from being tric=
ked if developers are given bad info statically or dynamically. 
    

    What you are doing is safe as long as your developers don't m=
ake any mistakes. 
    
If you want to be safe and not have to preconfigure the AS you need to use t=
he refresh to get single audianced tokens, or PoP.
    

    John B. 
    

    On Mar 16, 2016 11:27 AM, "George Fletcher" <<=
a href=3D"mailto:gffletch@aol.com">gffletch@aol.com> wrote:
    
 =20
   =20
 =20
  
    
    
    
    
    
    
    On 3/15/16 6:14 PM, John Bradley wrote:
    
    
    
    
    
     =20
      If the AS is audience restricting the tokens then it just needs to
      put the right audience in the token based on what the client is
      asking for.  
      
    That is safe as the RS wouldn=E2=80=99t be able to replay
        the token someplace else.
    
    
    
    So let's assuming a client sends a token audience restricted to
    GoodRS instead to EvilRS. When EvilRS replays the token at the
    GoodRS endpoint, how does GoodRS reject the token because when
    GoodRS sends the token to the AS for introspection (or does so
    itself) the token will be audience restricted to the GoodRS and it
    will process the token. The only way to prevent this is with
    client-authentication so that the presenter can be matched against
    who is allowed to present the token (aka PoP).
    
    
    
    In the pure bearer token model, I don't see how this can be
    prevented at the protocol level.
    
    
    
      

    
      
    
      
    That would need to be a AS policy if it wanted to do
        that for unknown RS.   
    
      

    
      
    
      
    Allowing more than one audience in a token is a
        convince but a well known security risk with bearer tokens.
    
    
    
    True, but this means clients have to manage many tokens or call the
    token endpoint to get a "downscoped, audience restricted" token
    every time they need one. This is a very different model than what
    most people think of when they think of OAuth2. Not bad, just
    different:)
    
    
    
      

    
      
    
      
    A AS would probably want to have only one audience
        in a AT for a untrusted RS, but may allow multiple if they are
        all trusted.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 6:28 PM, George Fletcher
              <gffl=
etch@aol.com>
              wrote:
    
            
    
            
    
             =20
              
     
    
                
    On 3/15/16 3:26 PM, John
                  Bradley wrote:
    
                
    
                
    
                 =20
                  I think Phil and others are concerned that a developer
                  might get bad info to put in the client , some out of
                  band discovery goes wrong or the user is somehow
                  tricked into specifying a bad resource to the client.
                  

    
                  
    
                  
    So getting a bad resource is a touch
                    hypothetical. 
    
                  
    
                
    
                If we are really trying to solve this problem
                holistically, then we probably need to first describe
                the use cases we want to solve. I'm starting to wonder
                if we are all providing solutions to slightly different
                use cases.
    
                
    
                  

    
                  
    
                  
    For Connect we could suppose that
                    someone publishes a malicious discovery document
                    listing themselves as the RS but all the other
                    endpoints are at the good AS so the client
                    registers, authorizes the user and gives the AT to
                    the bad guy.  The confused client mitigation by
                    returning client_id_and issuer from the
                    authorization endpoint will stop the attack before
                    the token can be given to the token endpoint or RS.
                
    
                Agreed and I'm fine with this solution.
    
                
    
                  

    
                  
    
                  
    So protecting the AT at this point is
                    more for a unknown attack that would confuse
                    whatever protocol/API that is using OAuth about what
                    RS to use.
    
                
    
                Yes. This is where we need to describe some use cases
                (preferably real vs contrived) before we propose
                solutions. In most cases the RS endpoints are hard coded
                into the client or maybe pulled from a different central
                config endpoint (which is fixed).
    
                
    
                That's why the only case I could think of is a client
                that works with multiple RS endpoints from different
                providers that server the same content (e.g.
                PortableContacts API). In this use case, the user of the
                client would need to enter the location of the RS they
                wanted to use and then the flow would start from there.
                In reality, most services like this would have a fixed
                set of RS's they work with and again it wouldn't be
                dynamic.
    
                
    
                  

    
                  
    
                  
    In reality this is what PoP is supposed
                    to be for.
    
                  

    
                  
    
                  
    I guess the question is what short of
                    PoP can we do to prevent the client leaking tokens
                    to bad RS that confuse it via the application
                    protocol.
    
                  

    
                  
    
                  
    If we want to del with this in OAuth
                    then we need to tell the AS where the token is going
                    to be used or tel the client where the token can be
                    used. 
    
                  

    
                  
    
                  
    I think letting the client tell the AS
                    where it wants the token used having the AS
                    construct a audience out of that is probably the
                    best thing.  to get around having a pre-established=

                    relationship between the AS and RS.
    
                
    
                Even if the client tells the AS where it wants to use
                the token (via some endpoint URL), the AS still needs to
                have a relationship with the RS (at a minimum as an
                endpointURL-to-RS map) otherwise how can it determine if
                it is allowed to issue an access token to the user for
                that RS. This map is what I want to avoid "building"
                into the AS. Do we need "dynamic RS registration" to
                support this?
    
                
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 3:14 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        

    =

                            
    
                            I think Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            I'm not sure passing the full endpoint to
                            the AS will help with my concerns... The AS
                            could potentially do a webfinger on the
                            resource URI and determine if it's an RS
                            that it supports... though that requires all
                            RS's to support webfinger. What I really
                            want to avoid is the AS having this list of
                            URIs to RS that is almost assuredly to get
                            out of sync.
    
                            
    
                            
    
                          
    
                          
    On
                            3/15/16 1:56 PM, John Bradley wrote:
    
                          
    
                          
    I t=
hink it is a AS policy decision
                            if it should error or take the requested
                            resource and issue a token audianced for
                            that resource.
    
                          Actuall=
y,
                            the error cases are interesting. What if the
                            passed in resource/audience doesn't actually
                            match a requested scope? Or some match and
                            some don't? Is it better to send back a
                            token with less capability? or error the
                            entire request?
                          
    
                            

    
                            
    
                            
    I guess the question is how to
                              transition from now to a future state.  
                              If you cannot upgrade all the clients at
                              once.
    
                            

    
                            
    
                            
    A processing rule on the AS
                              that allowed some clients to not send the
                              requested resource , but would error out
                              for other upgraded clients  with a
                              "resource not allowed=E2=80=9D oauth error wou=
ld
                              work and not require the return of the
                              resources.  
    
                            

    
                            
    
                            
    If you return the resources
                              and let the client error if it is trying
                              to send to the wrong endpoint that make
                              upgrading easier, but gives less control
                              to the AS.
    
                            

    
                            
    
                            
    
                              
    
                                
    I could
                                    live with it ether way.
    
                                

    
                                
    
                                The advantage of always sending it in
                                the token request is that it allows the
                                AS to do the mapping from a resource URI
                                to one or more abstract audience for the
                                token.
    
                            
    
                          
    
                          I
                            thought Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            The question is how does a client internally
                            reference a resource server? If it's a fixed
                            RS endpoint, then it sort of doesn't matter,
                            the client isn't going to send the token to
                            the wrong endpoint anyway and it can easily
                            reference the audience by an abstract URI.
    
                            
    
                            If the client can dynamically find new RS's
                            to interact with. How does that happen? Does
                            the client get handed an endpoint to use? or
                            does it do some sort of discovery to
                            determine the endpoint? I suppose both are
                            possible.
    
                            
    
                            Could we prescribe that the realm value of
                            RFC 6750 error response be effectively a
                            resource-service-id (like issuer for the
                            AS). The client would then need to do
                            discovery on that value to find the valid
                            endpoints of the RS. This could be done once
                            and the resource-service-id could be used as
                            the "abstract" RS identifier. This requires
                            no more discovery than adding an AS to the
                            client.
    
                              
                          
    
                            
    
                              

    
                              
    
                              
    That might help address
                                George=E2=80=99s concern.
    
                            
    
                          
    
                          I'm
                            not sure passing the full endpoint to the AS
                            will help with my concerns... The AS could
                            potentially do a webfinger on the resource
                            URI and determine if it's an RS that it
                            supports... though that requires all RS's to
                            support webfinger. What I really want to
                            avoid is the AS having this map of URIs to
                            RS that is almost assuredly to get out of
                            sync.
                          
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                              
    
                              

    
                                
    
                                  
    On Mar 15, 2016, at 2:44
                                    PM, Brian Campbell <bcampbell@pingidentity.com>

                                    wrote:
    
                                  
    
                                  
    
                                    
    I was
                                      thinking it'd be simpler to error,
                                      if the requested resource(s)
                                      weren't okay. That puts the burden
                                      of checking in the AS. And doesn't
                                      add anything to the token or
                                      authorization response. I see the
                                      potential similarity to scope but
                                      not sure it's worth it.    
    
                                    

    
                                      
    On Tue,
                                        Mar 15, 2016 at 11:37 AM, John
                                        Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                        
    
                                          
    If the client
                                            specifies the resource it
                                            wants the token for, then
                                            the meta-data would not be
                                            required unless the
                                            resources the token is good
                                            at are different from the
                                            request.  
                                            
    Lat is the
                                              same logic as scopes.
    
                                            

    
                                            
    
                                            
    For backwards
                                              compatibility if the
                                              client is happy with the
                                              default resources based on
                                              scopes then I think it is
                                              a good idea to tell the
                                              client what the resources
                                              are in the response.
    
                                            

    
                                            
    
                                            
    I suspect that
                                              it is simpler with less
                                              optionality and always
                                              return the resources, even
                                              if they are not required.
                                            

    
                                            
    
                                            
    John B.
    
                                            
    
                                              
    
                                                

    
                                                
    
                                                
    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:46 PM, Brian
                                                        Campbell <bcampbell@pingidentity.com<=
/a>>

                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
    If
                                                          the client
                                                          specifies the
                                                          desired
                                                          audience(s)/resour=
ce(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for. 
    
                                                          
    
                                                          
    
                                                          

    
                                                          
    On

                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley =
;<ve7jtb@v=
e7jtb.com> wrote:
    
                                                          
    
                                                          
    Yes,

                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The

                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          audience.
    
                                                          

    
                                                          
    
                                                          
    If

                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time. 
                                                          

    
                                                          
    
                                                          
    In

                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil=E2=80=
=99s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
      <=
/div>
                                                          
    If

                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.  That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    William

                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John

                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    On

                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>

                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On

                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously 
    
                                                          
    
                                                          Hans. <=
/span>
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: =

    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty,&nbs=
p;
    
                                                          it=E2=80=99s not e=
ven
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases =E2=80=94=

                                                          it=E2=80=99s=
 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution=
 
    
                                                          mechanism in
                                                          that case.&n=
bsp;
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we=E2=80=99=
ve
                                                          really =

    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into&=
nbsp;
    
                                                          =E2=80=9Cscope=E2=80=
=9D that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: =
;
    
                                                          
    
                                                          
    
                                                            =
-
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile)&nbs=
p;
    
                                                            =
-
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete) 
    
                                                            =
-
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? <=
/span>
    
                                                          (offline_access/re=
fresh_token,

                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token <=
/span>
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. =
;
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in&n=
bsp;
    
                                                          with things
                                                          like
                                                          =E2=80=9Coffline_a=
ccess=E2=80=9D
                                                          in certain
                                                          APIs. <=
/span>
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we=E2=80=99re goin=
g to
                                                          be adding
                                                          things =

    
                                                          like
                                                          =E2=80=9Caudience=E2=
=80=9D or
                                                          =E2=80=9Cresource=E2=
=80=9D or
                                                          both to the
                                                          token
                                                          requests.&nb=
sp;
    
                                                          
    
                                                            =
=E2=80=94
                                                          Justin =

    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: =

    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify =
;
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about=
 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. <=
/span>
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are&nb=
sp;
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making=
 
    
                                                          a mess of
                                                          scopes. =
;
    
                                                          
    
                                                          John B. =
;
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>

                                                          wrote: =

    
                                                          
    
                                                          Inline =

    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com 
    =

                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: =

    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.  On=
e
                                                          was to provide
                                                          a spec for AS
                                                          metadata.&nb=
sp;
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack. =
;
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don=E2=80=99t 
    
                                                          otherwise need
                                                          discovery.&n=
bsp;
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth=
/charters?item=3Dcharter-oauth-2016-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint&nbs=
p;
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without =
;
    
                                                          discovery.&n=
bsp;
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to&n=
bsp;
    
                                                          the wrong
                                                          endpoint?&nb=
sp;
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably 
    
                                                          doesn=E2=80=99t ne=
ed
                                                          discovery.&n=
bsp;
    
                                                          
    
                                                          We agree&nbs=
p;
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find&n=
bsp;
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating&n=
bsp;
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives =

    
                                                          what the
                                                          resource is.=
 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not&=
nbsp;
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service.&nbs=
p;
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have&nb=
sp;
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. =
;
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process.&nbs=
p;
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production.&=
nbsp;
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly=
 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. <=
/span>
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn=E2=80=
=99t
                                                          know all the=
 
    
                                                          possible RS. =
 
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can&nb=
sp;
    
                                                          address.&nbs=
p;
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them. 
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS 
    
                                                          endpoints
                                                          intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request =
;
    
                                                          for each
                                                          endpoint.&nb=
sp;
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS&n=
bsp;
    
                                                          servers
                                                          assigned to
                                                          each instance? 
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner <=
/span>
    
                                                          are.  I think=

                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. =

    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints.&n=
bsp;
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a 
    
                                                          client chooses evil.com <http://evil.com/> =
;the cert can be valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to&n=
bsp;
    
                                                          res.example.com <http://res.example.c=
om/>? 
    
                                                          

    
                                                          If this is
             
    =

    ...
    

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

--Apple-Mail-31459CDC-7934-4141-B7C9-D3D21E1D8909--


From nobody Wed Mar 16 08:56:51 2016
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 66E3C12D680 for ; Wed, 16 Mar 2016 08:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.641
X-Spam-Level: 
X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 kRcQwHaOavOs for ; Wed, 16 Mar 2016 08:56:43 -0700 (PDT)
Received: from omr-a014e.mx.aol.com (omr-a014e.mx.aol.com [204.29.186.62]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E2412D574 for ; Wed, 16 Mar 2016 08:56:42 -0700 (PDT)
Received: from mtaout-aak02.mx.aol.com (mtaout-aak02.mx.aol.com [172.27.2.226]) by omr-a014e.mx.aol.com (Outbound Mail Relay) with ESMTP id CA4B438000BA; Wed, 16 Mar 2016 11:56:41 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aak02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1529A38000084; Wed, 16 Mar 2016 11:56:41 -0400 (EDT)
To: "Phil Hunt (IDM)" , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>  <56E96D48.90704@aol.com>  <4128BA28-F6B1-43E7-A6DB-8A8CC3425095@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E98238.8030003@aol.com>
Date: Wed, 16 Mar 2016 11:56:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <4128BA28-F6B1-43E7-A6DB-8A8CC3425095@oracle.com>
Content-Type: multipart/alternative; boundary="------------050807060703050300010408"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458143801; bh=Ar2rPSinb76ApdtA0FM5dri2HADn3gzXwucA3czmhIc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=zoLcyamukOiTjW3SaWoBQMFtN94wsOOv2eteC/LinvIS5uQT2rPZSFMJefo2V7UxM MbxwP1AhBEb0KZyon3cA1WzgduqFZ5yxlNJmxqi2Go2CuYsAPPfT3jIOIGvGuFQRJ+ rBPAfNehQpLi+XSpe/1FdWSYw8Uq/AdLjGoQfWMs=
x-aol-sid: 3039ac1b02e256e982393a43
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 15:56:49 -0000

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

For me the difference between the /token endpoint and an RS endpoint is 
semantic. The /token endpoint is part of the AS and a critical part of 
the authorization flow.

RS endpoints are under the control of the RS.

Thanks,
George

On 3/16/16 11:30 AM, Phil Hunt (IDM) wrote:
> John,
>
> Mis configured token endpoint and resource endpoint is the same client 
> misconfiguration issue where a client is mis-informed by mistake or 
> mis-deed.
>
> Why do you propose to solve token endpoint in config discovery but 
> feel resource endpoint must be reverified each time in the core protocol?
>
> Phil
>
> On Mar 16, 2016, at 07:46, John Bradley  > wrote:
>
>> If the client sends the uri of the resource it intends to send the 
>> token to in the token request the bad guy would get only a token 
>> audianced to itself and not to good RS.
>>
>> You can't solve the problem of bearer tokens with multiple audiences 
>> leaking.   That is a risk inherent in using that sort of token.   
>> Compromise in one RS will impact all of them.
>>
>> The only safe way with bearer to deal with a RS the AS dosen't trust 
>> a RS is to only have one audianced in the token. (or by introspection)
>>
>> We have always known that and left it up to clients to make sure they 
>> are secure by not sending tokens to bad RS.
>>
>> Now people want a AS check to prevent clients from being tricked if 
>> developers are given bad info statically or dynamically.
>>
>> What you are doing is safe as long as your developers don't make any 
>> mistakes.
>> If you want to be safe and not have to preconfigure the AS you need 
>> to use the refresh to get single audianced tokens, or PoP.
>>
>> John B.
>>
>> On Mar 16, 2016 11:27 AM, "George Fletcher" > > wrote:
>>
>>
>>
>>     On 3/15/16 6:14 PM, John Bradley wrote:
>>>     If the AS is audience restricting the tokens then it just needs
>>>     to put the right audience in the token based on what the client
>>>     is asking for.
>>>     That is safe as the RS wouldn’t be able to replay the token
>>>     someplace else.
>>     So let's assuming a client sends a token audience restricted to
>>     GoodRS instead to EvilRS. When EvilRS replays the token at the
>>     GoodRS endpoint, how does GoodRS reject the token because when
>>     GoodRS sends the token to the AS for introspection (or does so
>>     itself) the token will be audience restricted to the GoodRS and
>>     it will process the token. The only way to prevent this is with
>>     client-authentication so that the presenter can be matched
>>     against who is allowed to present the token (aka PoP).
>>
>>     In the pure bearer token model, I don't see how this can be
>>     prevented at the protocol level.
>>>
>>>     That would need to be a AS policy if it wanted to do that for
>>>     unknown RS.
>>>
>>>     Allowing more than one audience in a token is a convince but a
>>>     well known security risk with bearer tokens.
>>     True, but this means clients have to manage many tokens or call
>>     the token endpoint to get a "downscoped, audience restricted"
>>     token every time they need one. This is a very different model
>>     than what most people think of when they think of OAuth2. Not
>>     bad, just different:)
>>>
>>>     A AS would probably want to have only one audience in a AT for a
>>>     untrusted RS, but may allow multiple if they are all trusted.
>>>
>>>     John B.
>>>
>>>
>>>>     On Mar 15, 2016, at 6:28 PM, George Fletcher >>>     > wrote:
>>>>
>>>>
>>>>     On 3/15/16 3:26 PM, John Bradley wrote:
>>>>>     I think Phil and others are concerned that a developer might
>>>>>     get bad info to put in the client , some out of band discovery
>>>>>     goes wrong or the user is somehow tricked into specifying a
>>>>>     bad resource to the client.
>>>>>
>>>>>     So getting a bad resource is a touch hypothetical.
>>>>     If we are really trying to solve this problem holistically,
>>>>     then we probably need to first describe the use cases we want
>>>>     to solve. I'm starting to wonder if we are all providing
>>>>     solutions to slightly different use cases.
>>>>>
>>>>>     For Connect we could suppose that someone publishes a
>>>>>     malicious discovery document listing themselves as the RS but
>>>>>     all the other endpoints are at the good AS so the client
>>>>>     registers, authorizes the user and gives the AT to the bad
>>>>>     guy.  The confused client mitigation by returning
>>>>>     client_id_and issuer from the authorization endpoint will stop
>>>>>     the attack before the token can be given to the token endpoint
>>>>>     or RS.
>>>>     Agreed and I'm fine with this solution.
>>>>>
>>>>>     So protecting the AT at this point is more for a unknown
>>>>>     attack that would confuse whatever protocol/API that is using
>>>>>     OAuth about what RS to use.
>>>>     Yes. This is where we need to describe some use cases
>>>>     (preferably real vs contrived) before we propose solutions. In
>>>>     most cases the RS endpoints are hard coded into the client or
>>>>     maybe pulled from a different central config endpoint (which is
>>>>     fixed).
>>>>
>>>>     That's why the only case I could think of is a client that
>>>>     works with multiple RS endpoints from different providers that
>>>>     server the same content (e.g. PortableContacts API). In this
>>>>     use case, the user of the client would need to enter the
>>>>     location of the RS they wanted to use and then the flow would
>>>>     start from there. In reality, most services like this would
>>>>     have a fixed set of RS's they work with and again it wouldn't
>>>>     be dynamic.
>>>>>
>>>>>     In reality this is what PoP is supposed to be for.
>>>>>
>>>>>     I guess the question is what short of PoP can we do to prevent
>>>>>     the client leaking tokens to bad RS that confuse it via the
>>>>>     application protocol.
>>>>>
>>>>>     If we want to del with this in OAuth then we need to tell the
>>>>>     AS where the token is going to be used or tel the client where
>>>>>     the token can be used.
>>>>>
>>>>>     I think letting the client tell the AS where it wants the
>>>>>     token used having the AS construct a audience out of that is
>>>>>     probably the best thing.  to get around having a
>>>>>     pre-established relationship between the AS and RS.
>>>>     Even if the client tells the AS where it wants to use the token
>>>>     (via some endpoint URL), the AS still needs to have a
>>>>     relationship with the RS (at a minimum as an endpointURL-to-RS
>>>>     map) otherwise how can it determine if it is allowed to issue
>>>>     an access token to the user for that RS. This map is what I
>>>>     want to avoid "building" into the AS. Do we need "dynamic RS
>>>>     registration" to support this?
>>>>
>>>>>
>>>>>     John B.
>>>>>
>>>>>>     On Mar 15, 2016, at 3:14 PM, George Fletcher
>>>>>>     > wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>     I think Justin provided a good break down of the different
>>>>>>     aspects a client wants to specify about the requested token.
>>>>>>     (my paraphrase)
>>>>>>       1. what RS's the token will be used at
>>>>>>       2. authorization privilege requests
>>>>>>       3. token-timing adjustments
>>>>>>
>>>>>>     I'm not sure passing the full endpoint to the AS will help
>>>>>>     with my concerns... The AS could potentially do a webfinger
>>>>>>     on the resource URI and determine if it's an RS that it
>>>>>>     supports... though that requires all RS's to support
>>>>>>     webfinger. What I really want to avoid is the AS having this
>>>>>>     list of URIs to RS that is almost assuredly to get out of sync.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On 3/15/16 1:56 PM, John Bradley wrote:
>>>>>>>     I think it is a AS policy decision if it should error or
>>>>>>>     take the requested resource and issue a token audianced for
>>>>>>>     that resource.
>>>>>>     Actually, the error cases are interesting. What if the passed
>>>>>>     in resource/audience doesn't actually match a requested
>>>>>>     scope? Or some match and some don't? Is it better to send
>>>>>>     back a token with less capability? or error the entire request?
>>>>>>>
>>>>>>>     I guess the question is how to transition from now to a
>>>>>>>     future state.   If you cannot upgrade all the clients at once.
>>>>>>>
>>>>>>>     A processing rule on the AS that allowed some clients to not
>>>>>>>     send the requested resource , but would error out for other
>>>>>>>     upgraded clients  with a "resource not allowed†oauth error
>>>>>>>     would work and not require the return of the resources.
>>>>>>>
>>>>>>>     If you return the resources and let the client error if it
>>>>>>>     is trying to send to the wrong endpoint that make upgrading
>>>>>>>     easier, but gives less control to the AS.
>>>>>>>
>>>>>>>     I could live with it ether way.
>>>>>>>
>>>>>>>     The advantage of always sending it in the token request is
>>>>>>>     that it allows the AS to do the mapping from a resource URI
>>>>>>>     to one or more abstract audience for the token.
>>>>>>     I thought Justin provided a good break down of the different
>>>>>>     aspects a client wants to specify about the requested token.
>>>>>>     (my paraphrase)
>>>>>>       1. what RS's the token will be used at
>>>>>>       2. authorization privilege requests
>>>>>>       3. token-timing adjustments
>>>>>>
>>>>>>     The question is how does a client internally reference a
>>>>>>     resource server? If it's a fixed RS endpoint, then it sort of
>>>>>>     doesn't matter, the client isn't going to send the token to
>>>>>>     the wrong endpoint anyway and it can easily reference the
>>>>>>     audience by an abstract URI.
>>>>>>
>>>>>>     If the client can dynamically find new RS's to interact with.
>>>>>>     How does that happen? Does the client get handed an endpoint
>>>>>>     to use? or does it do some sort of discovery to determine the
>>>>>>     endpoint? I suppose both are possible.
>>>>>>
>>>>>>     Could we prescribe that the realm value of RFC 6750 error
>>>>>>     response be effectively a resource-service-id (like issuer
>>>>>>     for the AS). The client would then need to do discovery on
>>>>>>     that value to find the valid endpoints of the RS. This could
>>>>>>     be done once and the resource-service-id could be used as the
>>>>>>     "abstract" RS identifier. This requires no more discovery
>>>>>>     than adding an AS to the client.
>>>>>>>
>>>>>>>     That might help address George’s concern.
>>>>>>     I'm not sure passing the full endpoint to the AS will help
>>>>>>     with my concerns... The AS could potentially do a webfinger
>>>>>>     on the resource URI and determine if it's an RS that it
>>>>>>     supports... though that requires all RS's to support
>>>>>>     webfinger. What I really want to avoid is the AS having this
>>>>>>     map of URIs to RS that is almost assuredly to get out of sync.
>>>>>>>
>>>>>>>     John B.
>>>>>>>
>>>>>>>
>>>>>>>>     On Mar 15, 2016, at 2:44 PM, Brian Campbell
>>>>>>>>     >>>>>>>     > wrote:
>>>>>>>>
>>>>>>>>     I was thinking it'd be simpler to error, if the requested
>>>>>>>>     resource(s) weren't okay. That puts the burden of checking
>>>>>>>>     in the AS. And doesn't add anything to the token or
>>>>>>>>     authorization response. I see the potential similarity to
>>>>>>>>     scope but not sure it's worth it.
>>>>>>>>
>>>>>>>>     On Tue, Mar 15, 2016 at 11:37 AM, John
>>>>>>>>     Bradley>wrote:
>>>>>>>>
>>>>>>>>         If the client specifies the resource it wants the token
>>>>>>>>         for, then the meta-data would not be required unless
>>>>>>>>         the resources the token is good at are different from
>>>>>>>>         the request.
>>>>>>>>         Lat is the same logic as scopes.
>>>>>>>>
>>>>>>>>         For backwards compatibility if the client is happy with
>>>>>>>>         the default resources based on scopes then I think it
>>>>>>>>         is a good idea to tell the client what the resources
>>>>>>>>         are in the response.
>>>>>>>>
>>>>>>>>         I suspect that it is simpler with less optionality and
>>>>>>>>         always return the resources, even if they are not required.
>>>>>>>>
>>>>>>>>         John B.
>>>>>>>>
>>>>>>>>>         On Mar 15, 2016, at 12:46 PM, Brian Campbell
>>>>>>>>>         >>>>>>>>         > wrote:
>>>>>>>>>
>>>>>>>>>         If the client specifies the desired
>>>>>>>>>         audience(s)/resource(s), is that metadata to the
>>>>>>>>>         client needed? The AS can audience restrict the token
>>>>>>>>>         as needed or respond with an error if it can't or wont
>>>>>>>>>         issue a token for the resource the client asked for.
>>>>>>>>>
>>>>>>>>>         On Tue, Mar 15, 2016 at 9:37 AM, John
>>>>>>>>>         Bradley>>>>>>>>         >wrote:
>>>>>>>>>
>>>>>>>>>             Yes,  I think bearer tokens with no audience are a
>>>>>>>>>             bad idea.
>>>>>>>>>
>>>>>>>>>             The AS needs to infer an audience from the scopes
>>>>>>>>>             snd/or have the client specify the desired audience.
>>>>>>>>>
>>>>>>>>>             If the AT has a audience or audiences then as long
>>>>>>>>>             as the endpoint URI are provided as meta-data with
>>>>>>>>>             the token, the client can determine if it is
>>>>>>>>>             sending the token to the correct place.
>>>>>>>>>
>>>>>>>>>             I think Phil would prefer the server rather than
>>>>>>>>>             the client do the check, but the client always
>>>>>>>>>             needs to take some responsibility to not leak
>>>>>>>>>             tokens giving them to the wrong RS or the code to
>>>>>>>>>             the wrong token endpoint is leaking.
>>>>>>>>>
>>>>>>>>>             I imagine that claims based access tokens are
>>>>>>>>>             going to become more popular and the static
>>>>>>>>>             relationship between one RS and one AS will not be
>>>>>>>>>             the majority of deployments over time.
>>>>>>>>>
>>>>>>>>>             In any case where the client is configured up
>>>>>>>>>             front to know the RS and the AS it seems like that
>>>>>>>>>             would not require Phil’s Solution, but that is the
>>>>>>>>>             only case supported by that discovery.
>>>>>>>>>             If the client itself is bad there is not much you
>>>>>>>>>             can do to stop it from passing on the AT in way
>>>>>>>>>             way it wants. That however is a different problem
>>>>>>>>>             and needs claimed URI or attestations to prevent
>>>>>>>>>             client spoofing.
>>>>>>>>>             William and I are working on that in the mobile
>>>>>>>>>             best practices draft.
>>>>>>>>>
>>>>>>>>>             John B.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>             On Mar 15, 2016, at 12:09 PM, George Fletcher
>>>>>>>>>>             > wrote:
>>>>>>>>>>
>>>>>>>>>>             I worry about two directions I see in this thread...
>>>>>>>>>>
>>>>>>>>>>             1. Client's accessing resources dynamically so
>>>>>>>>>>             that discovery is required to know the correct
>>>>>>>>>>             AS, etc. This is pretty much the classic use case
>>>>>>>>>>             for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>
>>>>>>>>>>             2. Creating a tight coupling between RS and AS
>>>>>>>>>>             such that RS endpoint changes must be continually
>>>>>>>>>>             communicated to the AS. If an RS supports
>>>>>>>>>>             multiple AS's then the RS has to deal with
>>>>>>>>>>             "guaranteed" delivery. The AS needs an endpoint
>>>>>>>>>>             to receive such communications. If not dynamic
>>>>>>>>>>             via APIs, then deployment of the new RS is bound
>>>>>>>>>>             by the associated AS's getting and deploying the
>>>>>>>>>>             new endpoints. Can both endpoints of the RS be
>>>>>>>>>>             supported within the AS for some period of time,
>>>>>>>>>>             etc. This is an operation nightmare and almost
>>>>>>>>>>             assuredly going to go wrong in production.
>>>>>>>>>>
>>>>>>>>>>             Maybe an OAuth2 "audience binding" spec is what's
>>>>>>>>>>             needed for those deployments that require this. I
>>>>>>>>>>             believe that is what John Bradley is suggesting.
>>>>>>>>>>
>>>>>>>>>>             Thanks,
>>>>>>>>>>             George
>>>>>>>>>>
>>>>>>>>>>             On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>>>>>             +1, I've found the very same in OAuth
>>>>>>>>>>>             deployments that I was involved in; the hard
>>>>>>>>>>>             part is to give names and descriptions to these
>>>>>>>>>>>             concepts so that they cover all use cases and
>>>>>>>>>>>             can be applied unambiguously
>>>>>>>>>>>
>>>>>>>>>>>             Hans.
>>>>>>>>>>>
>>>>>>>>>>>             On 3/14/16 10:44 PM, Justin Richer wrote:
>>>>>>>>>>>>             I agree that this is valuable, and not just for
>>>>>>>>>>>>             PoP. In all honesty,
>>>>>>>>>>>>             it’s not even really required for PoP to
>>>>>>>>>>>>             function in many cases — it’s
>>>>>>>>>>>>             just an optimization for one particular kind of
>>>>>>>>>>>>             key distribution
>>>>>>>>>>>>             mechanism in that case.
>>>>>>>>>>>>
>>>>>>>>>>>>             In the years of deployment experience with
>>>>>>>>>>>>             OAuth 2, I think we’ve really
>>>>>>>>>>>>             got three different kinds of things that
>>>>>>>>>>>>             currently get folded into
>>>>>>>>>>>>             “scope†that we might want to try separating
>>>>>>>>>>>>             out better:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>             - What things do I want to access? (photos,
>>>>>>>>>>>>             profile)
>>>>>>>>>>>>             - What actions do I want to take on these
>>>>>>>>>>>>             things? (read, write, delete)
>>>>>>>>>>>>             - How long do I want these tokens to work?
>>>>>>>>>>>>             (offline_access/refresh_token, one time use,
>>>>>>>>>>>>             next hour, etc)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>             I think the first one is close to the
>>>>>>>>>>>>             audience/resource parameters that
>>>>>>>>>>>>             have been bandied about a few times, including
>>>>>>>>>>>>             in the current token
>>>>>>>>>>>>             exchange document. We should be consistent
>>>>>>>>>>>>             across drafts in that regard.
>>>>>>>>>>>>             The second is more traditional scope-ish. The
>>>>>>>>>>>>             third has been patched in
>>>>>>>>>>>>             with things like “offline_access†in certain APIs.
>>>>>>>>>>>>
>>>>>>>>>>>>             Just another vector to think about if we’re
>>>>>>>>>>>>             going to be adding things
>>>>>>>>>>>>             like “audience†or “resource†or both to the
>>>>>>>>>>>>             token requests.
>>>>>>>>>>>>
>>>>>>>>>>>>             — Justin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>             On Mar 14, 2016, at 6:26 PM, John Bradley
>>>>>>>>>>>>>             
>>>>>>>>>>>>>             
>>>>>>>>>>>>>             > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>             Yes I will work on another proposal for
>>>>>>>>>>>>>             allowing clients to specify
>>>>>>>>>>>>>             what resource they want a token for and
>>>>>>>>>>>>>             providing the meta-data to the
>>>>>>>>>>>>>             client about the resources that a token is
>>>>>>>>>>>>>             valid for.
>>>>>>>>>>>>>
>>>>>>>>>>>>>             We have part of it in the POP key distribution
>>>>>>>>>>>>>             spec and talked about
>>>>>>>>>>>>>             separating it, as it is used more places than
>>>>>>>>>>>>>             just for assigning keys.
>>>>>>>>>>>>>             I know some AS use different token formats for
>>>>>>>>>>>>>             different RS so are
>>>>>>>>>>>>>             all-ready needing to pass the resource in the
>>>>>>>>>>>>>             request to avoid making
>>>>>>>>>>>>>             a mess of scopes.
>>>>>>>>>>>>>
>>>>>>>>>>>>>             John B.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>             On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)
>>>>>>>>>>>>>>             >>>>>>>>>>>>>             
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>             > wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             Inline
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             Phil
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             On Mar 14, 2016, at 14:13, John Bradley
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>             > wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             We had two mandates.  One was to provide a
>>>>>>>>>>>>>>>             spec for AS metadata.
>>>>>>>>>>>>>>>             The other was to mitigate the client mixup
>>>>>>>>>>>>>>>             attack. The request was
>>>>>>>>>>>>>>>             to do the latter without requiring the
>>>>>>>>>>>>>>>             former for clients that don’t
>>>>>>>>>>>>>>>             otherwise need discovery.
>>>>>>>>>>>>>>             There is no mandate for any of this. See
>>>>>>>>>>>>>>             http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             Returning the issuer and client_id from the
>>>>>>>>>>>>>>>             authorization endpoint
>>>>>>>>>>>>>>>             and the client checking them can be done by
>>>>>>>>>>>>>>>             the client without
>>>>>>>>>>>>>>>             discovery.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             How does this address the issue of whether
>>>>>>>>>>>>>>             the client is talking to
>>>>>>>>>>>>>>             the wrong endpoint?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             Any client that has the resource and issuer
>>>>>>>>>>>>>>>             hard coded probably
>>>>>>>>>>>>>>>             doesn’t need discovery.
>>>>>>>>>>>>>>             We agree
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             One of the things that a client will need
>>>>>>>>>>>>>>>             discovery for is to find
>>>>>>>>>>>>>>>             the RS, so requiring the client to know the
>>>>>>>>>>>>>>>             RS URI before getting
>>>>>>>>>>>>>>>             the AS config seems backwards to me.
>>>>>>>>>>>>>>             How can you make an assumption on order? You
>>>>>>>>>>>>>>             seem to be conflating
>>>>>>>>>>>>>>             authentication with authorization by assuming
>>>>>>>>>>>>>>             the identity drives
>>>>>>>>>>>>>>             what the resource is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             There are lots of applications that require
>>>>>>>>>>>>>>             user rights but are not
>>>>>>>>>>>>>>             identify centric. For example a document service.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             Unless the client tells the AS where it
>>>>>>>>>>>>>>>             intends to use the token we
>>>>>>>>>>>>>>>             will be leaving a security hole because the
>>>>>>>>>>>>>>>             bearer tokens will have
>>>>>>>>>>>>>>>             too loose an audience if they have one at all.
>>>>>>>>>>>>>>             This is the biggest risk we have IMHO.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             True you are telling the AS (Webfinger
>>>>>>>>>>>>>>>             service) what the RS is but
>>>>>>>>>>>>>>>             that is not at a place that is useful in the
>>>>>>>>>>>>>>>             token production process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             This has nothing to do with token production.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             What we want to ensure is whether an honest
>>>>>>>>>>>>>>             client is correctly
>>>>>>>>>>>>>>             configured and has not been mislead - eg by a
>>>>>>>>>>>>>>             phishing page.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             I also think there are use cases where the
>>>>>>>>>>>>>>>             AS doesn’t know all the
>>>>>>>>>>>>>>>             possible RS. That is not something that a
>>>>>>>>>>>>>>>             out of band check can
>>>>>>>>>>>>>>>             address.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             May be. Lets identify them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             There are also cases where a token might be
>>>>>>>>>>>>>>>             good at multiple RS
>>>>>>>>>>>>>>>             endpoints intentionally.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>              In your solution the client would need to
>>>>>>>>>>>>>>>             make a discovery request
>>>>>>>>>>>>>>>             for each endpoint.
>>>>>>>>>>>>>>             Sure. Otherwise how would it know if there is
>>>>>>>>>>>>>>             one AS or a pool of AS
>>>>>>>>>>>>>>             servers assigned to each instance?
>>>>>>>>>>>>>>>             Those requests lack the context of who the
>>>>>>>>>>>>>>>             client and resource owner
>>>>>>>>>>>>>>>             are.  I think that will be a problem in some
>>>>>>>>>>>>>>>             use cases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             Not sure I agree. This is about discovering a
>>>>>>>>>>>>>>             valid set of endpoints.
>>>>>>>>>>>>>>             For mitm, we mainly want to check the
>>>>>>>>>>>>>>             hostname is correct. If a
>>>>>>>>>>>>>>             client choosesevil.com
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>             the cert can be valid and
>>>>>>>>>>>>>>             TLS will pass. How does it otherwise know it
>>>>>>>>>>>>>>             is supposed to talk to
>>>>>>>>>>>>>>             res.example.com
>>>>>>>>>>>>>>             
>>>>>>>>>>>>>>             ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             If this is 
>>>>>>>>>
>>     ...
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    For me the difference between
      the /token endpoint and an RS endpoint is semantic. The /token endpoint
      is part of the AS and a critical part of the authorization flow.
    
      
    
      RS endpoints are under the control of the RS.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/16/16 11:30 AM, Phil Hunt (IDM)
      wrote:
    
    
    
    
    
      
      
    John,
    
      

    
      
    
      
    Mis configured token endpoint and
        resource endpoint is the same client misconfiguration issue
        where a client is mis-informed by mistake or mis-deed. 
    
      

    
      
    
      
    Why do you propose to solve token
        endpoint in config discovery but feel resource endpoint must be
        reverified each time in the core protocol? 
    
      
    
      

    
        Phil
    
      

    
        On Mar 16, 2016, at 07:46, John Bradley <ve7jtb@ve7jtb.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
    If the client sends the uri of the resource it
            intends to send the token to in the token request the bad
            guy would get only a token audianced to itself and not to
            good RS.  
    
          
    You can't solve the problem of bearer tokens with
            multiple audiences leaking.   That is a risk inherent in
            using that sort of token.   Compromise in one RS will impact
            all of them.  
    
          
    The only safe way with bearer to deal with a RS
            the AS dosen't trust a RS is to only have one audianced in
            the token. (or by introspection)
    
          
    We have always known that and left it up to
            clients to make sure they are secure by not sending tokens
            to bad RS.  
    
          
    Now people want a AS check to prevent clients
            from being tricked if developers are given bad info
            statically or dynamically. 
    
          
    What you are doing is safe as long as your
            developers don't make any mistakes. 
    
            If you want to be safe and not have to preconfigure the AS
            you need to use the refresh to get single audianced tokens,
            or PoP.
    
          
    John B. 
    
          
    On Mar 16, 2016 11:27 AM, "George
            Fletcher" <gffletch@aol.com>
            wrote:
    
            
    
              
     
    
                
    
                
    On 3/15/16 6:14 PM, John Bradley wrote:
    
                
    
                
     If the AS is audience
                  restricting the tokens then it just needs to put the
                  right audience in the token based on what the client
                  is asking for.  
                  
    That is safe as the RS wouldn’t be able to replay
                    the token someplace else.
    
                
    
                So let's assuming a client sends a token audience
                restricted to GoodRS instead to EvilRS. When EvilRS
                replays the token at the GoodRS endpoint, how does
                GoodRS reject the token because when GoodRS sends the
                token to the AS for introspection (or does so itself)
                the token will be audience restricted to the GoodRS and
                it will process the token. The only way to prevent this
                is with client-authentication so that the presenter can
                be matched against who is allowed to present the token
                (aka PoP).
    
                
    
                In the pure bearer token model, I don't see how this can
                be prevented at the protocol level.
    
                
    
                  

    
                  
    
                  
    That would need to be a AS policy if it wanted to
                    do that for unknown RS.   
    
                  

    
                  
    
                  
    Allowing more than one audience in a token is a
                    convince but a well known security risk with bearer
                    tokens.
    
                
    
                True, but this means clients have to manage many tokens
                or call the token endpoint to get a "downscoped,
                audience restricted" token every time they need one.
                This is a very different model than what most people
                think of when they think of OAuth2. Not bad, just
                different:)
    
                
    
                  

    
                  
    
                  
    A AS would probably want to have only one
                    audience in a AT for a untrusted RS, but may allow
                    multiple if they are all trusted.
    
                  

    
                  
    
                  
    John B.
    
                  

    
                  
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 6:28 PM, George
                          Fletcher <gffletch@aol.com>
                          wrote:
    
                        
    
                        
    
                          
     
    
                            
    On 3/15/16 3:26 PM, John Bradley wrote:
    
                            
    
                            
     I think Phil and
                              others are concerned that a developer
                              might get bad info to put in the client ,
                              some out of band discovery goes wrong or
                              the user is somehow tricked into
                              specifying a bad resource to the client.
                              

    
                              
    
                              
    So getting a bad resource is a touch
                                hypothetical. 
    
                              
    
                            
    
                            If we are really trying to solve this
                            problem holistically, then we probably need
                            to first describe the use cases we want to
                            solve. I'm starting to wonder if we are all
                            providing solutions to slightly different
                            use cases.
    
                            
    
                              

    
                              
    
                              
    For Connect we could suppose that
                                someone publishes a malicious discovery
                                document listing themselves as the RS
                                but all the other endpoints are at the
                                good AS so the client registers,
                                authorizes the user and gives the AT to
                                the bad guy.  The confused client
                                mitigation by returning client_id_and
                                issuer from the authorization endpoint
                                will stop the attack before the token
                                can be given to the token endpoint or
                                RS.
    
                            
    
                            Agreed and I'm fine with this solution.
    
                            
    
                              

    
                              
    
                              
    So protecting the AT at this point is
                                more for a unknown attack that would
                                confuse whatever protocol/API that is
                                using OAuth about what RS to use.
    
                            
    
                            Yes. This is where we need to describe some
                            use cases (preferably real vs contrived)
                            before we propose solutions. In most cases
                            the RS endpoints are hard coded into the
                            client or maybe pulled from a different
                            central config endpoint (which is fixed).
    
                            
    
                            That's why the only case I could think of is
                            a client that works with multiple RS
                            endpoints from different providers that
                            server the same content (e.g.
                            PortableContacts API). In this use case, the
                            user of the client would need to enter the
                            location of the RS they wanted to use and
                            then the flow would start from there. In
                            reality, most services like this would have
                            a fixed set of RS's they work with and again
                            it wouldn't be dynamic.
    
                            
    
                              

    
                              
    
                              
    In reality this is what PoP is
                                supposed to be for.
    
                              

    
                              
    
                              
    I guess the question is what short of
                                PoP can we do to prevent the client
                                leaking tokens to bad RS that confuse it
                                via the application protocol.
    
                              

    
                              
    
                              
    If we want to del with this in OAuth
                                then we need to tell the AS where the
                                token is going to be used or tel the
                                client where the token can be used. 
    
                              

    
                              
    
                              
    I think letting the client tell the
                                AS where it wants the token used having
                                the AS construct a audience out of that
                                is probably the best thing.  to get
                                around having a pre-established
                                relationship between the AS and RS.
    
                            
    
                            Even if the client tells the AS where it
                            wants to use the token (via some endpoint
                            URL), the AS still needs to have a
                            relationship with the RS (at a minimum as an
                            endpointURL-to-RS map) otherwise how can it
                            determine if it is allowed to issue an
                            access token to the user for that RS. This
                            map is what I want to avoid "building" into
                            the AS. Do we need "dynamic RS registration"
                            to support this?
    
                            
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                                
    
                                  
    
                                    
    On Mar 15, 2016, at 3:14 PM,
                                      George Fletcher <gffletch@aol.com>


                                      wrote:
    
                                    
    
                                    

    
                                        
    
                                        I think Justin provided a good
                                        break down of the different
                                        aspects a client wants to
                                        specify about the requested
                                        token. (my paraphrase)
    
                                          1. what RS's the token will be
                                        used at
    
                                          2. authorization privilege
                                        requests
    
                                          3. token-timing adjustments
    
                                        
    
                                        I'm not sure passing the full
                                        endpoint to the AS will help
                                        with my concerns... The AS could
                                        potentially do a webfinger on
                                        the resource URI and determine
                                        if it's an RS that it
                                        supports... though that requires
                                        all RS's to support webfinger.
                                        What I really want to avoid is
                                        the AS having this list of URIs
                                        to RS that is almost assuredly
                                        to get out of sync.
    
                                        
    
                                        
    
                                      
    
                                      
    On

                                        3/15/16 1:56 PM, John Bradley
                                        wrote:
    
                                      
    
                                      
    I
                                        think it is a AS policy decision
                                        if it should error or take the
                                        requested resource and issue a
                                        token audianced for that
                                        resource.
    
                                      Actually, the error
                                        cases are interesting. What if
                                        the passed in resource/audience
                                        doesn't actually match a
                                        requested scope? Or some match
                                        and some don't? Is it better to
                                        send back a token with less
                                        capability? or error the entire
                                        request?
                                      
    
                                        

    
                                        
    
                                        
    I guess the question is how
                                          to transition from now to a
                                          future state.   If you cannot
                                          upgrade all the clients at
                                          once.
    
                                        

    
                                        
    
                                        
    A processing rule on the AS
                                          that allowed some clients to
                                          not send the requested
                                          resource , but would error out
                                          for other upgraded clients
                                           with a "resource not allowedâ€
                                          oauth error would work and not
                                          require the return of the
                                          resources.  
    
                                        

    
                                        
    
                                        
    If you return the resources
                                          and let the client error if it
                                          is trying to send to the wrong
                                          endpoint that make upgrading
                                          easier, but gives less control
                                          to the AS.
    
                                        

    
                                        
    
                                        
    
                                          
    
                                            
    I could live with
                                                it ether way.
    
                                            

    
                                            
    
                                            The advantage of always
                                            sending it in the token
                                            request is that it allows
                                            the AS to do the mapping
                                            from a resource URI to one
                                            or more abstract audience
                                            for the token.
    
                                        
    
                                      
    
                                      I thought Justin
                                        provided a good break down of
                                        the different aspects a client
                                        wants to specify about the
                                        requested token. (my paraphrase)
    
                                          1. what RS's the token will be
                                        used at
    
                                          2. authorization privilege
                                        requests
    
                                          3. token-timing adjustments
    
                                        
    
                                        The question is how does a
                                        client internally reference a
                                        resource server? If it's a fixed
                                        RS endpoint, then it sort of
                                        doesn't matter, the client isn't
                                        going to send the token to the
                                        wrong endpoint anyway and it can
                                        easily reference the audience by
                                        an abstract URI.
    
                                        
    
                                        If the client can dynamically
                                        find new RS's to interact with.
                                        How does that happen? Does the
                                        client get handed an endpoint to
                                        use? or does it do some sort of
                                        discovery to determine the
                                        endpoint? I suppose both are
                                        possible.
    
                                        
    
                                        Could we prescribe that the
                                        realm value of RFC 6750 error
                                        response be effectively a
                                        resource-service-id (like issuer
                                        for the AS). The client would
                                        then need to do discovery on
                                        that value to find the valid
                                        endpoints of the RS. This could
                                        be done once and the
                                        resource-service-id could be
                                        used as the "abstract" RS
                                        identifier. This requires no
                                        more discovery than adding an AS
                                        to the client.
    
                                          
                                      
    
                                        
    
                                          

    
                                          
    
                                          
    That might help address
                                            George’s concern.
    
                                        
    
                                      
    
                                      I'm not sure passing
                                        the full endpoint to the AS will
                                        help with my concerns... The AS
                                        could potentially do a webfinger
                                        on the resource URI and
                                        determine if it's an RS that it
                                        supports... though that requires
                                        all RS's to support webfinger.
                                        What I really want to avoid is
                                        the AS having this map of URIs
                                        to RS that is almost assuredly
                                        to get out of sync.
                                      
    
                                        
    
                                          

    
                                          
    
                                          
    John B.
    
                                          

    
                                          
    
                                          

    
                                            
    
                                              
    On Mar 15, 2016, at
                                                2:44 PM, Brian Campbell
                                                <bcampbell@pingidentity.com>


                                                wrote:
    
                                              
    
                                              
    
                                                
    I was
                                                  thinking it'd be
                                                  simpler to error, if
                                                  the requested
                                                  resource(s) weren't
                                                  okay. That puts the
                                                  burden of checking in
                                                  the AS. And doesn't
                                                  add anything to the
                                                  token or authorization
                                                  response. I see the
                                                  potential similarity
                                                  to scope but not sure
                                                  it's worth it.    
    
                                                

    
                                                  
    On
                                                    Tue, Mar 15, 2016 at
                                                    11:37 AM, John
                                                    Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                                    
    
                                                      
    If
                                                        the client
                                                        specifies the
                                                        resource it
                                                        wants the token
                                                        for, then the
                                                        meta-data would
                                                        not be required
                                                        unless the
                                                        resources the
                                                        token is good at
                                                        are different
                                                        from the
                                                        request.  
                                                        
    Lat is the
                                                          same logic as
                                                          scopes.
    
                                                        

    
                                                        
    
                                                        
    For
                                                          backwards
                                                          compatibility
                                                          if the client
                                                          is happy with
                                                          the default
                                                          resources
                                                          based on
                                                          scopes then I
                                                          think it is a
                                                          good idea to
                                                          tell the
                                                          client what
                                                          the resources
                                                          are in the
                                                          response.
    
                                                        

    
                                                        
    
                                                        
    I suspect
                                                          that it is
                                                          simpler with
                                                          less
                                                          optionality
                                                          and always
                                                          return the
                                                          resources,
                                                          even if they
                                                          are not
                                                          required.
    
                                                        

    
                                                        
    
                                                        
    John B.
    
                                                        
    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On Mar
                                                          15, 2016, at
                                                          12:46 PM,
                                                          Brian Campbell
                                                          <bcampbell@pingidentity.com>


                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    If

                                                          the client
                                                          specifies the
                                                          desired
                                                          audience(s)/resource(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for. 
    
                                                          
    
                                                          
    
                                                          

    
                                                          
    On


                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                                          
    
                                                          
    Yes,


                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The AS
                                                          needs to infer
                                                          an audience
                                                          from the
                                                          scopes snd/or
                                                          have the
                                                          client specify
                                                          the desired
                                                          audience.
    
                                                          

    
                                                          
    
                                                          
    If the AT
                                                          has a audience
                                                          or audiences
                                                          then as long
                                                          as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I think
                                                          Phil would
                                                          prefer the
                                                          server rather
                                                          than the
                                                          client do the
                                                          check, but the
                                                          client always
                                                          needs to take
                                                          some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          

    
                                                          
    
                                                          
    I imagine
                                                          that claims
                                                          based access
                                                          tokens are
                                                          going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time. 
    
                                                          

    
                                                          
    
                                                          
    In any
                                                          case where the
                                                          client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil’s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
      
    
                                                          
    If the
                                                          client itself
                                                          is bad there
                                                          is not much
                                                          you can do to
                                                          stop it from
                                                          passing on the
                                                          AT in way way
                                                          it wants. 
                                                          That however
                                                          is a different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    William
                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    
                                                          
    
                                                          
    On Mar
                                                          15, 2016, at
                                                          12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>


                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          

    
                                                          
    On
                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,

                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously 
    
                                                          
    
                                                          Hans. 
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: 
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty, 
    
                                                          it’s not even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases —
                                                          it’s 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution 
    
                                                          mechanism in
                                                          that case. 
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we’ve
                                                          really 
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into 
    
                                                          “scope†that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: 
    
                                                          
    
                                                          
    
                                                            -
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile) 
    
                                                            -
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete) 
    
                                                            -
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? 
    
                                                          (offline_access/refresh_token,


                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token 
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. 
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in 
    
                                                          with things
                                                          like
                                                          “offline_accessâ€
                                                          in certain
                                                          APIs. 
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we’re going to
                                                          be adding
                                                          things 
    
                                                          like
                                                          “audience†or
                                                          “resource†or
                                                          both to the
                                                          token
                                                          requests. 
    
                                                          
    
                                                            —
                                                          Justin 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>


                                                          wrote: 
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify 
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. 
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are 
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making 
    
                                                          a mess of
                                                          scopes. 
    
                                                          
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>


                                                          wrote: 
    
                                                          
    
                                                          Inline 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>


                                                          wrote: 
    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.  One
                                                          was to provide
                                                          a spec for AS
                                                          metadata. 
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack. 
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don’t 
    
                                                          otherwise need
                                                          discovery. 
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint 
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without 
    
                                                          discovery. 
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to 
    
                                                          the wrong
                                                          endpoint? 
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably 
    
                                                          doesn’t need
                                                          discovery. 
    
                                                          
    
                                                          We agree 
    
                                                          
    
                                                          
    
                                                          
    One

                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find 
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating 
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives 
    
                                                          what the
                                                          resource is. 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not 
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service. 
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have 
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. 
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process. 
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production. 
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. 
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn’t
                                                          know all the 
    
                                                          possible RS.  
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can 
    
                                                          address. 
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them. 
    
                                                          
    
                                                          
    There

                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS 
    
                                                          endpoints
                                                          intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In

                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request 
    
                                                          for each
                                                          endpoint. 
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS 
    
                                                          servers
                                                          assigned to
                                                          each instance? 
    
                                                          
    Those

                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner 
    
                                                          are.  I think
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. 
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints. 
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a 
    
                                                          client chooses evil.com <http://evil.com/> the
                                                          cert can be
                                                          valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to 
    
                                                          res.example.com <http://res.example.com/>? 
    
                                                          

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


--------------050807060703050300010408--


From nobody Wed Mar 16 08:57:45 2016
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 3EB5012D78A for ; Wed, 16 Mar 2016 08:57:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 iJ6sHBifuxEV for ; Wed, 16 Mar 2016 08:57:42 -0700 (PDT)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB60E12D532 for ; Wed, 16 Mar 2016 08:57:41 -0700 (PDT)
Received: from mtaout-aal02.mx.aol.com (mtaout-aal02.mx.aol.com [172.27.20.206]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 07E0438000E7 for ; Wed, 16 Mar 2016 11:57:41 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aal02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7FB6838000088 for ; Wed, 16 Mar 2016 11:57:40 -0400 (EDT)
To: "oauth@ietf.org" 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E98274.10002@aol.com>
Date: Wed, 16 Mar 2016 11:57:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------030500060500020502010300"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458143860; bh=DnUXFT//iJ0CDLwTS4OtowMbYrZomm+s9BIDxbEIVC4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ieK/9ic4OUsij5kVdoWY6tCVpoz+OA+9qdk815qddpEBh1oLFWB2a10JHHehieKRU 4yt36jFPX+AkwrIzwHTt68IFvw3oSijedTHoOuHM+KET4dxYCk3qSwiDOFzbaqPJzl ymBOTNYlY5VREDlyLYwt5pJp/rkqiZtasDnGcXLU=
x-aol-sid: 3039ac1b14ce56e982746d1a
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 15:57:43 -0000

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

So, in thinking about all this AS restricting tokens to RS and 
"discovery" of RS endpoints, etc. I wondered why we don't just leverage 
RS metadata like we have AS metadata.

For an AS we require an 'iss' claim to use as an identifier of the AS. 
We could do the same with RS metadata retrieving the metadata from a 
.well-known location and including a claim of 'rsid' to use as an 
identifier of the Resource Server.

This 'rsid' identifier could then be used for registration with the AS 
and presentation by the client when requesting tokens.

This provides a separation between an identifier for a resource and the 
specific endpoints the token will be sent to. A client could "discover" 
the necessary endpoint on a periodic basis and use a single identifier 
with the AS for any of the endpoints or scopes supported by the RS. If 
desired the RS could expose the supported scopes in the RS metadata file.

Thoughts?

Thanks,
George

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


  

    
  
  
    So, in thinking about all
      this AS restricting tokens to RS and "discovery" of RS endpoints,
      etc. I wondered why we don't just leverage RS metadata like we
      have AS metadata.
    
      
    
      For an AS we require an 'iss' claim to use as an identifier of the
      AS. We could do the same with RS metadata retrieving the metadata
      from a .well-known location and including a claim of 'rsid' to use
      as an identifier of the Resource Server.
    
      
    
      This 'rsid' identifier could then be used for registration with
      the AS and presentation by the client when requesting tokens.
    
      
    
      This provides a separation between an identifier for a resource
      and the specific endpoints the token will be sent to. A client
      could "discover" the necessary endpoint on a periodic basis and
      use a single identifier with the AS for any of the endpoints or
      scopes supported by the RS. If desired the RS could expose the
      supported scopes in the RS metadata file.
    
      
    
      Thoughts?
    
      
    
      Thanks,
    
      George
    
  


--------------030500060500020502010300--


From nobody Wed Mar 16 09:20:37 2016
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 9F77D12D9CE for ; Wed, 16 Mar 2016 09:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 4d8SWCjwg-F9 for ; Wed, 16 Mar 2016 09:20:34 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 8829312D9F6 for ; Wed, 16 Mar 2016 09:20:30 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2GGKPBt000855 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 16 Mar 2016 16:20:25 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2GGKPVR030447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 16 Mar 2016 16:20:25 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2GGKOfb008952; Wed, 16 Mar 2016 16:20:24 GMT
Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Mar 2016 09:20:24 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-337655A9-9E8E-4C3F-A685-DBE133B51201
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: <56E98274.10002@aol.com>
Date: Wed, 16 Mar 2016 09:20:22 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com>
References: <56E98274.10002@aol.com>
To: George Fletcher 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 16:20:35 -0000

--Apple-Mail-337655A9-9E8E-4C3F-A685-DBE133B51201
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

George

Very good question...

I considered that the RS metadata discovery could be fake.=20

So the final step in configuration validation is to bind the relationship be=
tween as and rs discovery together to confirm the relationship is valid.=20

We are of course assuming that a hacker needs to use the real AS authorize e=
ndpoint to succeed in obtaining an access token(it can't be mitm'd). Once th=
e grant is obtained by the client, the threat comes when the client uses the=
 grant at a mitm'd token endpoint OR an access token at a mitm'd resource en=
dpoint.=20

So the AS and its config set becomes the trust anchor. Binding allows us to e=
xtend trust to the RS discovery giving some assurance that a client has a co=
rrect set of endpoints including resource.=20

John's solution requires translating aud to res url and changes to core oaut=
h. He seems to imply there is a need for ongoing validation of resource. I'm=
 not yet convinced that is really needed.  Maybe it is needed because the cl=
ient could be convinced to follow a link embedded in a resource that is some=
how not part of the defined audience?

Thanks

Phil

> On Mar 16, 2016, at 08:57, George Fletcher  wrote:
>=20
> So, in thinking about all this AS restricting tokens to RS and "discovery"=
 of RS endpoints, etc. I wondered why we don't just leverage RS metadata lik=
e we have AS metadata.
>=20
> For an AS we require an 'iss' claim to use as an identifier of the AS. We c=
ould do the same with RS metadata retrieving the metadata from a .well-known=
 location and including a claim of 'rsid' to use as an identifier of the Res=
ource Server.
>=20
> This 'rsid' identifier could then be used for registration with the AS and=
 presentation by the client when requesting tokens.
>=20
> This provides a separation between an identifier for a resource and the sp=
ecific endpoints the token will be sent to. A client could "discover" the ne=
cessary endpoint on a periodic basis and use a single identifier with the AS=
 for any of the endpoints or scopes supported by the RS. If desired the RS c=
ould expose the supported scopes in the RS metadata file.
>=20
> Thoughts?
>=20
> Thanks,
> George
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-337655A9-9E8E-4C3F-A685-DBE133B51201
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    George

    Very good question...

    I consi=
dered that the RS metadata discovery could be fake. 

    So the final step=
 in configuration validation is to bind the relationship between as and rs d=
iscovery together to confirm the relationship is valid. 

    We are of cour=
se assuming that a hacker needs to use the real AS authorize endpoint to suc=
ceed in obtaining an access token(it can't be mitm'd). Once the grant is obt=
ained by the client, the threat comes when the client uses the grant at a mi=
tm'd token endpoint OR an access token at a mitm'd resource endpoint. <=
/div>

    So the AS and its config set becomes the trust anchor. Binding allows us to=
 extend trust to the RS discovery giving some assurance that a client has a c=
orrect set of endpoints including resource. 

    John's solution requires t=
ranslating aud to res url and changes to core oauth. He seems to imply there=
 is a need for ongoing validation of resource. I'm not yet convinced that is=
 really needed.  Maybe it is needed because the client could be convinc=
ed to follow a link embedded in a resource that is somehow not part of the d=
efined audience?

    Thanks

    Phil

    On Mar 16, 2016, at 08:57=
, George Fletcher <gffletch@aol.com> wrote:

    
 =20

    
 =20
 =20
    So, in thinking about all
      this AS restricting tokens to RS and "discovery" of RS endpoints,
      etc. I wondered why we don't just leverage RS metadata like we
      have AS metadata.
    
      
    
      For an AS we require an 'iss' claim to use as an identifier of the
      AS. We could do the same with RS metadata retrieving the metadata
      from a .well-known location and including a claim of 'rsid' to use
      as an identifier of the Resource Server.
    
      
    
      This 'rsid' identifier could then be used for registration with
      the AS and presentation by the client when requesting tokens.
    
      
    
      This provides a separation between an identifier for a resource
      and the specific endpoints the token will be sent to. A client
      could "discover" the necessary endpoint on a periodic basis and
      use a single identifier with the AS for any of the endpoints or
      scopes supported by the RS. If desired the RS could expose the
      supported scopes in the RS metadata file.
    
      
    
      Thoughts?
    
      
    
      Thanks,
    
      George
    
 =20


    =

--Apple-Mail-337655A9-9E8E-4C3F-A685-DBE133B51201--


From nobody Wed Mar 16 10:59:53 2016
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 7A25E12DA43 for ; Wed, 16 Mar 2016 10:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 A1wZDWW16787 for ; Wed, 16 Mar 2016 10:59:50 -0700 (PDT)
Received: from omr-a010e.mx.aol.com (omr-a010e.mx.aol.com [204.29.186.54]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8F612D663 for ; Wed, 16 Mar 2016 10:59:30 -0700 (PDT)
Received: from mtaout-aaj02.mx.aol.com (mtaout-aaj02.mx.aol.com [172.27.3.206]) by omr-a010e.mx.aol.com (Outbound Mail Relay) with ESMTP id D1F6B38000B9; Wed, 16 Mar 2016 13:59:29 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaj02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 597C53800009A; Wed, 16 Mar 2016 13:59:29 -0400 (EDT)
To: "Phil Hunt (IDM)" 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E99F01.5020002@aol.com>
Date: Wed, 16 Mar 2016 13:59:29 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com>
Content-Type: multipart/alternative; boundary="------------050900070503010705020006"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458151169; bh=IbQAgqj/Ve9ht9ELZl6hGql116yyYmnQzPni4QMkSUA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=BqUnDG/kAFh8hhVq+2GBnOnYJ6siXhXgaod5WWb3eYdUfsXTubnzv4qa0eDmY5mOH eJmyQz4zrtm8Wxdyt3iftfcsJaBDiHNRhql5WNTzPqvFTR51pGzGgy6gYtjYv9zkhO mrsuaMRAXE4Oa7+8HkDlc3+oQmLQk5jYm0GrH2Yc=
x-aol-sid: 3039ac1b03ce56e99f0103d0
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 17:59:52 -0000

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



On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
> George
>
> Very good question...
>
> I considered that the RS metadata discovery could be fake.
Same way that the 'iss' claim must "match" the url used to retrieve the 
metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't 
be spoofed by another site
>
> So the final step in configuration validation is to bind the 
> relationship between as and rs discovery together to confirm the 
> relationship is valid.
And what I'd like to see is the 'rsid' value used to represent the RS 
rather than some unique endpoint (even if wildcards are allowed)

Another step that may be required is for the RS to return it's 'rsid' in 
the realm field of the WWW-Authenticate response header. This allows a 
client to discover metadata about the RS and it's endpoints. It also 
allows the client to determine if the 'rsid' returned by the RS matches 
the 'rsid' it is expecting.
>
> We are of course assuming that a hacker needs to use the real AS 
> authorize endpoint to succeed in obtaining an access token(it can't be 
> mitm'd). Once the grant is obtained by the client, the threat comes 
> when the client uses the grant at a mitm'd token endpoint OR an access 
> token at a mitm'd resource endpoint.
>
> So the AS and its config set becomes the trust anchor. Binding allows 
> us to extend trust to the RS discovery giving some assurance that a 
> client has a correct set of endpoints including resource.
Are you recommending that the AS metadata provide a list of the 'rsid' 
supported by the AS?
>
> John's solution requires translating aud to res url and changes to 
> core oauth. He seems to imply there is a need for ongoing validation 
> of resource. I'm not yet convinced that is really needed.  Maybe it is 
> needed because the client could be convinced to follow a link embedded 
> in a resource that is somehow not part of the defined audience?
>
> Thanks
>
> Phil
>
> On Mar 16, 2016, at 08:57, George Fletcher  > wrote:
>
>> So, in thinking about all this AS restricting tokens to RS and 
>> "discovery" of RS endpoints, etc. I wondered why we don't just 
>> leverage RS metadata like we have AS metadata.
>>
>> For an AS we require an 'iss' claim to use as an identifier of the 
>> AS. We could do the same with RS metadata retrieving the metadata 
>> from a .well-known location and including a claim of 'rsid' to use as 
>> an identifier of the Resource Server.
>>
>> This 'rsid' identifier could then be used for registration with the 
>> AS and presentation by the client when requesting tokens.
>>
>> This provides a separation between an identifier for a resource and 
>> the specific endpoints the token will be sent to. A client could 
>> "discover" the necessary endpoint on a periodic basis and use a 
>> single identifier with the AS for any of the endpoints or scopes 
>> supported by the RS. If desired the RS could expose the supported 
>> scopes in the RS metadata file.
>>
>> Thoughts?
>>
>> Thanks,
>> George
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    
    
    
    
    
    On 3/16/16 12:20 PM, Phil Hunt (IDM)
      wrote:
    
    
    
    
    
      
      
    George
    
      

    
      
    
      
    Very good question...
    
      

    
      
    
      
    I considered that the RS metadata
        discovery could be fake. 
    
      
    
    
    
    Same way that the 'iss'
      claim must "match" the url used to retrieve the metadata would
      apply to the 'rsid' claim
    
      -- I think that should suffice to ensuring the 'rsid' identifier
      can't be spoofed by another site
    
        
    
    
      

    
      
    
      
    So the final step in configuration
        validation is to bind the relationship between as and rs
        discovery together to confirm the relationship is valid. 
    
      
    
    
    
    And what I'd like to see is the 'rsid' value used to represent the
    RS rather than some unique endpoint (even if wildcards are allowed)
    
    
    
    Another step that may be required is for the RS to return it's
    'rsid' in the realm field of the WWW-Authenticate response header.
    This allows a client to discover metadata about the RS and it's
    endpoints. It also allows the client to determine if the 'rsid'
    returned by the RS matches the 'rsid' it is expecting.
    
    
    
      

    
      
    
      
    We are of course assuming that a
        hacker needs to use the real AS authorize endpoint to succeed in
        obtaining an access token(it can't be mitm'd). Once the grant is
        obtained by the client, the threat comes when the client uses
        the grant at a mitm'd token endpoint OR an access token at a
        mitm'd resource endpoint. 
    
      

    
      
    
      
    So the AS and its config set becomes
        the trust anchor. Binding allows us to extend trust to the RS
        discovery giving some assurance that a client has a correct set
        of endpoints including resource. 
    
      
    
    
    
    Are you recommending that the AS metadata provide a list of the
    'rsid' supported by the AS?
    
    
    
      

    
      
    
      
    John's solution requires translating
        aud to res url and changes to core oauth. He seems to imply
        there is a need for ongoing validation of resource. I'm not yet
        convinced that is really needed.  Maybe it is needed because the
        client could be convinced to follow a link embedded in a
        resource that is somehow not part of the defined audience?
    
      

    
      
    
      
    Thanks
    
        
    
        Phil
    
      

    
        On Mar 16, 2016, at 08:57, George Fletcher <gffletch@aol.com>
        wrote:
    
        
    
      
    
      
    
        
    
          
          So, in thinking
            about all this AS restricting tokens to RS and "discovery"
            of RS endpoints, etc. I wondered why we don't just leverage
            RS metadata like we have AS metadata.
    
            
    
            For an AS we require an 'iss' claim to use as an identifier
            of the AS. We could do the same with RS metadata retrieving
            the metadata from a .well-known location and including a
            claim of 'rsid' to use as an identifier of the Resource
            Server.
    
            
    
            This 'rsid' identifier could then be used for registration
            with the AS and presentation by the client when requesting
            tokens.
    
            
    
            This provides a separation between an identifier for a
            resource and the specific endpoints the token will be sent
            to. A client could "discover" the necessary endpoint on a
            periodic basis and use a single identifier with the AS for
            any of the endpoints or scopes supported by the RS. If
            desired the RS could expose the supported scopes in the RS
            metadata file.
    
            
    
            Thoughts?
    
            
    
            Thanks,
    
            George
    
        
    
      
    
      
    
        
    _______________________________________________
    
          OAuth mailing list
    
          OAuth@ietf.org
    
          https://www.ietf.org/mailman/listinfo/oauth
    
        
    
      
    
    
    
    
    
    
    -- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

    
  


--------------050900070503010705020006--


From nobody Wed Mar 16 11:16:27 2016
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 C24B412D61D for ; Wed, 16 Mar 2016 11:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 UwJ_l0OVq5rZ for ; Wed, 16 Mar 2016 11:16:23 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 7469912D616 for ; Wed, 16 Mar 2016 11:16:21 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2GIGHPl014641 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2016 18:16:17 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2GIGHCc000729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 18:16:17 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2GIGG6T015174; Wed, 16 Mar 2016 18:16:16 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Mar 2016 11:16:16 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_731E265B-06B9-4094-8CAD-5C4557DD1519"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <56E99F01.5020002@aol.com>
Date: Wed, 16 Mar 2016 11:16:14 -0700
Message-Id: <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com>
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 18:16:26 -0000

--Apple-Mail=_731E265B-06B9-4094-8CAD-5C4557DD1519
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 16, 2016, at 10:59 AM, George Fletcher  =
wrote:
>=20
>=20
>=20
> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>> George
>>=20
>> Very good question...
>>=20
>> I considered that the RS metadata discovery could be fake.=20
> Same way that the 'iss' claim must "match" the url used to retrieve =
the metadata would apply to the 'rsid' claim
> -- I think that should suffice to ensuring the 'rsid' identifier can't =
be spoofed by another site

So the attacker makes iss and url match for the resource discovery. Yet =
the AS service provider doesn=E2=80=99t know where the client is using =
the tokens.  How would the client or the AS detect that the wrong iss =
was given?

>>=20
>> So the final step in configuration validation is to bind the =
relationship between as and rs discovery together to confirm the =
relationship is valid.=20
> And what I'd like to see is the 'rsid' value used to represent the RS =
rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue RSID =
values in the works?

That said, I would have thought this is more ownerous than checking =
*.example.com matches the given URL by the client.
>=20
> Another step that may be required is for the RS to return it's 'rsid' =
in the realm field of the WWW-Authenticate response header. This allows =
a client to discover metadata about the RS and it's endpoints. It also =
allows the client to determine if the 'rsid' returned by the RS matches =
the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks =
for the configuration metadata or when the client asks for tokens?  I =
think it only needs to happen at config time.
>>=20
>> We are of course assuming that a hacker needs to use the real AS =
authorize endpoint to succeed in obtaining an access token(it can't be =
mitm'd). Once the grant is obtained by the client, the threat comes when =
the client uses the grant at a mitm'd token endpoint OR an access token =
at a mitm'd resource endpoint.=20
>>=20
>> So the AS and its config set becomes the trust anchor. Binding allows =
us to extend trust to the RS discovery giving some assurance that a =
client has a correct set of endpoints including resource.=20
> Are you recommending that the AS metadata provide a list of the 'rsid' =
supported by the AS?
No.  I think that is a bad idea.  Better to use an identity oracle =
function and say, give me the config for rsid=3Dxyz

That also allows a common AS discovery endpoint to actually do discovery =
for multiple AS systems.  E.g. to configure a client to a specific AS =
service designated by the customer paying for the resource service. =20

IOW. by providing a resource query, the meta-data config discovery =
actually looks more like discovery.  :-)
>>=20
>> John's solution requires translating aud to res url and changes to =
core oauth. He seems to imply there is a need for ongoing validation of =
resource. I'm not yet convinced that is really needed.  Maybe it is =
needed because the client could be convinced to follow a link embedded =
in a resource that is somehow not part of the defined audience?
>>=20
>> Thanks
>>=20
>> Phil
>>=20
>> On Mar 16, 2016, at 08:57, George Fletcher < =
gffletch@aol.com > =
wrote:
>>=20
>>> So, in thinking about all this AS restricting tokens to RS and =
"discovery" of RS endpoints, etc. I wondered why we don't just leverage =
RS metadata like we have AS metadata.
>>>=20
>>> For an AS we require an 'iss' claim to use as an identifier of the =
AS. We could do the same with RS metadata retrieving the metadata from a =
.well-known location and including a claim of 'rsid' to use as an =
identifier of the Resource Server.
>>>=20
>>> This 'rsid' identifier could then be used for registration with the =
AS and presentation by the client when requesting tokens.
>>>=20
>>> This provides a separation between an identifier for a resource and =
the specific endpoints the token will be sent to. A client could =
"discover" the necessary endpoint on a periodic basis and use a single =
identifier with the AS for any of the endpoints or scopes supported by =
the RS. If desired the RS could expose the supported scopes in the RS =
metadata file.
>>>=20
>>> Thoughts?
>>>=20
>>> Thanks,
>>> George
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 


--Apple-Mail=_731E265B-06B9-4094-8CAD-5C4557DD1519
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


    


    

    

    On Mar 16, 2016, at 10:59 AM, George Fletcher <gffletch@aol.com> =
wrote:



    On 3/16/16 12:20 PM, Phil Hunt =
(IDM) wrote:
    George

    Very good question...

    I considered that the RS =
metadata discovery could be fake. 
    Same way that the =
'iss' claim must "match" the url used to retrieve the metadata would =
apply to the 'rsid' claim
    -- I think that should suffice =
to ensuring the 'rsid' identifier can't be spoofed by another site

    So the =
attacker makes iss and url match for the resource discovery. Yet the AS =
service provider doesn=E2=80=99t know where the client is using the =
tokens.  How would the client or the AS detect that the wrong iss =
was given?


    So the =
final step in configuration validation is to bind the relationship =
between as and rs discovery together to confirm the relationship is =
valid. 
    And what I'd like to see is the 'rsid' value =
used to represent the RS rather than some unique endpoint (even if =
wildcards are allowed)

    Long term, I =
think this would be better. Do we have a way to issue RSID values in the =
works?

    That said, I would have =
thought this is more ownerous than checking *.example.com matches the given =
URL by the client.

    Another step that may be required is for the RS =
to return it's 'rsid' in the realm field of the WWW-Authenticate =
response header. This allows a client to discover metadata about the RS =
and it's endpoints. It also allows the client to determine if the 'rsid' =
returned by the RS matches the 'rsid' it is expecting.

    Agreed. This =
might work. But should the check be when the client asks for the =
configuration metadata or when the client asks for tokens?  I think =
it only needs to happen at config time.

    We are =
of course assuming that a hacker needs to use the real AS authorize =
endpoint to succeed in obtaining an access token(it can't be mitm'd). =
Once the grant is obtained by the client, the threat comes when the =
client uses the grant at a mitm'd token endpoint OR an access token at a =
mitm'd resource endpoint. 

    So the AS and its config set becomes =
the trust anchor. Binding allows us to extend trust to the RS discovery =
giving some assurance that a client has a correct set of endpoints =
including resource. 
    Are you recommending that the AS metadata =
provide a list of the 'rsid' supported by the AS?
    No.  I think that is a bad idea. =
 Better to use an identity oracle function and say, give me the =
config for rsid=3Dxyz

    That also =
allows a common AS discovery endpoint to actually do discovery for =
multiple AS systems.  E.g. to configure a client to a specific AS =
service designated by the customer paying for the resource service. =
 

    IOW. by providing a resource =
query, the meta-data config discovery actually looks more like =
discovery.  :-)

    John's =
solution requires translating aud to res url and changes to core oauth. =
He seems to imply there is a need for ongoing validation of resource. =
I'm not yet convinced that is really needed.  Maybe it is needed =
because the client could be convinced to follow a link embedded in a =
resource that is somehow not part of the defined audience?

    Thanks

    Phil

    On Mar 16, 2016, at =
08:57, George Fletcher <gffletch@aol.com> wrote:

    So, in =
thinking about all this AS restricting tokens to RS and "discovery" of =
RS endpoints, etc. I wondered why we don't just leverage RS metadata =
like we have AS metadata.

    For an AS we =
require an 'iss' claim to use as an identifier of the AS. We could do =
the same with RS metadata retrieving the metadata from a .well-known =
location and including a claim of 'rsid' to use as an identifier of the =
Resource Server.

    This 'rsid' identifier =
could then be used for registration with the AS and presentation by the =
client when requesting tokens.

    This =
provides a separation between an identifier for a resource and the =
specific endpoints the token will be sent to. A client could "discover" =
the necessary endpoint on a periodic basis and use a single identifier =
with the AS for any of the endpoints or scopes supported by the RS. If =
desired the RS could expose the supported scopes in the RS metadata =
file.

    Thoughts?

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

    --=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


    =

--Apple-Mail=_731E265B-06B9-4094-8CAD-5C4557DD1519--


From nobody Wed Mar 16 11:29:16 2016
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 551EA12DA08 for ; Wed, 16 Mar 2016 11:29:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 kCxkcnfNqtyH for ; Wed, 16 Mar 2016 11:29:12 -0700 (PDT)
Received: from omr-m019e.mx.aol.com (omr-m019e.mx.aol.com [204.29.186.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003AF12D643 for ; Wed, 16 Mar 2016 11:29:11 -0700 (PDT)
Received: from mtaout-aak01.mx.aol.com (mtaout-aak01.mx.aol.com [172.27.2.225]) by omr-m019e.mx.aol.com (Outbound Mail Relay) with ESMTP id 406F03800089; Wed, 16 Mar 2016 14:29:11 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aak01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7776438000090; Wed, 16 Mar 2016 14:29:10 -0400 (EDT)
To: Phil Hunt 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56E9A5F6.2010405@aol.com>
Date: Wed, 16 Mar 2016 14:29:10 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com>
Content-Type: multipart/alternative; boundary="------------020908010005090806090206"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458152951; bh=JSob5JmVFrlR9zMQYHPox2ETXgUbTIHwbrNjmx/HydI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=eDtYJJuyn9JLRqbYxdHS07Mdcq0gBOOrhse48Ln/kNr4URhX4dtwuCM7Nv/6NxXdC VStAzIwheMTbVqiZyomc8yQx6bWvqTVy+0IZj0BgE3cgELUjtsEcKglg0zDOK/v7nj yxWg7+kPe4YDatiUIshZrEbttsenLJOy500jpiSo=
x-aol-sid: 3039ac1b02e156e9a5f64240
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 18:29:15 -0000

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

Inline...

On 3/16/16 2:16 PM, Phil Hunt wrote:
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Mar 16, 2016, at 10:59 AM, George Fletcher > > wrote:
>>
>>
>>
>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>> George
>>>
>>> Very good question...
>>>
>>> I considered that the RS metadata discovery could be fake.
>> Same way that the 'iss' claim must "match" the url used to retrieve 
>> the metadata would apply to the 'rsid' claim
>> -- I think that should suffice to ensuring the 'rsid' identifier 
>> can't be spoofed by another site
>
> So the attacker makes iss and url match for the resource discovery. 
> Yet the AS service provider doesn’t know where the client is using the 
> tokens.  How would the client or the AS detect that the wrong iss was 
> given?
Because if the attacker makes the rsid and the url match, then the 
client will submit an rsid that isn't "registered" with the AS and the 
AS won't issue the token. This assumes the client is not talking to an 
evil AS (as there are other mitigations for that case).
>
>>>
>>> So the final step in configuration validation is to bind the 
>>> relationship between as and rs discovery together to confirm the 
>>> relationship is valid.
>> And what I'd like to see is the 'rsid' value used to represent the RS 
>> rather than some unique endpoint (even if wildcards are allowed)
>
> Long term, I think this would be better. Do we have a way to issue 
> RSID values in the works?
No, but that is what this email thread is contemplating:) Just as the AS 
iss value is selfdefined by the AS, the rsid should be selfdefined by 
the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how 
the AS 'iss' claim is defined for the AS in it's metadata.
>
> That said, I would have thought this is more ownerous than checking 
> *.example.com  matches the given URL by the client.
My problem with the URL level checking is that a RS may legitimately 
have endpoints on multiple domains. An RS may move endpoints from one 
domain to another (say when moving from version 1 to version 2 of an 
API). Using the rsid for audience restriction and as an indirect 
mechanism for specifying actual endpoints, the RS has a much looser 
coupling with the AS.

AS we move into "federated authorization" meaning that an RS outsources 
it's API authorization to one or more AS's, this will become more important.
>>
>> Another step that may be required is for the RS to return it's 'rsid' 
>> in the realm field of the WWW-Authenticate response header. This 
>> allows a client to discover metadata about the RS and it's endpoints. 
>> It also allows the client to determine if the 'rsid' returned by the 
>> RS matches the 'rsid' it is expecting.
>
> Agreed. This might work. But should the check be when the client asks 
> for the configuration metadata or when the client asks for tokens?  I 
> think it only needs to happen at config time.
What I see here is that the desire is to audience protect tokens. To do 
that, the audience need to be specified everytime a token is requested. 
I really don't the AS to have to manage the complex state of which 
audiences have previously been issued to refresh_tokens and then 
reconstruct the correct audience for a requested downscoped 
access_token. It's much simpler, since the client knows which RS it's 
going to send the token to, to provide that when requesting tokens.

The complication comes when exchanging the code for the tokens, it needs 
to specify all possible audiences (rsid's) it might send the token to 
based on the requested scopes. There will be a fair amount of complex 
logic at the AS to ensure the correct behavior. I do worry about this 
complexity.
>>>
>>> We are of course assuming that a hacker needs to use the real AS 
>>> authorize endpoint to succeed in obtaining an access token(it can't 
>>> be mitm'd). Once the grant is obtained by the client, the threat 
>>> comes when the client uses the grant at a mitm'd token endpoint OR 
>>> an access token at a mitm'd resource endpoint.
>>>
>>> So the AS and its config set becomes the trust anchor. Binding 
>>> allows us to extend trust to the RS discovery giving some assurance 
>>> that a client has a correct set of endpoints including resource.
>> Are you recommending that the AS metadata provide a list of the 
>> 'rsid' supported by the AS?
> No.  I think that is a bad idea.  Better to use an identity oracle 
> function and say, give me the config for rsid=xyz
Good :)
>
> That also allows a common AS discovery endpoint to actually do 
> discovery for multiple AS systems.  E.g. to configure a client to a 
> specific AS service designated by the customer paying for the resource 
> service.
>
> IOW. by providing a resource query, the meta-data config discovery 
> actually looks more like discovery.  :-)
>>>
>>> John's solution requires translating aud to res url and changes to 
>>> core oauth. He seems to imply there is a need for ongoing validation 
>>> of resource. I'm not yet convinced that is really needed.  Maybe it 
>>> is needed because the client could be convinced to follow a link 
>>> embedded in a resource that is somehow not part of the defined audience?
>>>
>>> Thanks
>>>
>>> Phil
>>>
>>> On Mar 16, 2016, at 08:57, George Fletcher  wrote:
>>>
>>>> So, in thinking about all this AS restricting tokens to RS and 
>>>> "discovery" of RS endpoints, etc. I wondered why we don't just 
>>>> leverage RS metadata like we have AS metadata.
>>>>
>>>> For an AS we require an 'iss' claim to use as an identifier of the 
>>>> AS. We could do the same with RS metadata retrieving the metadata 
>>>> from a .well-known location and including a claim of 'rsid' to use 
>>>> as an identifier of the Resource Server.
>>>>
>>>> This 'rsid' identifier could then be used for registration with the 
>>>> AS and presentation by the client when requesting tokens.
>>>>
>>>> This provides a separation between an identifier for a resource and 
>>>> the specific endpoints the token will be sent to. A client could 
>>>> "discover" the necessary endpoint on a periodic basis and use a 
>>>> single identifier with the AS for any of the endpoints or scopes 
>>>> supported by the RS. If desired the RS could expose the supported 
>>>> scopes in the RS metadata file.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> George
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Inline...
    
    
    
    
    On 3/16/16 2:16 PM, Phil Hunt wrote:
    
    
    
    
    
      
      
    
      
      
    
      
    
        
    
          
    On Mar 16, 2016, at 10:59 AM, George Fletcher
            <gffletch@aol.com> wrote:
    
          
    
          

    
            
    
            
    On 3/16/16 12:20 PM, Phil Hunt (IDM)
              wrote:
    
            
    
            
    
              
    George
    
              

    
              
    
              
    Very good question...
    
              

    
              
    
              
    I considered that the RS metadata discovery
                could be fake. 
    
              
    
            
    
            Same way that the
              'iss' claim must "match" the url used to retrieve the
              metadata would apply to the 'rsid' claim
    
              -- I think that should suffice to ensuring the 'rsid'
              identifier can't be spoofed by another site
    
            
    
        
    
        

    
        
    
        So the attacker makes iss and url match for the resource
        discovery. Yet the AS service provider doesn’t know where the
        client is using the tokens.  How would the client or the AS
        detect that the wrong iss was given?
    
    
    
    Because if the attacker makes the rsid and the url match, then the
    client will submit an rsid that isn't "registered" with the AS and
    the AS won't issue the token. This assumes the client is not talking
    to an evil AS (as there are other mitigations for that case).
    
    
    
      

    
        
    
          
    
            
    
              

    
              
    
              
    So the final step in configuration
                validation is to bind the relationship between as and rs
                discovery together to confirm the relationship is valid. 
    
              
    
            
    
            And what I'd like to see is the 'rsid' value used
              to represent the RS rather than some unique endpoint (even
              if wildcards are allowed)
    
          
    
        
    
        

    
        
    
        Long term, I think this would be better. Do we have a way to
        issue RSID values in the works?
    
    
    
    No, but that is what this email thread is contemplating:) Just as
    the AS iss value is selfdefined by the AS, the rsid should be
    selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
    is a mirror of how the AS 'iss' claim is defined for the AS in it's
    metadata.
    
    
    
      

    
      
    
      
    That said, I would have thought this is more ownerous than
        checking *.example.com matches the given URL by the client.
    
      
    
    
    
    My problem with the URL level checking is that a RS may legitimately
    have endpoints on multiple domains. An RS may move endpoints from
    one domain to another (say when moving from version 1 to version 2
    of an API). Using the rsid for audience restriction and as an
    indirect mechanism for specifying actual endpoints, the RS has a
    much looser coupling with the AS.
    
    
    
    AS we move into "federated authorization" meaning that an RS
    outsources it's API authorization to one or more AS's, this will
    become more important.
    
    
    
      
    
        
    
          

    
            Another step that may be required is for the RS
              to return it's 'rsid' in the realm field of the
              WWW-Authenticate response header. This allows a client to
              discover metadata about the RS and it's endpoints. It also
              allows the client to determine if the 'rsid' returned by
              the RS matches the 'rsid' it is expecting.
    
          
    
        
    
        

    
        
    
        Agreed. This might work. But should the check be when the client
        asks for the configuration metadata or when the client asks for
        tokens?  I think it only needs to happen at config time.
    
      
    
    
    
    What I see here is that the desire is to audience protect tokens. To
    do that, the audience need to be specified everytime a token is
    requested. I really don't the AS to have to manage the complex state
    of which audiences have previously been issued to refresh_tokens and
    then reconstruct the correct audience for a requested downscoped
    access_token. It's much simpler, since the client knows which RS
    it's going to send the token to, to provide that when requesting
    tokens.
    
    
    
    The complication comes when exchanging the code for the tokens, it
    needs to specify all possible audiences (rsid's) it might send the
    token to based on the requested scopes. There will be a fair amount
    of complex logic at the AS to ensure the correct behavior. I do
    worry about this complexity.
    
    
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    We are of course assuming that a hacker
                needs to use the real AS authorize endpoint to succeed
                in obtaining an access token(it can't be mitm'd). Once
                the grant is obtained by the client, the threat comes
                when the client uses the grant at a mitm'd token
                endpoint OR an access token at a mitm'd resource
                endpoint. 
    
              

    
              
    
              
    So the AS and its config set becomes the
                trust anchor. Binding allows us to extend trust to the
                RS discovery giving some assurance that a client has a
                correct set of endpoints including resource. 
    
              
    
            
    
            Are you recommending that the AS metadata provide
              a list of the 'rsid' supported by the AS?
    
          
    
        
    
        No.  I think that is a bad idea.  Better to use an identity
        oracle function and say, give me the config for rsid=xyz
    
    
    
    Good :)
    
    
    
      

    
      
    
      
    That also allows a common AS discovery endpoint to actually
        do discovery for multiple AS systems.  E.g. to configure a
        client to a specific AS service designated by the customer
        paying for the resource service.  
    
      

    
      
    
      
    IOW. by providing a resource query, the meta-data config
        discovery actually looks more like discovery.  :-)
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    John's solution requires translating aud to
                res url and changes to core oauth. He seems to imply
                there is a need for ongoing validation of resource. I'm
                not yet convinced that is really needed.  Maybe it is
                needed because the client could be convinced to follow a
                link embedded in a resource that is somehow not part of
                the defined audience?
    
              

    
              
    
              
    Thanks
    
                
    
                Phil
    
              

    
                On Mar 16, 2016, at 08:57, George Fletcher <gffletch@aol.com>
                wrote:
    
                
    
              
    
              
    
                
    So, in thinking about all this AS
                    restricting tokens to RS and "discovery" of RS
                    endpoints, etc. I wondered why we don't just
                    leverage RS metadata like we have AS metadata.
    
                    
    
                    For an AS we require an 'iss' claim to use as an
                    identifier of the AS. We could do the same with RS
                    metadata retrieving the metadata from a .well-known
                    location and including a claim of 'rsid' to use as
                    an identifier of the Resource Server.
    
                    
    
                    This 'rsid' identifier could then be used for
                    registration with the AS and presentation by the
                    client when requesting tokens.
    
                    
    
                    This provides a separation between an identifier for
                    a resource and the specific endpoints the token will
                    be sent to. A client could "discover" the necessary
                    endpoint on a periodic basis and use a single
                    identifier with the AS for any of the endpoints or
                    scopes supported by the RS. If desired the RS could
                    expose the supported scopes in the RS metadata file.
    
                    
    
                    Thoughts?
    
                    
    
                    Thanks,
    
                    George
    
                
    
              
    
              
    
                
    _______________________________________________
    
                  OAuth mailing list
    
                  OAuth@ietf.org
    
                  https://www.ietf.org/mailman/listinfo/oauth
    
                
    
              
    
            
    
          
    
        
    
      
    
    
    
    
    
  


--------------020908010005090806090206--


From nobody Wed Mar 16 11:47:06 2016
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 CBE3112DA30 for ; Wed, 16 Mar 2016 11:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 uthtYaKDCkbN for ; Wed, 16 Mar 2016 11:47:03 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 2BBC512D5E7 for ; Wed, 16 Mar 2016 11:47:03 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2GIl0cY012811 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2016 18:47:01 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2GIl0VE019286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 18:47:00 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2GIkxwh002282; Wed, 16 Mar 2016 18:46:59 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Mar 2016 11:46:59 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_6A314786-DC30-43B1-A3B1-DF2F32EB462A"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <56E9A5F6.2010405@aol.com>
Date: Wed, 16 Mar 2016 11:46:57 -0700
Message-Id: <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com>
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 18:47:06 -0000

--Apple-Mail=_6A314786-DC30-43B1-A3B1-DF2F32EB462A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

George,

Thanks. It would be good to get a draft that sketches out the overall =
picture of this for BA =E2=80=94 even if in very rough form given the =
deadline is monday.  Or, maybe just a PPT walkthru.

Interested to see what comes out.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 16, 2016, at 11:29 AM, George Fletcher  =
wrote:
>=20
> Inline...
>=20
> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com =
phil.hunt@oracle.com =

>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 16, 2016, at 10:59 AM, George Fletcher > wrote:
>>>=20
>>>=20
>>>=20
>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>> George
>>>>=20
>>>> Very good question...
>>>>=20
>>>> I considered that the RS metadata discovery could be fake.=20
>>> Same way that the 'iss' claim must "match" the url used to retrieve =
the metadata would apply to the 'rsid' claim
>>> -- I think that should suffice to ensuring the 'rsid' identifier =
can't be spoofed by another site
>>=20
>> So the attacker makes iss and url match for the resource discovery. =
Yet the AS service provider doesn=E2=80=99t know where the client is =
using the tokens.  How would the client or the AS detect that the wrong =
iss was given?
> Because if the attacker makes the rsid and the url match, then the =
client will submit an rsid that isn't "registered" with the AS and the =
AS won't issue the token. This assumes the client is not talking to an =
evil AS (as there are other mitigations for that case).
>>=20
>>>>=20
>>>> So the final step in configuration validation is to bind the =
relationship between as and rs discovery together to confirm the =
relationship is valid.=20
>>> And what I'd like to see is the 'rsid' value used to represent the =
RS rather than some unique endpoint (even if wildcards are allowed)
>>=20
>> Long term, I think this would be better. Do we have a way to issue =
RSID values in the works?
> No, but that is what this email thread is contemplating:) Just as the =
AS iss value is selfdefined by the AS, the rsid should be selfdefined by =
the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how =
the AS 'iss' claim is defined for the AS in it's metadata.
>>=20
>> That said, I would have thought this is more ownerous than checking =
*.example.com  matches the given URL by the client.
> My problem with the URL level checking is that a RS may legitimately =
have endpoints on multiple domains. An RS may move endpoints from one =
domain to another (say when moving from version 1 to version 2 of an =
API). Using the rsid for audience restriction and as an indirect =
mechanism for specifying actual endpoints, the RS has a much looser =
coupling with the AS.
>=20
> AS we move into "federated authorization" meaning that an RS =
outsources it's API authorization to one or more AS's, this will become =
more important.
>>>=20
>>> Another step that may be required is for the RS to return it's =
'rsid' in the realm field of the WWW-Authenticate response header. This =
allows a client to discover metadata about the RS and it's endpoints. It =
also allows the client to determine if the 'rsid' returned by the RS =
matches the 'rsid' it is expecting.
>>=20
>> Agreed. This might work. But should the check be when the client asks =
for the configuration metadata or when the client asks for tokens?  I =
think it only needs to happen at config time.
> What I see here is that the desire is to audience protect tokens. To =
do that, the audience need to be specified everytime a token is =
requested. I really don't the AS to have to manage the complex state of =
which audiences have previously been issued to refresh_tokens and then =
reconstruct the correct audience for a requested downscoped =
access_token. It's much simpler, since the client knows which RS it's =
going to send the token to, to provide that when requesting tokens.
>=20
> The complication comes when exchanging the code for the tokens, it =
needs to specify all possible audiences (rsid's) it might send the token =
to based on the requested scopes. There will be a fair amount of complex =
logic at the AS to ensure the correct behavior. I do worry about this =
complexity.
>>>>=20
>>>> We are of course assuming that a hacker needs to use the real AS =
authorize endpoint to succeed in obtaining an access token(it can't be =
mitm'd). Once the grant is obtained by the client, the threat comes when =
the client uses the grant at a mitm'd token endpoint OR an access token =
at a mitm'd resource endpoint.=20
>>>>=20
>>>> So the AS and its config set becomes the trust anchor. Binding =
allows us to extend trust to the RS discovery giving some assurance that =
a client has a correct set of endpoints including resource.=20
>>> Are you recommending that the AS metadata provide a list of the =
'rsid' supported by the AS?
>> No.  I think that is a bad idea.  Better to use an identity oracle =
function and say, give me the config for rsid=3Dxyz
> Good :)
>>=20
>> That also allows a common AS discovery endpoint to actually do =
discovery for multiple AS systems.  E.g. to configure a client to a =
specific AS service designated by the customer paying for the resource =
service. =20
>>=20
>> IOW. by providing a resource query, the meta-data config discovery =
actually looks more like discovery.  :-)
>>>>=20
>>>> John's solution requires translating aud to res url and changes to =
core oauth. He seems to imply there is a need for ongoing validation of =
resource. I'm not yet convinced that is really needed.  Maybe it is =
needed because the client could be convinced to follow a link embedded =
in a resource that is somehow not part of the defined audience?
>>>>=20
>>>> Thanks
>>>>=20
>>>> Phil
>>>>=20
>>>> On Mar 16, 2016, at 08:57, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>=20
>>>>> So, in thinking about all this AS restricting tokens to RS and =
"discovery" of RS endpoints, etc. I wondered why we don't just leverage =
RS metadata like we have AS metadata.
>>>>>=20
>>>>> For an AS we require an 'iss' claim to use as an identifier of the =
AS. We could do the same with RS metadata retrieving the metadata from a =
.well-known location and including a claim of 'rsid' to use as an =
identifier of the Resource Server.
>>>>>=20
>>>>> This 'rsid' identifier could then be used for registration with =
the AS and presentation by the client when requesting tokens.
>>>>>=20
>>>>> This provides a separation between an identifier for a resource =
and the specific endpoints the token will be sent to. A client could =
"discover" the necessary endpoint on a periodic basis and use a single =
identifier with the AS for any of the endpoints or scopes supported by =
the RS. If desired the RS could expose the supported scopes in the RS =
metadata file.
>>>>>=20
>>>>> Thoughts?
>>>>>=20
>>>>> Thanks,
>>>>> George
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth =

>=20


--Apple-Mail=_6A314786-DC30-43B1-A3B1-DF2F32EB462A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

George,

    Thanks. It would be good to get a draft that sketches out the =
overall picture of this for BA =E2=80=94 even if in very rough form =
given the deadline is monday.  Or, maybe just a PPT =
walkthru.

    Interested to see what comes out.

    


    

    

    On Mar 16, 2016, at 11:29 AM, George Fletcher <gffletch@aol.com> =
wrote:

    
 =20
    
 =20
  
    
    Inline...
    
    
    
    
    On 3/16/16 2:16 PM, Phil Hunt =
wrote:
    
    
    
    
    
      
      
    
      
    
        
    
          
    
            
    
                
    
                  
    
                    
    
                      
    Phil
    
                      

    
                      
    
                      
    @independentid
    
                      
    www.independentid.com
    
                    
    
                  
    
                
    
                  phil.hunt@oracle.com
    
            

    
            
    
          
    
          
    
        
    
        
    
        
    
      
    
      
    
      
    
        
    
          
    On Mar 16, 2016, at 10:59 AM, George Fletcher
            <gffletch@aol.com> =
wrote:
    
          
    
          

    
            
    
            
    On 3/16/16 12:20 PM, Phil Hunt (IDM)
              wrote:
    
            
    
            
    
              
    George
    
              

    
              
    
              
    Very good question...
    
              

    
              
    
              
    I considered that the RS metadata =
discovery
                could be fake. 
    
              
    
            
    
            Same way that the
              'iss' claim must "match" the url used to retrieve the
              metadata would apply to the 'rsid' claim
    
              -- I think that should suffice to ensuring the 'rsid'
              identifier can't be spoofed by another site
    
            
    
        
    
        

    
        
    
        So the attacker makes iss and url match for the resource
        discovery. Yet the AS service provider doesn=E2=80=99t know =
where the
        client is using the tokens.  How would the client or the AS
        detect that the wrong iss was given?
    
    
    
    Because if the attacker makes the rsid and the url match, then the
    client will submit an rsid that isn't "registered" with the AS and
    the AS won't issue the token. This assumes the client is not talking
    to an evil AS (as there are other mitigations for that case).
    
    
    
      

    
        
    
          
    
            
    
              

    
              
    
              
    So the final step in configuration
                validation is to bind the relationship between as and rs
                discovery together to confirm the relationship is =
valid. 
    
              
    
            
    
            And what I'd like to see is the 'rsid' value used
              to represent the RS rather than some unique endpoint (even
              if wildcards are allowed)
    
          
    
        
    
        

    
        
    
        Long term, I think this would be better. Do we have a way to
        issue RSID values in the works?
    
    
    
    No, but that is what this email thread is contemplating:) Just as
    the AS iss value is selfdefined by the AS, the rsid should be
    selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
    is a mirror of how the AS 'iss' claim is defined for the AS in it's
    metadata.
    
    
    
      

    
      
    
      
    That said, I would have thought this is more =
ownerous than
        checking *.example.com matches the =
given URL by the client.
    
      
    
    
    
    My problem with the URL level checking is that a RS may legitimately
    have endpoints on multiple domains. An RS may move endpoints from
    one domain to another (say when moving from version 1 to version 2
    of an API). Using the rsid for audience restriction and as an
    indirect mechanism for specifying actual endpoints, the RS has a
    much looser coupling with the AS.
    
    
    
    AS we move into "federated authorization" meaning that an RS
    outsources it's API authorization to one or more AS's, this will
    become more important.
    
    
    
      
    
        
    
          

    
            Another step that may be required is for the RS
              to return it's 'rsid' in the realm field of the
              WWW-Authenticate response header. This allows a client to
              discover metadata about the RS and it's endpoints. It also
              allows the client to determine if the 'rsid' returned by
              the RS matches the 'rsid' it is expecting.
    
          
    
        
    
        

    
        
    
        Agreed. This might work. But should the check be when the client
        asks for the configuration metadata or when the client asks for
        tokens?  I think it only needs to happen at config time.
    
      
    
    
    
    What I see here is that the desire is to audience protect tokens. To
    do that, the audience need to be specified everytime a token is
    requested. I really don't the AS to have to manage the complex state
    of which audiences have previously been issued to refresh_tokens and
    then reconstruct the correct audience for a requested downscoped
    access_token. It's much simpler, since the client knows which RS
    it's going to send the token to, to provide that when requesting
    tokens.
    
    
    
    The complication comes when exchanging the code for the tokens, it
    needs to specify all possible audiences (rsid's) it might send the
    token to based on the requested scopes. There will be a fair amount
    of complex logic at the AS to ensure the correct behavior. I do
    worry about this complexity.
    
    
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    We are of course assuming that a hacker
                needs to use the real AS authorize endpoint to succeed
                in obtaining an access token(it can't be mitm'd). Once
                the grant is obtained by the client, the threat comes
                when the client uses the grant at a mitm'd token
                endpoint OR an access token at a mitm'd resource
                endpoint. 
    
              

    
              
    
              
    So the AS and its config set becomes the
                trust anchor. Binding allows us to extend trust to the
                RS discovery giving some assurance that a client has a
                correct set of endpoints including resource. 
    
              
    
            
    
            Are you recommending that the AS metadata provide
              a list of the 'rsid' supported by the AS?
    
          
    
        
    
        No.  I think that is a bad idea.  Better to use an =
identity
        oracle function and say, give me the config for rsid=3Dxyz
    
    
    
    Good :)
    
    
    
      

    
      
    
      
    That also allows a common AS discovery endpoint to =
actually
        do discovery for multiple AS systems.  E.g. to configure a
        client to a specific AS service designated by the customer
        paying for the resource service.  
    
      

    
      
    
      
    IOW. by providing a resource query, the meta-data =
config
        discovery actually looks more like discovery.  :-)
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    John's solution requires translating aud =
to
                res url and changes to core oauth. He seems to imply
                there is a need for ongoing validation of resource. I'm
                not yet convinced that is really needed.  Maybe it =
is
                needed because the client could be convinced to follow a
                link embedded in a resource that is somehow not part of
                the defined audience?
    
              

    
              
    
              
    Thanks
    
                
    
                Phil
    
              

    
                On Mar 16, 2016, at 08:57, George Fletcher <gffletch@aol.com>
                wrote:
    
                
    
              
    
              
    
                
    So, in thinking about all this AS
                    restricting tokens to RS and "discovery" of RS
                    endpoints, etc. I wondered why we don't just
                    leverage RS metadata like we have AS metadata.
    
                    
    
                    For an AS we require an 'iss' claim to use as an
                    identifier of the AS. We could do the same with RS
                    metadata retrieving the metadata from a .well-known
                    location and including a claim of 'rsid' to use as
                    an identifier of the Resource Server.
    
                    
    
                    This 'rsid' identifier could then be used for
                    registration with the AS and presentation by the
                    client when requesting tokens.
    
                    
    
                    This provides a separation between an identifier for
                    a resource and the specific endpoints the token will
                    be sent to. A client could "discover" the necessary
                    endpoint on a periodic basis and use a single
                    identifier with the AS for any of the endpoints or
                    scopes supported by the RS. If desired the RS could
                    expose the supported scopes in the RS metadata =
file.
    
                    
    
                    Thoughts?
    
                    
    
                    Thanks,
    
                    George
    
                
    
              
    
              
    
                
    _______________________________________________
    
                  OAuth mailing list
    
                  OAuth@ietf.org
    
                  https://www.ietf.org/mailman/listinfo/oauth
    
                
    
              
    
            
    
          
    
        
    
      
    
    
    
    
    
  
    



    =

--Apple-Mail=_6A314786-DC30-43B1-A3B1-DF2F32EB462A--


From nobody Wed Mar 16 15:38:25 2016
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 CAD1712D592 for ; Wed, 16 Mar 2016 15:38:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 smVICpgBpirY for ; Wed, 16 Mar 2016 15:38:19 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 B789212D568 for ; Wed, 16 Mar 2016 15:38:18 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id x1so27757369qkc.1 for ; Wed, 16 Mar 2016 15:38:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=wri65SnuNapyUosWObazcgbmwD2R39+dRJjWfkRGVVY=; b=sS8V35DgnH4poD9IghA3GVBsr9dv7/Tfg8u1TyWpKEkDCfG4eRS0v+fnpgQECUPyvL AlJ8/CP82gE/4sw7u4Q+IBMpGci3d9GCjhyKc++hGBFFjx67f3TYpbWB0lV4N3ZZGLsw Uc/t9x5hsuk0LJhXuixbtQM7OMmHOLudgMsxDyzReNx8YZjlkqTu5eCtiRM/H5HR3wxS oYFcmD3R8nUhLPdVht/TxyIAFWleAVMWQooJyfzxmXwiSwFU7CKn932jafMfQ5c2ztiY Hmof0uUo2ajFgooohqcGs0lIwh/FKrClbJVELcqmdVcWZOZTPNnZAJJ5Cgw8rccBfSMv wErA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wri65SnuNapyUosWObazcgbmwD2R39+dRJjWfkRGVVY=; b=nHoHNH65OHCRcbLB2EuhyQc/it8mfja4HBwIBOEgAEa+26j5EdZdQlg/VDBgN2mEgX gQy4+kF7oOQDw3JUkl918Nli+AXhdRmX+7mwtW6Kkr0x4AzLWNdkuIzXpyqg1qTLQoVF cLBDbMobzU2L/4PqCeOFcZuEIlZmKAPKFsrOM5KsM4p6uqUtuUVApbS7H4bYcZlaRHo+ UaNCcwyMqg9ywVMImhk7c7jng+o0l9r8UeUYs1rHM9ypVHzen92OYItXHi245gt7Lwta qZfCZVtpbsR0A57PFuuLOWCTl/Sy+KfYJvzriBbzRqimmIPz5aNuoyk+a9m4qd2Sazft s6/A==
X-Gm-Message-State: AD7BkJJ1lzSV2aTwFpb6WnUsLeChOWIIHX6MXYJSven5tLdaIudBDRsSSDE+BPAAHiH7Fw==
X-Received: by 10.55.207.217 with SMTP id v86mr9525407qkl.16.1458167897690; Wed, 16 Mar 2016 15:38:17 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.15.25]) by smtp.gmail.com with ESMTPSA id v66sm2466495qhb.26.2016.03.16.15.38.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 15:38:16 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_10A8A989-ED94-49C3-985D-60859CCAE9F4"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com>
Date: Wed, 16 Mar 2016 19:37:54 -0300
Message-Id: <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com>
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 22:38:23 -0000

--Apple-Mail=_10A8A989-ED94-49C3-985D-60859CCAE9F4
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_41E9114C-58A1-4F93-A8F8-55EDDFF7DA8C"


--Apple-Mail=_41E9114C-58A1-4F93-A8F8-55EDDFF7DA8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree with Phil that the client can=E2=80=99t trust any abstract =
identifier that it might get from a bad RS unless it is were a URI that =
the client or AS could deference to get a list of the concrete URI for =
the RS.

That seems like a lot of work that clients are unlikely to do.

A AS might do it if it wanted to look up the identifier for a given =
resource.=20

Something like do get on resource get back Abstract identifier (probably =
well known location, as recently pointed out in another thread you =
can=E2=80=99t allow it to point to user content.)=20

The AS gets the file and maps the uri to a abstract identifier for =
audience.

I guess that would be one way that you could map AS URI to a abstract =
identifier, but I wouldn=E2=80=99t want to count on clients doing it.

John B.





> On Mar 16, 2016, at 3:46 PM, Phil Hunt  wrote:
>=20
> George,
>=20
> Thanks. It would be good to get a draft that sketches out the overall =
picture of this for BA =E2=80=94 even if in very rough form given the =
deadline is monday.  Or, maybe just a PPT walkthru.
>=20
> Interested to see what comes out.
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 16, 2016, at 11:29 AM, George Fletcher > wrote:
>>=20
>> Inline...
>>=20
>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com =
phil.hunt@oracle.com =

>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher > wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>> George
>>>>>=20
>>>>> Very good question...
>>>>>=20
>>>>> I considered that the RS metadata discovery could be fake.=20
>>>> Same way that the 'iss' claim must "match" the url used to retrieve =
the metadata would apply to the 'rsid' claim
>>>> -- I think that should suffice to ensuring the 'rsid' identifier =
can't be spoofed by another site
>>>=20
>>> So the attacker makes iss and url match for the resource discovery. =
Yet the AS service provider doesn=E2=80=99t know where the client is =
using the tokens.  How would the client or the AS detect that the wrong =
iss was given?
>> Because if the attacker makes the rsid and the url match, then the =
client will submit an rsid that isn't "registered" with the AS and the =
AS won't issue the token. This assumes the client is not talking to an =
evil AS (as there are other mitigations for that case).
>>>=20
>>>>>=20
>>>>> So the final step in configuration validation is to bind the =
relationship between as and rs discovery together to confirm the =
relationship is valid.=20
>>>> And what I'd like to see is the 'rsid' value used to represent the =
RS rather than some unique endpoint (even if wildcards are allowed)
>>>=20
>>> Long term, I think this would be better. Do we have a way to issue =
RSID values in the works?
>> No, but that is what this email thread is contemplating:) Just as the =
AS iss value is selfdefined by the AS, the rsid should be selfdefined by =
the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how =
the AS 'iss' claim is defined for the AS in it's metadata.
>>>=20
>>> That said, I would have thought this is more ownerous than checking =
*.example.com  matches the given URL by the client.
>> My problem with the URL level checking is that a RS may legitimately =
have endpoints on multiple domains. An RS may move endpoints from one =
domain to another (say when moving from version 1 to version 2 of an =
API). Using the rsid for audience restriction and as an indirect =
mechanism for specifying actual endpoints, the RS has a much looser =
coupling with the AS.
>>=20
>> AS we move into "federated authorization" meaning that an RS =
outsources it's API authorization to one or more AS's, this will become =
more important.
>>>>=20
>>>> Another step that may be required is for the RS to return it's =
'rsid' in the realm field of the WWW-Authenticate response header. This =
allows a client to discover metadata about the RS and it's endpoints. It =
also allows the client to determine if the 'rsid' returned by the RS =
matches the 'rsid' it is expecting.
>>>=20
>>> Agreed. This might work. But should the check be when the client =
asks for the configuration metadata or when the client asks for tokens?  =
I think it only needs to happen at config time.
>> What I see here is that the desire is to audience protect tokens. To =
do that, the audience need to be specified everytime a token is =
requested. I really don't the AS to have to manage the complex state of =
which audiences have previously been issued to refresh_tokens and then =
reconstruct the correct audience for a requested downscoped =
access_token. It's much simpler, since the client knows which RS it's =
going to send the token to, to provide that when requesting tokens.
>>=20
>> The complication comes when exchanging the code for the tokens, it =
needs to specify all possible audiences (rsid's) it might send the token =
to based on the requested scopes. There will be a fair amount of complex =
logic at the AS to ensure the correct behavior. I do worry about this =
complexity.
>>>>>=20
>>>>> We are of course assuming that a hacker needs to use the real AS =
authorize endpoint to succeed in obtaining an access token(it can't be =
mitm'd). Once the grant is obtained by the client, the threat comes when =
the client uses the grant at a mitm'd token endpoint OR an access token =
at a mitm'd resource endpoint.=20
>>>>>=20
>>>>> So the AS and its config set becomes the trust anchor. Binding =
allows us to extend trust to the RS discovery giving some assurance that =
a client has a correct set of endpoints including resource.=20
>>>> Are you recommending that the AS metadata provide a list of the =
'rsid' supported by the AS?
>>> No.  I think that is a bad idea.  Better to use an identity oracle =
function and say, give me the config for rsid=3Dxyz
>> Good :)
>>>=20
>>> That also allows a common AS discovery endpoint to actually do =
discovery for multiple AS systems.  E.g. to configure a client to a =
specific AS service designated by the customer paying for the resource =
service. =20
>>>=20
>>> IOW. by providing a resource query, the meta-data config discovery =
actually looks more like discovery.  :-)
>>>>>=20
>>>>> John's solution requires translating aud to res url and changes to =
core oauth. He seems to imply there is a need for ongoing validation of =
resource. I'm not yet convinced that is really needed.  Maybe it is =
needed because the client could be convinced to follow a link embedded =
in a resource that is somehow not part of the defined audience?
>>>>>=20
>>>>> Thanks
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> On Mar 16, 2016, at 08:57, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>=20
>>>>>> So, in thinking about all this AS restricting tokens to RS and =
"discovery" of RS endpoints, etc. I wondered why we don't just leverage =
RS metadata like we have AS metadata.
>>>>>>=20
>>>>>> For an AS we require an 'iss' claim to use as an identifier of =
the AS. We could do the same with RS metadata retrieving the metadata =
from a .well-known location and including a claim of 'rsid' to use as an =
identifier of the Resource Server.
>>>>>>=20
>>>>>> This 'rsid' identifier could then be used for registration with =
the AS and presentation by the client when requesting tokens.
>>>>>>=20
>>>>>> This provides a separation between an identifier for a resource =
and the specific endpoints the token will be sent to. A client could =
"discover" the necessary endpoint on a periodic basis and use a single =
identifier with the AS for any of the endpoints or scopes supported by =
the RS. If desired the RS could expose the supported scopes in the RS =
metadata file.
>>>>>>=20
>>>>>> Thoughts?
>>>>>>=20
>>>>>> Thanks,
>>>>>> George
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_41E9114C-58A1-4F93-A8F8-55EDDFF7DA8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I agree with Phil that the client can=E2=80=99t trust any =
abstract identifier that it might get from a bad RS unless it is were a =
URI that the client or AS could deference to get a list of the concrete =
URI for the RS.

    That =
seems like a lot of work that clients are unlikely to do.

    A AS might do it if it =
wanted to look up the identifier for a given resource. 

    Something like do get on =
resource get back Abstract identifier (probably well known location, as =
recently pointed out in another thread you can=E2=80=99t allow it to =
point to user content.) 

    The AS gets the file and maps the uri =
to a abstract identifier for audience.

    I guess that would be one way that you =
could map AS URI to a abstract identifier, but I wouldn=E2=80=99t want =
to count on clients doing it.

    John B.





    On Mar 16, 2016, at 3:46 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    George,

    Thanks. It would be good =
to get a draft that sketches out the overall picture of this for BA =E2=80=
=94 even if in very rough form given the deadline is monday.  Or, =
maybe just a PPT walkthru.

    Interested to see what comes out.

    




    

    

    On Mar 16, 2016, at 11:29 AM, George Fletcher <gffletch@aol.com> =
wrote:

    
 =20
    
 =20
  
    
    Inline...
    
    
    
    
    On 3/16/16 2:16 PM, Phil Hunt =
wrote:
    
    
    
    
    
      
      
    
      
    
        
    
          
    
            
    
                
    
                  
    
                    
    
                      
    Phil
    
                      

    
                      
    
                      
    @independentid
    
                      
    www.independentid.com
    
                    
    
                  
    
                
    
                  phil.hunt@oracle.com
    
            

    
            
    
          
    
          
    
        
    
        
    
        
    
      
    
      
    
      
    
        
    
          
    On Mar 16, 2016, at 10:59 AM, George Fletcher
            <gffletch@aol.com> =
wrote:
    
          
    
          

    
            
    
            
    On 3/16/16 12:20 PM, Phil Hunt (IDM)
              wrote:
    
            
    
            
    
              
    George
    
              

    
              
    
              
    Very good question...
    
              

    
              
    
              
    I considered that the RS metadata =
discovery
                could be fake. 
    
              
    
            
    
            Same way that the
              'iss' claim must "match" the url used to retrieve the
              metadata would apply to the 'rsid' claim
    
              -- I think that should suffice to ensuring the 'rsid'
              identifier can't be spoofed by another site
    
            
    
        
    
        

    
        
    
        So the attacker makes iss and url match for the resource
        discovery. Yet the AS service provider doesn=E2=80=99t know =
where the
        client is using the tokens.  How would the client or the AS
        detect that the wrong iss was given?
    
    
    
    Because if the attacker makes the rsid and the url match, then the
    client will submit an rsid that isn't "registered" with the AS and
    the AS won't issue the token. This assumes the client is not talking
    to an evil AS (as there are other mitigations for that case).
    
    
    
      

    
        
    
          
    
            
    
              

    
              
    
              
    So the final step in configuration
                validation is to bind the relationship between as and rs
                discovery together to confirm the relationship is =
valid. 
    
              
    
            
    
            And what I'd like to see is the 'rsid' value used
              to represent the RS rather than some unique endpoint (even
              if wildcards are allowed)
    
          
    
        
    
        

    
        
    
        Long term, I think this would be better. Do we have a way to
        issue RSID values in the works?
    
    
    
    No, but that is what this email thread is contemplating:) Just as
    the AS iss value is selfdefined by the AS, the rsid should be
    selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
    is a mirror of how the AS 'iss' claim is defined for the AS in it's
    metadata.
    
    
    
      

    
      
    
      
    That said, I would have thought this is more =
ownerous than
        checking *.example.com matches the =
given URL by the client.
    
      
    
    
    
    My problem with the URL level checking is that a RS may legitimately
    have endpoints on multiple domains. An RS may move endpoints from
    one domain to another (say when moving from version 1 to version 2
    of an API). Using the rsid for audience restriction and as an
    indirect mechanism for specifying actual endpoints, the RS has a
    much looser coupling with the AS.
    
    
    
    AS we move into "federated authorization" meaning that an RS
    outsources it's API authorization to one or more AS's, this will
    become more important.
    
    
    
      
    
        
    
          

    
            Another step that may be required is for the RS
              to return it's 'rsid' in the realm field of the
              WWW-Authenticate response header. This allows a client to
              discover metadata about the RS and it's endpoints. It also
              allows the client to determine if the 'rsid' returned by
              the RS matches the 'rsid' it is expecting.
    
          
    
        
    
        

    
        
    
        Agreed. This might work. But should the check be when the client
        asks for the configuration metadata or when the client asks for
        tokens?  I think it only needs to happen at config time.
    
      
    
    
    
    What I see here is that the desire is to audience protect tokens. To
    do that, the audience need to be specified everytime a token is
    requested. I really don't the AS to have to manage the complex state
    of which audiences have previously been issued to refresh_tokens and
    then reconstruct the correct audience for a requested downscoped
    access_token. It's much simpler, since the client knows which RS
    it's going to send the token to, to provide that when requesting
    tokens.
    
    
    
    The complication comes when exchanging the code for the tokens, it
    needs to specify all possible audiences (rsid's) it might send the
    token to based on the requested scopes. There will be a fair amount
    of complex logic at the AS to ensure the correct behavior. I do
    worry about this complexity.
    
    
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    We are of course assuming that a hacker
                needs to use the real AS authorize endpoint to succeed
                in obtaining an access token(it can't be mitm'd). Once
                the grant is obtained by the client, the threat comes
                when the client uses the grant at a mitm'd token
                endpoint OR an access token at a mitm'd resource
                endpoint. 
    
              

    
              
    
              
    So the AS and its config set becomes the
                trust anchor. Binding allows us to extend trust to the
                RS discovery giving some assurance that a client has a
                correct set of endpoints including resource. 
    
              
    
            
    
            Are you recommending that the AS metadata provide
              a list of the 'rsid' supported by the AS?
    
          
    
        
    
        No.  I think that is a bad idea.  Better to use an =
identity
        oracle function and say, give me the config for rsid=3Dxyz
    
    
    
    Good :)
    
    
    
      

    
      
    
      
    That also allows a common AS discovery endpoint to =
actually
        do discovery for multiple AS systems.  E.g. to configure a
        client to a specific AS service designated by the customer
        paying for the resource service.  
    
      

    
      
    
      
    IOW. by providing a resource query, the meta-data =
config
        discovery actually looks more like discovery.  :-)
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    John's solution requires translating aud =
to
                res url and changes to core oauth. He seems to imply
                there is a need for ongoing validation of resource. I'm
                not yet convinced that is really needed.  Maybe it =
is
                needed because the client could be convinced to follow a
                link embedded in a resource that is somehow not part of
                the defined audience?
    
              

    
              
    
              
    Thanks
    
                
    
                Phil
    
              

    
                On Mar 16, 2016, at 08:57, George Fletcher <gffletch@aol.com>
                wrote:
    
                
    
              
    
              
    
                
    So, in thinking about all this AS
                    restricting tokens to RS and "discovery" of RS
                    endpoints, etc. I wondered why we don't just
                    leverage RS metadata like we have AS metadata.
    
                    
    
                    For an AS we require an 'iss' claim to use as an
                    identifier of the AS. We could do the same with RS
                    metadata retrieving the metadata from a .well-known
                    location and including a claim of 'rsid' to use as
                    an identifier of the Resource Server.
    
                    
    
                    This 'rsid' identifier could then be used for
                    registration with the AS and presentation by the
                    client when requesting tokens.
    
                    
    
                    This provides a separation between an identifier for
                    a resource and the specific endpoints the token will
                    be sent to. A client could "discover" the necessary
                    endpoint on a periodic basis and use a single
                    identifier with the AS for any of the endpoints or
                    scopes supported by the RS. If desired the RS could
                    expose the supported scopes in the RS metadata =
file.
    
                    
    
                    Thoughts?
    
                    
    
                    Thanks,
    
                    George
    
                
    
              
    
              
    
                
    _______________________________________________
    
                  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

    =

--Apple-Mail=_41E9114C-58A1-4F93-A8F8-55EDDFF7DA8C--

--Apple-Mail=_10A8A989-ED94-49C3-985D-60859CCAE9F4
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTYyMjM3NTRaMCMGCSqGSIb3DQEJBDEWBBSPz9BqZ1qHxavCzEVpf6z3
p9wHHzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQChzlTmDFp23V6B13qq45yDuexHl2Qe8Sqia8A3vdckqrHIyVI8vD5Q
BOXJIUxXIrWyI8wpxNZ+DtGWk93cuF/rZfjzZf6MmX5RStBEf+7UBeD75VpjQmUJQQuS21YfodwU
UODaNyYA1aNQj8HPtJPRxC7do2wDLY2OXVAGEDM/bAIOnWMaLtTo+Vx6QXL442ohjrzxuRtQ7/fd
X7valetdd/Kz1VYfjJseAXR/80Lh5LLGerX8YGDmAP051EPsFh/yGSxJso9NoKbtog9rWw6gt8+W
OknOooo4aqtImJofFa1Cn5WvLOMNs46dZfWLTaWHDtIJWh0hO09PDNm9bvcuAAAAAAAA
--Apple-Mail=_10A8A989-ED94-49C3-985D-60859CCAE9F4--


From nobody Wed Mar 16 16:08:51 2016
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 A223212D612 for ; Wed, 16 Mar 2016 16:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 4_Ke9J_xHQPS for ; Wed, 16 Mar 2016 16:08:47 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 2B26A12D5A3 for ; Wed, 16 Mar 2016 16:08:47 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2GN8h5Y002884 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Mar 2016 23:08:44 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2GN8ghW024395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 23:08:43 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2GN8f9b019480; Wed, 16 Mar 2016 23:08:42 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Mar 2016 16:08:41 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_26C128DD-FDF0-47CD-A875-62DFF6FFD272"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com>
Date: Wed, 16 Mar 2016 16:08:39 -0700
Message-Id: 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 23:08:49 -0000

--Apple-Mail=_26C128DD-FDF0-47CD-A875-62DFF6FFD272
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99m assuming that in many cases, the =E2=80=9Caud=E2=80=9D =
concept is opaque or even non-existent to clients.  It would be hard for =
them to translate one to the other.

However, it may be that in some resource discovery cases, they are =
passing a URI (an RSID?) to a discovery service and the discovery =
translates that into a real endpoint. **

At some point then, having obtained what the client thinks is the =
resource endpoint, either in the OAuth config lookup, or elsewhere (as =
John Proposes) in the AS interactions, the endpoint obtained by the =
client for the resource is checked to some degree (regex filter, domain =
name check, lookup, etc).

** I don=E2=80=99t want to make people=E2=80=99s head explode, but =
thinking about Tony=E2=80=99s idea on software statements...  one of the =
possibilities is that the resource discovery could return a software =
statement describing the resource.  It would include items like valid =
endpoints for the resource as well as its audience URI(s). The AS config =
endpoint then uses the statement itself (signed by a trusted party) as =
the translation method bridging aud to real endpoint URL.

Parsing a statement may be a bit more complex for the client, but it may =
solve scenarios that using a resource endpoint URL alone can=E2=80=99t =
address.

Would it be worth setting up a concall early next week? The objective =
would be to come up with a couple of ppt slides (e.g. swim lanes) we =
could talk about in BA.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 16, 2016, at 3:37 PM, John Bradley  wrote:
>=20
> I agree with Phil that the client can=E2=80=99t trust any abstract =
identifier that it might get from a bad RS unless it is were a URI that =
the client or AS could deference to get a list of the concrete URI for =
the RS.
>=20
> That seems like a lot of work that clients are unlikely to do.
>=20
> A AS might do it if it wanted to look up the identifier for a given =
resource.=20
>=20
> Something like do get on resource get back Abstract identifier =
(probably well known location, as recently pointed out in another thread =
you can=E2=80=99t allow it to point to user content.)=20
>=20
> The AS gets the file and maps the uri to a abstract identifier for =
audience.
>=20
> I guess that would be one way that you could map AS URI to a abstract =
identifier, but I wouldn=E2=80=99t want to count on clients doing it.
>=20
> John B.
>=20
>=20
>=20
>=20
>=20
>> On Mar 16, 2016, at 3:46 PM, Phil Hunt > wrote:
>>=20
>> George,
>>=20
>> Thanks. It would be good to get a draft that sketches out the overall =
picture of this for BA =E2=80=94 even if in very rough form given the =
deadline is monday.  Or, maybe just a PPT walkthru.
>>=20
>> Interested to see what comes out.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com =
phil.hunt@oracle.com =

>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 16, 2016, at 11:29 AM, George Fletcher > wrote:
>>>=20
>>> Inline...
>>>=20
>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher > wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>> George
>>>>>>=20
>>>>>> Very good question...
>>>>>>=20
>>>>>> I considered that the RS metadata discovery could be fake.=20
>>>>> Same way that the 'iss' claim must "match" the url used to =
retrieve the metadata would apply to the 'rsid' claim
>>>>> -- I think that should suffice to ensuring the 'rsid' identifier =
can't be spoofed by another site
>>>>=20
>>>> So the attacker makes iss and url match for the resource discovery. =
Yet the AS service provider doesn=E2=80=99t know where the client is =
using the tokens.  How would the client or the AS detect that the wrong =
iss was given?
>>> Because if the attacker makes the rsid and the url match, then the =
client will submit an rsid that isn't "registered" with the AS and the =
AS won't issue the token. This assumes the client is not talking to an =
evil AS (as there are other mitigations for that case).
>>>>=20
>>>>>>=20
>>>>>> So the final step in configuration validation is to bind the =
relationship between as and rs discovery together to confirm the =
relationship is valid.=20
>>>>> And what I'd like to see is the 'rsid' value used to represent the =
RS rather than some unique endpoint (even if wildcards are allowed)
>>>>=20
>>>> Long term, I think this would be better. Do we have a way to issue =
RSID values in the works?
>>> No, but that is what this email thread is contemplating:) Just as =
the AS iss value is selfdefined by the AS, the rsid should be =
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a =
mirror of how the AS 'iss' claim is defined for the AS in it's metadata.
>>>>=20
>>>> That said, I would have thought this is more ownerous than checking =
*.example.com  matches the given URL by the client.
>>> My problem with the URL level checking is that a RS may legitimately =
have endpoints on multiple domains. An RS may move endpoints from one =
domain to another (say when moving from version 1 to version 2 of an =
API). Using the rsid for audience restriction and as an indirect =
mechanism for specifying actual endpoints, the RS has a much looser =
coupling with the AS.
>>>=20
>>> AS we move into "federated authorization" meaning that an RS =
outsources it's API authorization to one or more AS's, this will become =
more important.
>>>>>=20
>>>>> Another step that may be required is for the RS to return it's =
'rsid' in the realm field of the WWW-Authenticate response header. This =
allows a client to discover metadata about the RS and it's endpoints. It =
also allows the client to determine if the 'rsid' returned by the RS =
matches the 'rsid' it is expecting.
>>>>=20
>>>> Agreed. This might work. But should the check be when the client =
asks for the configuration metadata or when the client asks for tokens?  =
I think it only needs to happen at config time.
>>> What I see here is that the desire is to audience protect tokens. To =
do that, the audience need to be specified everytime a token is =
requested. I really don't the AS to have to manage the complex state of =
which audiences have previously been issued to refresh_tokens and then =
reconstruct the correct audience for a requested downscoped =
access_token. It's much simpler, since the client knows which RS it's =
going to send the token to, to provide that when requesting tokens.
>>>=20
>>> The complication comes when exchanging the code for the tokens, it =
needs to specify all possible audiences (rsid's) it might send the token =
to based on the requested scopes. There will be a fair amount of complex =
logic at the AS to ensure the correct behavior. I do worry about this =
complexity.
>>>>>>=20
>>>>>> We are of course assuming that a hacker needs to use the real AS =
authorize endpoint to succeed in obtaining an access token(it can't be =
mitm'd). Once the grant is obtained by the client, the threat comes when =
the client uses the grant at a mitm'd token endpoint OR an access token =
at a mitm'd resource endpoint.=20
>>>>>>=20
>>>>>> So the AS and its config set becomes the trust anchor. Binding =
allows us to extend trust to the RS discovery giving some assurance that =
a client has a correct set of endpoints including resource.=20
>>>>> Are you recommending that the AS metadata provide a list of the =
'rsid' supported by the AS?
>>>> No.  I think that is a bad idea.  Better to use an identity oracle =
function and say, give me the config for rsid=3Dxyz
>>> Good :)
>>>>=20
>>>> That also allows a common AS discovery endpoint to actually do =
discovery for multiple AS systems.  E.g. to configure a client to a =
specific AS service designated by the customer paying for the resource =
service. =20
>>>>=20
>>>> IOW. by providing a resource query, the meta-data config discovery =
actually looks more like discovery.  :-)
>>>>>>=20
>>>>>> John's solution requires translating aud to res url and changes =
to core oauth. He seems to imply there is a need for ongoing validation =
of resource. I'm not yet convinced that is really needed.  Maybe it is =
needed because the client could be convinced to follow a link embedded =
in a resource that is somehow not part of the defined audience?
>>>>>>=20
>>>>>> Thanks
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> On Mar 16, 2016, at 08:57, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>>=20
>>>>>>> So, in thinking about all this AS restricting tokens to RS and =
"discovery" of RS endpoints, etc. I wondered why we don't just leverage =
RS metadata like we have AS metadata.
>>>>>>>=20
>>>>>>> For an AS we require an 'iss' claim to use as an identifier of =
the AS. We could do the same with RS metadata retrieving the metadata =
from a .well-known location and including a claim of 'rsid' to use as an =
identifier of the Resource Server.
>>>>>>>=20
>>>>>>> This 'rsid' identifier could then be used for registration with =
the AS and presentation by the client when requesting tokens.
>>>>>>>=20
>>>>>>> This provides a separation between an identifier for a resource =
and the specific endpoints the token will be sent to. A client could =
"discover" the necessary endpoint on a periodic basis and use a single =
identifier with the AS for any of the endpoints or scopes supported by =
the RS. If desired the RS could expose the supported scopes in the RS =
metadata file.
>>>>>>>=20
>>>>>>> Thoughts?
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> George
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_26C128DD-FDF0-47CD-A875-62DFF6FFD272
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I=E2=80=99m assuming that in many cases, the =E2=80=9Caud=E2=80=
=9D concept is opaque or even non-existent to clients.  It would be =
hard for them to translate one to the other.

    However, it may be that in some =
resource discovery cases, they are passing a URI (an RSID?) to a =
discovery service and the discovery translates that into a real =
endpoint. **

    At =
some point then, having obtained what the client thinks is the resource =
endpoint, either in the OAuth config lookup, or elsewhere (as John =
Proposes) in the AS interactions, the endpoint obtained by the client =
for the resource is checked to some degree (regex filter, domain name =
check, lookup, etc).

    ** I don=E2=80=99t want to make people=E2=80=99s head =
explode, but thinking about Tony=E2=80=99s idea on software =
statements...  one of the possibilities is that the resource =
discovery could return a software statement describing the resource. =
 It would include items like valid endpoints for the resource as =
well as its audience URI(s). The AS config endpoint then uses the =
statement itself (signed by a trusted party) as the translation method =
bridging aud to real endpoint URL.

    Parsing a statement may be a bit more =
complex for the client, but it may solve scenarios that using a resource =
endpoint URL alone can=E2=80=99t address.

    Would it be worth setting up a concall =
early next week? The objective would be to come up with a couple of ppt =
slides (e.g. swim lanes) we could talk about in BA.

    


    

    

    On Mar 16, 2016, at 3:37 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    I agree with =
Phil that the client can=E2=80=99t trust any abstract identifier that it =
might get from a bad RS unless it is were a URI that the client or AS =
could deference to get a list of the concrete URI for the RS.

    That seems like a lot of =
work that clients are unlikely to do.

    A AS might do it if it wanted to look =
up the identifier for a given resource. 

    Something like do get on resource get =
back Abstract identifier (probably well known location, as recently =
pointed out in another thread you can=E2=80=99t allow it to point to =
user content.) 

    The AS gets the file and maps the uri to a abstract =
identifier for audience.

    I guess that would be one way that you could map AS URI to a =
abstract identifier, but I wouldn=E2=80=99t want to count on clients =
doing it.

    John =
B.





    On Mar =
16, 2016, at 3:46 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    George,

    Thanks. It would be good =
to get a draft that sketches out the overall picture of this for BA =E2=80=
=94 even if in very rough form given the deadline is monday.  Or, =
maybe just a PPT walkthru.

    Interested to see what comes out.

    




    

    

    On Mar 16, 2016, at 11:29 AM, George Fletcher <gffletch@aol.com> =
wrote:

    
 =20
    
 =20
  
    
    Inline...
    
    
    
    
    On 3/16/16 2:16 PM, Phil Hunt =
wrote:
    
    
    
    
    
      
      
    
      
    
        
    
          
    
            
    
                
    
                  
    
                    
    
                      
    Phil
    
                      

    
                      
    
                      
    @independentid
    
                      
    www.independentid.com
    
                    
    
                  
    
                
    
                  phil.hunt@oracle.com
    
            

    
            
    
          
    
          
    
        
    
        
    
        
    
      
    
      
    
      
    
        
    
          
    On Mar 16, 2016, at 10:59 AM, George Fletcher
            <gffletch@aol.com> =
wrote:
    
          
    
          

    
            
    
            
    On 3/16/16 12:20 PM, Phil Hunt (IDM)
              wrote:
    
            
    
            
    
              
    George
    
              

    
              
    
              
    Very good question...
    
              

    
              
    
              
    I considered that the RS metadata =
discovery
                could be fake. 
    
              
    
            
    
            Same way that the
              'iss' claim must "match" the url used to retrieve the
              metadata would apply to the 'rsid' claim
    
              -- I think that should suffice to ensuring the 'rsid'
              identifier can't be spoofed by another site
    
            
    
        
    
        

    
        
    
        So the attacker makes iss and url match for the resource
        discovery. Yet the AS service provider doesn=E2=80=99t know =
where the
        client is using the tokens.  How would the client or the AS
        detect that the wrong iss was given?
    
    
    
    Because if the attacker makes the rsid and the url match, then the
    client will submit an rsid that isn't "registered" with the AS and
    the AS won't issue the token. This assumes the client is not talking
    to an evil AS (as there are other mitigations for that case).
    
    
    
      

    
        
    
          
    
            
    
              

    
              
    
              
    So the final step in configuration
                validation is to bind the relationship between as and rs
                discovery together to confirm the relationship is =
valid. 
    
              
    
            
    
            And what I'd like to see is the 'rsid' value used
              to represent the RS rather than some unique endpoint (even
              if wildcards are allowed)
    
          
    
        
    
        

    
        
    
        Long term, I think this would be better. Do we have a way to
        issue RSID values in the works?
    
    
    
    No, but that is what this email thread is contemplating:) Just as
    the AS iss value is selfdefined by the AS, the rsid should be
    selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
    is a mirror of how the AS 'iss' claim is defined for the AS in it's
    metadata.
    
    
    
      

    
      
    
      
    That said, I would have thought this is more =
ownerous than
        checking *.example.com matches the =
given URL by the client.
    
      
    
    
    
    My problem with the URL level checking is that a RS may legitimately
    have endpoints on multiple domains. An RS may move endpoints from
    one domain to another (say when moving from version 1 to version 2
    of an API). Using the rsid for audience restriction and as an
    indirect mechanism for specifying actual endpoints, the RS has a
    much looser coupling with the AS.
    
    
    
    AS we move into "federated authorization" meaning that an RS
    outsources it's API authorization to one or more AS's, this will
    become more important.
    
    
    
      
    
        
    
          

    
            Another step that may be required is for the RS
              to return it's 'rsid' in the realm field of the
              WWW-Authenticate response header. This allows a client to
              discover metadata about the RS and it's endpoints. It also
              allows the client to determine if the 'rsid' returned by
              the RS matches the 'rsid' it is expecting.
    
          
    
        
    
        

    
        
    
        Agreed. This might work. But should the check be when the client
        asks for the configuration metadata or when the client asks for
        tokens?  I think it only needs to happen at config time.
    
      
    
    
    
    What I see here is that the desire is to audience protect tokens. To
    do that, the audience need to be specified everytime a token is
    requested. I really don't the AS to have to manage the complex state
    of which audiences have previously been issued to refresh_tokens and
    then reconstruct the correct audience for a requested downscoped
    access_token. It's much simpler, since the client knows which RS
    it's going to send the token to, to provide that when requesting
    tokens.
    
    
    
    The complication comes when exchanging the code for the tokens, it
    needs to specify all possible audiences (rsid's) it might send the
    token to based on the requested scopes. There will be a fair amount
    of complex logic at the AS to ensure the correct behavior. I do
    worry about this complexity.
    
    
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    We are of course assuming that a hacker
                needs to use the real AS authorize endpoint to succeed
                in obtaining an access token(it can't be mitm'd). Once
                the grant is obtained by the client, the threat comes
                when the client uses the grant at a mitm'd token
                endpoint OR an access token at a mitm'd resource
                endpoint. 
    
              

    
              
    
              
    So the AS and its config set becomes the
                trust anchor. Binding allows us to extend trust to the
                RS discovery giving some assurance that a client has a
                correct set of endpoints including resource. 
    
              
    
            
    
            Are you recommending that the AS metadata provide
              a list of the 'rsid' supported by the AS?
    
          
    
        
    
        No.  I think that is a bad idea.  Better to use an =
identity
        oracle function and say, give me the config for rsid=3Dxyz
    
    
    
    Good :)
    
    
    
      

    
      
    
      
    That also allows a common AS discovery endpoint to =
actually
        do discovery for multiple AS systems.  E.g. to configure a
        client to a specific AS service designated by the customer
        paying for the resource service.  
    
      

    
      
    
      
    IOW. by providing a resource query, the meta-data =
config
        discovery actually looks more like discovery.  :-)
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    John's solution requires translating aud =
to
                res url and changes to core oauth. He seems to imply
                there is a need for ongoing validation of resource. I'm
                not yet convinced that is really needed.  Maybe it =
is
                needed because the client could be convinced to follow a
                link embedded in a resource that is somehow not part of
                the defined audience?
    
              

    
              
    
              
    Thanks
    
                
    
                Phil
    
              

    
                On Mar 16, 2016, at 08:57, George Fletcher <gffletch@aol.com>
                wrote:
    
                
    
              
    
              
    
                
    So, in thinking about all this AS
                    restricting tokens to RS and "discovery" of RS
                    endpoints, etc. I wondered why we don't just
                    leverage RS metadata like we have AS metadata.
    
                    
    
                    For an AS we require an 'iss' claim to use as an
                    identifier of the AS. We could do the same with RS
                    metadata retrieving the metadata from a .well-known
                    location and including a claim of 'rsid' to use as
                    an identifier of the Resource Server.
    
                    
    
                    This 'rsid' identifier could then be used for
                    registration with the AS and presentation by the
                    client when requesting tokens.
    
                    
    
                    This provides a separation between an identifier for
                    a resource and the specific endpoints the token will
                    be sent to. A client could "discover" the necessary
                    endpoint on a periodic basis and use a single
                    identifier with the AS for any of the endpoints or
                    scopes supported by the RS. If desired the RS could
                    expose the supported scopes in the RS metadata =
file.
    
                    
    
                    Thoughts?
    
                    
    
                    Thanks,
    
                    George
    
                
    
              
    
              
    
                
    _______________________________________________
    
                  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


    =

--Apple-Mail=_26C128DD-FDF0-47CD-A875-62DFF6FFD272--


From nobody Wed Mar 16 16:28:55 2016
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 4996212D567 for ; Wed, 16 Mar 2016 16:28:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 2N1PVO9L8EWk for ; Wed, 16 Mar 2016 16:28:49 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 5A2BB12D521 for ; Wed, 16 Mar 2016 16:28:49 -0700 (PDT)
Received: by mail-qg0-x236.google.com with SMTP id u110so57701333qge.3 for ; Wed, 16 Mar 2016 16:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=BYSnZ7Ycm7/PKs7ztre5Hz9L717d4BfViU5xmOxyYwQ=; b=aKDOWJEYWdn38CaCEy1Al9DT9f3LS87vkojw9ec7qnUXpG+c2Pl7XrsFlQNpEHpuac P/y2gfxycWbV6Psu7m6evnF745cXPX4f4K5qsSB4QmVBvvzgcXE9Z/ZK4QzuslBQ5nyh OGNcfBZsqXBB93jsD5A0siDtFEHz0xoQhZ5jcZdLXabFWgR2poxURP7FyEAgLKFHQ68t rkITJvmNgTDZIdK5h6crdvgxmLOXJ7PsDUPWkB3NODPNgngdDp9ZHGi51szhkvhpRgMt q+QG+skLIeYw2WH1CoCrMr7gJgBTKqWTyehpjxG0Uh25u0GEW+UKknM9i2VPJCkeGFpo HzSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BYSnZ7Ycm7/PKs7ztre5Hz9L717d4BfViU5xmOxyYwQ=; b=QWmBaGlThRZ7yhwrJOdnc43a4bekC2ASm5emfSnUMBWzqbqvETe2g4kteBUxEpUcnL ZvdZOkHsMfz927UmSZj1PoDiRj7dAtURem6vTKL9862LPoeo6vpq/HfFny1M94Qq31so mijg/MXSb4c8C2zMbK9oSO1K9J8aCKCEJw3vKK1stakaTyMFQQjab8V2rBfrFNyp6LKB 2vcWtW/S3l+W7OfRiLZKuvtwgXQ86/IihamqBufWpzn4/mIFR8dXY3HPWlbKNOBzmGTa CIAtHVWYg8gqMSNhGGfH0iJAiRhS5dCSrAJn76iWKmMMxjnAWlyU8z2vF/JOOCg0fkU0 LlbQ==
X-Gm-Message-State: AD7BkJLV99+aC2SS1IqrkF/ncL6PSkTux5bXJ8BGmo/yHKXzvApTdbQioyK9NPiLJj6wsw==
X-Received: by 10.140.88.202 with SMTP id t68mr9745763qgd.86.1458170928185; Wed, 16 Mar 2016 16:28:48 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.15.25]) by smtp.gmail.com with ESMTPSA id y206sm2574850qhc.0.2016.03.16.16.28.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 16:28:46 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_32326404-1D5E-4029-A59D-0ADCD1C90AD5"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Wed, 16 Mar 2016 20:28:25 -0300
Message-Id: <1B415585-D80D-484F-B297-EB6AB9FE2095@ve7jtb.com>
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 23:28:53 -0000

--Apple-Mail=_32326404-1D5E-4029-A59D-0ADCD1C90AD5
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_EA443D6A-0575-4E4A-BD2D-3A77A1E48D38"


--Apple-Mail=_EA443D6A-0575-4E4A-BD2D-3A77A1E48D38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The aud of the access token is completely opaque to the client in all =
cases, with the possible exception of someone who is using scopes to =
represent resources and the client has some mapping of scopes granted to =
RS endpoints.   I am just trying to find a less confusing way to do that =
without the client needing a mapping.=20

Opaque audiences are how a client can get confused and present a token =
to a endpoint that is not part of the audience.=20

I don=E2=80=99t know that software statements for resources (need a =
different name at-least) are that useful. That starts sounding a lot =
like SAML SP meta-data signed by a federation.=20
There might be a reason to do it but it is probably overkill for the =
immediate problems.  I don=E2=80=99t think that OAuth should require a =
central trusted authority to be securely deployed.

I am in the UK at meetings next week but will try to join if a call is =
set up.

John B.




> On Mar 16, 2016, at 8:08 PM, Phil Hunt  wrote:
>=20
> I=E2=80=99m assuming that in many cases, the =E2=80=9Caud=E2=80=9D =
concept is opaque or even non-existent to clients.  It would be hard for =
them to translate one to the other.
>=20
> However, it may be that in some resource discovery cases, they are =
passing a URI (an RSID?) to a discovery service and the discovery =
translates that into a real endpoint. **
>=20
> At some point then, having obtained what the client thinks is the =
resource endpoint, either in the OAuth config lookup, or elsewhere (as =
John Proposes) in the AS interactions, the endpoint obtained by the =
client for the resource is checked to some degree (regex filter, domain =
name check, lookup, etc).
>=20
> ** I don=E2=80=99t want to make people=E2=80=99s head explode, but =
thinking about Tony=E2=80=99s idea on software statements...  one of the =
possibilities is that the resource discovery could return a software =
statement describing the resource.  It would include items like valid =
endpoints for the resource as well as its audience URI(s). The AS config =
endpoint then uses the statement itself (signed by a trusted party) as =
the translation method bridging aud to real endpoint URL.
>=20
> Parsing a statement may be a bit more complex for the client, but it =
may solve scenarios that using a resource endpoint URL alone can=E2=80=99t=
 address.
>=20
> Would it be worth setting up a concall early next week? The objective =
would be to come up with a couple of ppt slides (e.g. swim lanes) we =
could talk about in BA.
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 16, 2016, at 3:37 PM, John Bradley > wrote:
>>=20
>> I agree with Phil that the client can=E2=80=99t trust any abstract =
identifier that it might get from a bad RS unless it is were a URI that =
the client or AS could deference to get a list of the concrete URI for =
the RS.
>>=20
>> That seems like a lot of work that clients are unlikely to do.
>>=20
>> A AS might do it if it wanted to look up the identifier for a given =
resource.=20
>>=20
>> Something like do get on resource get back Abstract identifier =
(probably well known location, as recently pointed out in another thread =
you can=E2=80=99t allow it to point to user content.)=20
>>=20
>> The AS gets the file and maps the uri to a abstract identifier for =
audience.
>>=20
>> I guess that would be one way that you could map AS URI to a abstract =
identifier, but I wouldn=E2=80=99t want to count on clients doing it.
>>=20
>> John B.
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt > wrote:
>>>=20
>>> George,
>>>=20
>>> Thanks. It would be good to get a draft that sketches out the =
overall picture of this for BA =E2=80=94 even if in very rough form =
given the deadline is monday.  Or, maybe just a PPT walkthru.
>>>=20
>>> Interested to see what comes out.
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com =
phil.hunt@oracle.com =

>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher > wrote:
>>>>=20
>>>> Inline...
>>>>=20
>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher > wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>> George
>>>>>>>=20
>>>>>>> Very good question...
>>>>>>>=20
>>>>>>> I considered that the RS metadata discovery could be fake.=20
>>>>>> Same way that the 'iss' claim must "match" the url used to =
retrieve the metadata would apply to the 'rsid' claim
>>>>>> -- I think that should suffice to ensuring the 'rsid' identifier =
can't be spoofed by another site
>>>>>=20
>>>>> So the attacker makes iss and url match for the resource =
discovery. Yet the AS service provider doesn=E2=80=99t know where the =
client is using the tokens.  How would the client or the AS detect that =
the wrong iss was given?
>>>> Because if the attacker makes the rsid and the url match, then the =
client will submit an rsid that isn't "registered" with the AS and the =
AS won't issue the token. This assumes the client is not talking to an =
evil AS (as there are other mitigations for that case).
>>>>>=20
>>>>>>>=20
>>>>>>> So the final step in configuration validation is to bind the =
relationship between as and rs discovery together to confirm the =
relationship is valid.=20
>>>>>> And what I'd like to see is the 'rsid' value used to represent =
the RS rather than some unique endpoint (even if wildcards are allowed)
>>>>>=20
>>>>> Long term, I think this would be better. Do we have a way to issue =
RSID values in the works?
>>>> No, but that is what this email thread is contemplating:) Just as =
the AS iss value is selfdefined by the AS, the rsid should be =
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a =
mirror of how the AS 'iss' claim is defined for the AS in it's metadata.
>>>>>=20
>>>>> That said, I would have thought this is more ownerous than =
checking *.example.com  matches the given URL by =
the client.
>>>> My problem with the URL level checking is that a RS may =
legitimately have endpoints on multiple domains. An RS may move =
endpoints from one domain to another (say when moving from version 1 to =
version 2 of an API). Using the rsid for audience restriction and as an =
indirect mechanism for specifying actual endpoints, the RS has a much =
looser coupling with the AS.
>>>>=20
>>>> AS we move into "federated authorization" meaning that an RS =
outsources it's API authorization to one or more AS's, this will become =
more important.
>>>>>>=20
>>>>>> Another step that may be required is for the RS to return it's =
'rsid' in the realm field of the WWW-Authenticate response header. This =
allows a client to discover metadata about the RS and it's endpoints. It =
also allows the client to determine if the 'rsid' returned by the RS =
matches the 'rsid' it is expecting.
>>>>>=20
>>>>> Agreed. This might work. But should the check be when the client =
asks for the configuration metadata or when the client asks for tokens?  =
I think it only needs to happen at config time.
>>>> What I see here is that the desire is to audience protect tokens. =
To do that, the audience need to be specified everytime a token is =
requested. I really don't the AS to have to manage the complex state of =
which audiences have previously been issued to refresh_tokens and then =
reconstruct the correct audience for a requested downscoped =
access_token. It's much simpler, since the client knows which RS     =
it's going to send the token to, to provide that when requesting tokens.
>>>>=20
>>>> The complication comes when exchanging the code for the tokens, it =
needs to specify all possible audiences (rsid's) it might send the token =
to based on the requested scopes. There will be a fair amount of complex =
logic at the AS to ensure the correct behavior. I do worry about this =
complexity.
>>>>>>>=20
>>>>>>> We are of course assuming that a hacker needs to use the real AS =
authorize endpoint to succeed in obtaining an access token(it can't be =
mitm'd). Once the grant is obtained by the client, the threat comes when =
the client uses the grant at a mitm'd token endpoint OR an access token =
at a mitm'd resource endpoint.=20
>>>>>>>=20
>>>>>>> So the AS and its config set becomes the trust anchor. Binding =
allows us to extend trust to the RS discovery giving some assurance that =
a client has a correct set of endpoints including resource.=20
>>>>>> Are you recommending that the AS metadata provide a list of the =
'rsid' supported by the AS?
>>>>> No.  I think that is a bad idea.  Better to use an identity oracle =
function and say, give me the config for rsid=3Dxyz
>>>> Good :)
>>>>>=20
>>>>> That also allows a common AS discovery endpoint to actually do =
discovery for multiple AS systems.  E.g. to configure a client to a =
specific AS service designated by the customer paying for the resource =
service. =20
>>>>>=20
>>>>> IOW. by providing a resource query, the meta-data config discovery =
actually looks more like discovery.  :-)
>>>>>>>=20
>>>>>>> John's solution requires translating aud to res url and changes =
to core oauth. He seems to imply there is a need for ongoing validation =
of resource. I'm not yet convinced that is really needed.  Maybe it is =
needed because the client could be convinced to follow a link embedded =
in a resource that is somehow not part of the defined audience?
>>>>>>>=20
>>>>>>> Thanks
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>>>=20
>>>>>>>> So, in thinking about all this AS restricting tokens to RS and =
"discovery" of RS endpoints, etc. I wondered why we don't just leverage =
RS metadata like we have AS metadata.
>>>>>>>>=20
>>>>>>>> For an AS we require an 'iss' claim to use as an identifier of =
the AS. We could do the same with RS metadata retrieving the metadata =
from a .well-known location and including a claim of 'rsid' to use as an =
identifier of the Resource Server.
>>>>>>>>=20
>>>>>>>> This 'rsid' identifier could then be used for registration with =
the AS and presentation by the client when requesting tokens.
>>>>>>>>=20
>>>>>>>> This provides a separation between an identifier for a resource =
and the specific endpoints the token will be sent to. A client could =
"discover" the necessary endpoint on a periodic basis and use a single =
identifier with the AS for any of the endpoints or scopes supported by =
the RS. If desired the RS could expose the supported scopes in the RS =
metadata file.
>>>>>>>>=20
>>>>>>>> Thoughts?
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>> George
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org 
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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

>>=20
>=20


--Apple-Mail=_EA443D6A-0575-4E4A-BD2D-3A77A1E48D38
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The aud of the access token is completely opaque to the =
client in all cases, with the possible exception of someone who is using =
scopes to represent resources and the client has some mapping of scopes =
granted to RS endpoints.   I am just trying to find a less =
confusing way to do that without the client needing a mapping. 

    Opaque audiences are how =
a client can get confused and present a token to a endpoint that is not =
part of the audience. 

    I don=E2=80=99t know that software statements for resources =
(need a different name at-least) are that useful. That starts sounding a =
lot like SAML SP meta-data signed by a federation. 
    There might be a reason to do it but it is probably overkill =
for the immediate problems.  I don=E2=80=99t think that OAuth =
should require a central trusted authority to be securely =
deployed.

    I am =
in the UK at meetings next week but will try to join if a call is set =
up.

    John =
B.




    On =
Mar 16, 2016, at 8:08 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    I=E2=80=99m =
assuming that in many cases, the =E2=80=9Caud=E2=80=9D concept is opaque =
or even non-existent to clients.  It would be hard for them to =
translate one to the other.

    However, it may be that in some resource discovery cases, =
they are passing a URI (an RSID?) to a discovery service and the =
discovery translates that into a real endpoint. **

    At some point then, =
having obtained what the client thinks is the resource endpoint, either =
in the OAuth config lookup, or elsewhere (as John Proposes) in the AS =
interactions, the endpoint obtained by the client for the resource is =
checked to some degree (regex filter, domain name check, lookup, =
etc).

    ** I =
don=E2=80=99t want to make people=E2=80=99s head explode, but thinking =
about Tony=E2=80=99s idea on software statements...  one of the =
possibilities is that the resource discovery could return a software =
statement describing the resource.  It would include items like =
valid endpoints for the resource as well as its audience URI(s). The AS =
config endpoint then uses the statement itself (signed by a trusted =
party) as the translation method bridging aud to real endpoint =
URL.

    Parsing a =
statement may be a bit more complex for the client, but it may solve =
scenarios that using a resource endpoint URL alone can=E2=80=99t =
address.

    Would =
it be worth setting up a concall early next week? The objective would be =
to come up with a couple of ppt slides (e.g. swim lanes) we could talk =
about in BA.

    




    

    

    On Mar 16, 2016, at 3:37 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    I agree with =
Phil that the client can=E2=80=99t trust any abstract identifier that it =
might get from a bad RS unless it is were a URI that the client or AS =
could deference to get a list of the concrete URI for the RS.

    That seems like a lot of =
work that clients are unlikely to do.

    A AS might do it if it wanted to look =
up the identifier for a given resource. 

    Something like do get on resource get =
back Abstract identifier (probably well known location, as recently =
pointed out in another thread you can=E2=80=99t allow it to point to =
user content.) 

    The AS gets the file and maps the uri to a abstract =
identifier for audience.

    I guess that would be one way that you could map AS URI to a =
abstract identifier, but I wouldn=E2=80=99t want to count on clients =
doing it.

    John =
B.





    On Mar =
16, 2016, at 3:46 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    George,

    Thanks. It would be good =
to get a draft that sketches out the overall picture of this for BA =E2=80=
=94 even if in very rough form given the deadline is monday.  Or, =
maybe just a PPT walkthru.

    Interested to see what comes out.

    




    

    

    On Mar 16, 2016, at 11:29 AM, George Fletcher <gffletch@aol.com> =
wrote:

    
 =20
    
 =20
  
    
    Inline...
    
    
    
    
    On 3/16/16 2:16 PM, Phil Hunt =
wrote:
    
    
    
    
    
      
      
    
      
    
        
    
          
    
            
    
                
    
                  
    
                    
    
                      
    Phil
    
                      

    
                      
    
                      
    @independentid
    
                      
    www.independentid.com
    
                    
    
                  
    
                
    
                  phil.hunt@oracle.com
    
            

    
            
    
          
    
          
    
        
    
        
    
        
    
      
    
      
    
      
    
        
    
          
    On Mar 16, 2016, at 10:59 AM, George Fletcher
            <gffletch@aol.com> =
wrote:
    
          
    
          

    
            
    
            
    On 3/16/16 12:20 PM, Phil Hunt (IDM)
              wrote:
    
            
    
            
    
              
    George
    
              

    
              
    
              
    Very good question...
    
              

    
              
    
              
    I considered that the RS metadata =
discovery
                could be fake. 
    
              
    
            
    
            Same way that the
              'iss' claim must "match" the url used to retrieve the
              metadata would apply to the 'rsid' claim
    
              -- I think that should suffice to ensuring the 'rsid'
              identifier can't be spoofed by another site
    
            
    
        
    
        

    
        
    
        So the attacker makes iss and url match for the resource
        discovery. Yet the AS service provider doesn=E2=80=99t know =
where the
        client is using the tokens.  How would the client or the AS
        detect that the wrong iss was given?
    
    
    
    Because if the attacker makes the rsid and the url match, then the
    client will submit an rsid that isn't "registered" with the AS and
    the AS won't issue the token. This assumes the client is not talking
    to an evil AS (as there are other mitigations for that case).
    
    
    
      

    
        
    
          
    
            
    
              

    
              
    
              
    So the final step in configuration
                validation is to bind the relationship between as and rs
                discovery together to confirm the relationship is =
valid. 
    
              
    
            
    
            And what I'd like to see is the 'rsid' value used
              to represent the RS rather than some unique endpoint (even
              if wildcards are allowed)
    
          
    
        
    
        

    
        
    
        Long term, I think this would be better. Do we have a way to
        issue RSID values in the works?
    
    
    
    No, but that is what this email thread is contemplating:) Just as
    the AS iss value is selfdefined by the AS, the rsid should be
    selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
    is a mirror of how the AS 'iss' claim is defined for the AS in it's
    metadata.
    
    
    
      

    
      
    
      
    That said, I would have thought this is more =
ownerous than
        checking *.example.com matches the =
given URL by the client.
    
      
    
    
    
    My problem with the URL level checking is that a RS may legitimately
    have endpoints on multiple domains. An RS may move endpoints from
    one domain to another (say when moving from version 1 to version 2
    of an API). Using the rsid for audience restriction and as an
    indirect mechanism for specifying actual endpoints, the RS has a
    much looser coupling with the AS.
    
    
    
    AS we move into "federated authorization" meaning that an RS
    outsources it's API authorization to one or more AS's, this will
    become more important.
    
    
    
      
    
        
    
          

    
            Another step that may be required is for the RS
              to return it's 'rsid' in the realm field of the
              WWW-Authenticate response header. This allows a client to
              discover metadata about the RS and it's endpoints. It also
              allows the client to determine if the 'rsid' returned by
              the RS matches the 'rsid' it is expecting.
    
          
    
        
    
        

    
        
    
        Agreed. This might work. But should the check be when the client
        asks for the configuration metadata or when the client asks for
        tokens?  I think it only needs to happen at config time.
    
      
    
    
    
    What I see here is that the desire is to audience protect tokens. To
    do that, the audience need to be specified everytime a token is
    requested. I really don't the AS to have to manage the complex state
    of which audiences have previously been issued to refresh_tokens and
    then reconstruct the correct audience for a requested downscoped
    access_token. It's much simpler, since the client knows which RS
    it's going to send the token to, to provide that when requesting
    tokens.
    
    
    
    The complication comes when exchanging the code for the tokens, it
    needs to specify all possible audiences (rsid's) it might send the
    token to based on the requested scopes. There will be a fair amount
    of complex logic at the AS to ensure the correct behavior. I do
    worry about this complexity.
    
    
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    We are of course assuming that a hacker
                needs to use the real AS authorize endpoint to succeed
                in obtaining an access token(it can't be mitm'd). Once
                the grant is obtained by the client, the threat comes
                when the client uses the grant at a mitm'd token
                endpoint OR an access token at a mitm'd resource
                endpoint. 
    
              

    
              
    
              
    So the AS and its config set becomes the
                trust anchor. Binding allows us to extend trust to the
                RS discovery giving some assurance that a client has a
                correct set of endpoints including resource. 
    
              
    
            
    
            Are you recommending that the AS metadata provide
              a list of the 'rsid' supported by the AS?
    
          
    
        
    
        No.  I think that is a bad idea.  Better to use an =
identity
        oracle function and say, give me the config for rsid=3Dxyz
    
    
    
    Good :)
    
    
    
      

    
      
    
      
    That also allows a common AS discovery endpoint to =
actually
        do discovery for multiple AS systems.  E.g. to configure a
        client to a specific AS service designated by the customer
        paying for the resource service.  
    
      

    
      
    
      
    IOW. by providing a resource query, the meta-data =
config
        discovery actually looks more like discovery.  :-)
    
      
    
        
    
          
    
            
    
              

    
              
    
              
    John's solution requires translating aud =
to
                res url and changes to core oauth. He seems to imply
                there is a need for ongoing validation of resource. I'm
                not yet convinced that is really needed.  Maybe it =
is
                needed because the client could be convinced to follow a
                link embedded in a resource that is somehow not part of
                the defined audience?
    
              

    
              
    
              
    Thanks
    
                
    
                Phil
    
              

    
                On Mar 16, 2016, at 08:57, George Fletcher <gffletch@aol.com>
                wrote:
    
                
    
              
    
              
    
                
    So, in thinking about all this AS
                    restricting tokens to RS and "discovery" of RS
                    endpoints, etc. I wondered why we don't just
                    leverage RS metadata like we have AS metadata.
    
                    
    
                    For an AS we require an 'iss' claim to use as an
                    identifier of the AS. We could do the same with RS
                    metadata retrieving the metadata from a .well-known
                    location and including a claim of 'rsid' to use as
                    an identifier of the Resource Server.
    
                    
    
                    This 'rsid' identifier could then be used for
                    registration with the AS and presentation by the
                    client when requesting tokens.
    
                    
    
                    This provides a separation between an identifier for
                    a resource and the specific endpoints the token will
                    be sent to. A client could "discover" the necessary
                    endpoint on a periodic basis and use a single
                    identifier with the AS for any of the endpoints or
                    scopes supported by the RS. If desired the RS could
                    expose the supported scopes in the RS metadata =
file.
    
                    
    
                    Thoughts?
    
                    
    
                    Thanks,
    
                    George
    
                
    
              
    
              
    
                
    _______________________________________________
    
                  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



    =

--Apple-Mail=_EA443D6A-0575-4E4A-BD2D-3A77A1E48D38--

--Apple-Mail=_32326404-1D5E-4029-A59D-0ADCD1C90AD5
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTYyMzI4MjZaMCMGCSqGSIb3DQEJBDEWBBQNC4MqpeNNlyoGGmXPc9zw
8Ikf2jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBbVmY/dfrTsyuKwTD5nsl9HTTFmRjTKK4XSCqFkwcanj8sbanyaa5p
BTMWbwLvP8TvG1taXoV25Fu15WI96mfHBhSI1oQIo+4m0sCYFGrIqEjLzxreJeDLhvLZ0ostYvK2
/EjUzaRzZUFpFdEmGxYOdr/qB/pV0nlb/LoJNM1MVBUME4EJnBLeJCWy+iiYT2dC5QdVnQw+VgcL
ubmT4RF11WQN37DXCGjwuq0j6q6/6R5XwTSndDASY7l1d9J27i0R+ULeXEAeGi56mGf5oTBAGIz5
G6xFAzK+sTz/FxPp1tKH5QOFGH1btZCK0fQZX4bKOVAE7fzRElX7Q05XVj2vAAAAAAAA
--Apple-Mail=_32326404-1D5E-4029-A59D-0ADCD1C90AD5--


From nobody Wed Mar 16 16:50:50 2016
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 BD8BD12D6E6 for ; Wed, 16 Mar 2016 16:50:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 v3iazRHYt0tq for ; Wed, 16 Mar 2016 16:50:42 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 05E2212D6B9 for ; Wed, 16 Mar 2016 16:50:41 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id o6so28458996qkc.2 for ; Wed, 16 Mar 2016 16:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ThcfMMBTxF3rBgFqOBHVRIO6dd/agWg1K4Ubv1B17/8=; b=PgYs6iC+kMwTUTS65S+rEM5hkhLp3jOb4c4pfSWEmTy83yJ0yC47cS+inYIE9lr8uK WjVLH0MHZeLiz+twMNiikk4k0vfywH6VWK0h5ZSP1P4m/oaBUcquVjxTFzJ7EcxeY+6B m4NCu/utqoGC/nSFiyu7uzcklpZRHcHWILU/1w22L7bdG0Esq5hJT9j1/Vi0wA8GmPib B6cGqsc17T+Uuq7G81b45LEJESpuAgYWPANXh3ka2Er/OrbmVlgIEkUSl0Uf20+vsk1r SoZ8EORR+jnIkCXcyQ5HPrEm2UC5UKEdp7BCtVxg4jDhnVXH8wOZimAl77m3CMzrCxil xksA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ThcfMMBTxF3rBgFqOBHVRIO6dd/agWg1K4Ubv1B17/8=; b=LYJIgYWwz/g4NjtyOsNri8bDpVBUYH/UIm3jLDu8OBt4WKgtQ2J1GQGQj45yXwKX0J OVIhD+/VlgxMnGjgLKnWXbqR8berBzRdPYhGv7TWoSapCNCHr3mYVOkS0FDZ49h58TBz aJGlmOKv1OqQK70c+Z2lRCbGUvlkx/Wf3lyR1GKIG440frul94G5QmvhiIVfZlW/ztCk +SVHNtWQIY9xj13sGg+MIP2dr5HGPzb5IJI1yd23gXX3PeL0iQLK0SHiaHQCLAlyjWnR u1y/Lk2QMPVDLwJ6uYTC9CxO/hueJqKaHA8YsADxElzFTbTS+1HT95PJwFILr36cmbio 5obQ==
X-Gm-Message-State: AD7BkJLQKhfRiTED3ThU3sSXq0R1zRK8az0IkUFmmzfB5lzx80KcP7PTal+z9njBgx2WZQ==
X-Received: by 10.55.78.84 with SMTP id c81mr9898173qkb.85.1458172240987; Wed, 16 Mar 2016 16:50:40 -0700 (PDT)
Received: from [192.168.1.68] ([191.115.15.25]) by smtp.gmail.com with ESMTPSA id o62sm2603474qkl.28.2016.03.16.16.50.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 16:50:39 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_8FE1F88B-968A-48FE-803E-2FF3BFF804B6"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <4128BA28-F6B1-43E7-A6DB-8A8CC3425095@oracle.com>
Date: Wed, 16 Mar 2016 20:50:27 -0300
Message-Id: <7E321541-BD4F-4EE6-9831-4EAF407F4733@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>  <56E96D48.90704@aol.com>  <4128BA28-F6B1-43E7-A6DB-8A8CC3425095@oracle.com>
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Mar 2016 23:50:47 -0000

--Apple-Mail=_8FE1F88B-968A-48FE-803E-2FF3BFF804B6
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A40897A3-9921-455A-B34A-A5A1F10EAA1E"


--Apple-Mail=_A40897A3-9921-455A-B34A-A5A1F10EAA1E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If you recall in Darmstadt, the group decided that the mix up attack =
needed to be addressed without requiring discovery.

That is why I keep saying the are separate issues.

The proposed fix from the group for the AS confusion was to return a =
issuer and client_id from the authorization endpoint, so that the client =
can check the authorization response and determine if the response came =
from the same AS that it made it=E2=80=99=E2=80=99s request to.

This is predicated on the precondition that the attacker can =
modify/proxy the request , but not the response from the legitimate AS.

The client checks each response and compares the request issuer with the =
response issuer.   It requires the client to be configured with a issuer =
for each AS.

As a happy coincidence the issuer string is a HTTPS URI and could be =
used in a discovery spec to get the meta-data for the AS.

I think that is confusing people into thinking that the IdP mixup =
mitigation used discovery.  It doesn=E2=80=99t. =20

You are the one who is requiring discovery in your proposal.

I should point out that your proposal requires a trusted and validated =
issuer to be able to validate the RS.

If I were an attacker I could trick the client into registering with me =
I can give it my bad issuer-x and  it would talk to my bad web-finger =
and validate my bad RS at registration time.

On it=E2=80=99s own your discovery of the AS config and validation of =
the RS provides no improved security.

The client would still need to do per request validation of the issuer =
and client_id returned by the Authorization endpoint.

My proposal is to have the client send the RS URI to the AS and let it =
check with each request as well and skip the requirement for discovery.

Your proposal doesn=E2=80=99t remove the per authorization request =
check.

John B.


> On Mar 16, 2016, at 12:30 PM, Phil Hunt (IDM)  =
wrote:
>=20
> John,
>=20
> Mis configured token endpoint and resource endpoint is the same client =
misconfiguration issue where a client is mis-informed by mistake or =
mis-deed.=20
>=20
> Why do you propose to solve token endpoint in config discovery but =
feel resource endpoint must be reverified each time in the core =
protocol?=20
>=20
> Phil
>=20
> On Mar 16, 2016, at 07:46, John Bradley > wrote:
>=20
>> If the client sends the uri of the resource it intends to send the =
token to in the token request the bad guy would get only a token =
audianced to itself and not to good RS.=20
>>=20
>> You can't solve the problem of bearer tokens with multiple audiences =
leaking.   That is a risk inherent in using that sort of token.   =
Compromise in one RS will impact all of them.=20
>>=20
>> The only safe way with bearer to deal with a RS the AS dosen't trust =
a RS is to only have one audianced in the token. (or by introspection)
>>=20
>> We have always known that and left it up to clients to make sure they =
are secure by not sending tokens to bad RS.=20
>>=20
>> Now people want a AS check to prevent clients from being tricked if =
developers are given bad info statically or dynamically.
>>=20
>> What you are doing is safe as long as your developers don't make any =
mistakes.=20
>> If you want to be safe and not have to preconfigure the AS you need =
to use the refresh to get single audianced tokens, or PoP.
>>=20
>> John B.
>>=20
>> On Mar 16, 2016 11:27 AM, "George Fletcher" > wrote:
>>=20
>>=20
>> On 3/15/16 6:14 PM, John Bradley wrote:
>>> If the AS is audience restricting the tokens then it just needs to =
put the right audience in the token based on what the client is asking =
for. =20
>>> That is safe as the RS wouldn=E2=80=99t be able to replay the token =
someplace else.
>> So let's assuming a client sends a token audience restricted to =
GoodRS instead to EvilRS. When EvilRS replays the token at the GoodRS =
endpoint, how does GoodRS reject the token because when GoodRS sends the =
token to the AS for introspection (or does so itself) the token will be =
audience restricted to the GoodRS and it will process the token. The =
only way to prevent this is with client-authentication so that the =
presenter can be matched against who is allowed to present the token =
(aka PoP).
>>=20
>> In the pure bearer token model, I don't see how this can be prevented =
at the protocol level.
>>>=20
>>> That would need to be a AS policy if it wanted to do that for =
unknown RS.  =20
>>>=20
>>> Allowing more than one audience in a token is a convince but a well =
known security risk with bearer tokens.
>> True, but this means clients have to manage many tokens or call the =
token endpoint to get a "downscoped, audience restricted" token every =
time they need one. This is a very different model than what most people =
think of when they think of OAuth2. Not bad, just different:)
>>>=20
>>> A AS would probably want to have only one audience in a AT for a =
untrusted RS, but may allow multiple if they are all trusted.
>>>=20
>>> John B.
>>>=20
>>>=20
>>>> On Mar 15, 2016, at 6:28 PM, George Fletcher > wrote:
>>>>=20
>>>>=20
>>>> On 3/15/16 3:26 PM, John Bradley wrote:
>>>>> I think Phil and others are concerned that a developer might get =
bad info to put in the client , some out of band discovery goes wrong or =
the user is somehow tricked into specifying a bad resource to the =
client.
>>>>>=20
>>>>> So getting a bad resource is a touch hypothetical.=20
>>>> If we are really trying to solve this problem holistically, then we =
probably need to first describe the use cases we want to solve. I'm =
starting to wonder if we are all providing solutions to slightly =
different use cases.
>>>>>=20
>>>>> For Connect we could suppose that someone publishes a malicious =
discovery document listing themselves as the RS but all the other =
endpoints are at the good AS so the client registers, authorizes the =
user and gives the AT to the bad guy.  The confused client mitigation by =
returning client_id_and issuer from the authorization endpoint will stop =
the attack before the token can be given to the token endpoint or RS.
>>>> Agreed and I'm fine with this solution.
>>>>>=20
>>>>> So protecting the AT at this point is more for a unknown attack =
that would confuse whatever protocol/API that is using OAuth about what =
RS to use.
>>>> Yes. This is where we need to describe some use cases (preferably =
real vs contrived) before we propose solutions. In most cases the RS =
endpoints are hard coded into the client or maybe pulled from a =
different central config endpoint (which is fixed).
>>>>=20
>>>> That's why the only case I could think of is a client that works =
with multiple RS endpoints from different providers that server the same =
content (e.g. PortableContacts API). In this use case, the user of the =
client would need to enter the location of the RS they wanted to use and =
then the flow would start from there. In reality, most services like =
this would have a fixed set of RS's they work with and again it wouldn't =
be dynamic.
>>>>>=20
>>>>> In reality this is what PoP is supposed to be for.
>>>>>=20
>>>>> I guess the question is what short of PoP can we do to prevent the =
client leaking tokens to bad RS that confuse it via the application =
protocol.
>>>>>=20
>>>>> If we want to del with this in OAuth then we need to tell the AS =
where the token is going to be used or tel the client where the token =
can be used.=20
>>>>>=20
>>>>> I think letting the client tell the AS where it wants the token =
used having the AS construct a audience out of that is probably the best =
thing.  to get around having a pre-established relationship between the =
AS and RS.
>>>> Even if the client tells the AS where it wants to use the token =
(via some endpoint URL), the AS still needs to have a relationship with =
the RS (at a minimum as an endpointURL-to-RS map) otherwise how can it =
determine if it is allowed to issue an access token to the user for that =
RS. This map is what I want to avoid "building" into the AS. Do we need =
"dynamic RS registration" to support this?
>>>>=20
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>> On Mar 15, 2016, at 3:14 PM, George Fletcher > wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> I think Justin provided a good break down of the different =
aspects a client wants to specify about the requested token. (my =
paraphrase)
>>>>>>   1. what RS's the token will be used at
>>>>>>   2. authorization privilege requests
>>>>>>   3. token-timing adjustments
>>>>>>=20
>>>>>> I'm not sure passing the full endpoint to the AS will help with =
my concerns... The AS could potentially do a webfinger on the resource =
URI and determine if it's an RS that it supports... though that requires =
all RS's to support webfinger. What I really want to avoid is the AS =
having this list of URIs to RS that is almost assuredly to get out of =
sync.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 3/15/16 1:56 PM, John Bradley wrote:
>>>>>>> I think it is a AS policy decision if it should error or take =
the requested resource and issue a token audianced for that resource.
>>>>>> Actually, the error cases are interesting. What if the passed in =
resource/audience doesn't actually match a requested scope? Or some =
match and some don't? Is it better to send back a token with less =
capability? or error the entire request?
>>>>>>>=20
>>>>>>>=20
>>>>>>> I guess the question is how to transition from now to a future =
state.   If you cannot upgrade all the clients at once.
>>>>>>>=20
>>>>>>> A processing rule on the AS that allowed some clients to not =
send the requested resource , but would error out for other upgraded =
clients  with a "resource not allowed=E2=80=9D oauth error would work =
and not require the return of the resources. =20
>>>>>>>=20
>>>>>>> If you return the resources and let the client error if it is =
trying to send to the wrong endpoint that make upgrading easier, but =
gives less control to the AS.
>>>>>>>=20
>>>>>>> I could live with it ether way.
>>>>>>>=20
>>>>>>> The advantage of always sending it in the token request is that =
it allows the AS to do the mapping from a resource URI to one or more =
abstract audience for the token.
>>>>>> I thought Justin provided a good break down of the different =
aspects a client wants to specify about the requested token. (my =
paraphrase)
>>>>>>   1. what RS's the token will be used at
>>>>>>   2. authorization privilege requests
>>>>>>   3. token-timing adjustments
>>>>>>=20
>>>>>> The question is how does a client internally reference a resource =
server? If it's a fixed RS endpoint, then it sort of doesn't matter, the =
client isn't going to send the token to the wrong endpoint anyway and it =
can easily reference the audience by an abstract URI.
>>>>>>=20
>>>>>> If the client can dynamically find new RS's to interact with. How =
does that happen? Does the client get handed an endpoint to use? or does =
it do some sort of discovery to determine the endpoint? I suppose both =
are possible.
>>>>>>=20
>>>>>> Could we prescribe that the realm value of RFC 6750 error =
response be effectively a resource-service-id (like issuer for the AS). =
The client would then need to do discovery on that value to find the =
valid endpoints of the RS. This could be done once and the =
resource-service-id could be used as the "abstract" RS identifier. This =
requires no more discovery than adding an AS to the client.
>>>>>>>=20
>>>>>>> That might help address George=E2=80=99s concern.
>>>>>> I'm not sure passing the full endpoint to the AS will help with =
my concerns... The AS could potentially do a webfinger on the resource =
URI and determine if it's an RS that it supports... though that requires =
all RS's to support webfinger. What I really want to avoid is the AS =
having this map of URIs to RS that is almost assuredly to get out of =
sync.
>>>>>>>=20
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell < =
bcampbell@pingidentity.com =
> wrote:
>>>>>>>>=20
>>>>>>>> I was thinking it'd be simpler to error, if the requested =
resource(s) weren't okay. That puts the burden of checking in the AS. =
And doesn't add anything to the token or authorization response. I see =
the potential similarity to scope but not sure it's worth it.   =20
>>>>>>>>=20
>>>>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>>>>>> If the client specifies the resource it wants the token for, =
then the meta-data would not be required unless the resources the token =
is good at are different from the request. =20
>>>>>>>> Lat is the same logic as scopes.
>>>>>>>>=20
>>>>>>>> For backwards compatibility if the client is happy with the =
default resources based on scopes then I think it is a good idea to tell =
the client what the resources are in the response.
>>>>>>>>=20
>>>>>>>> I suspect that it is simpler with less optionality and always =
return the resources, even if they are not required.
>>>>>>>>=20
>>>>>>>> John B.
>>>>>>>>=20
>>>>>>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell < =
bcampbell@pingidentity.com =
> wrote:
>>>>>>>>>=20
>>>>>>>>> If the client specifies the desired audience(s)/resource(s), =
is that metadata to the client needed? The AS can audience restrict the =
token as needed or respond with an error if it can't or wont issue a =
token for the resource the client asked for.=20
>>>>>>>>>=20
>>>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>>>>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>>>>>=20
>>>>>>>>> The AS needs to infer an audience from the scopes snd/or have =
the client specify the desired audience.
>>>>>>>>>=20
>>>>>>>>> If the AT has a audience or audiences then as long as the =
endpoint URI are provided as meta-data with the token, the client can =
determine if it is sending the token to the correct place.
>>>>>>>>>=20
>>>>>>>>> I think Phil would prefer the server rather than the client do =
the check, but the client always needs to take some responsibility to =
not leak tokens giving them to the wrong RS or the code to the wrong =
token endpoint is leaking.
>>>>>>>>>=20
>>>>>>>>> I imagine that claims based access tokens are going to become =
more popular and the static relationship between one RS and one AS will =
not be the majority of deployments over time.=20
>>>>>>>>>=20
>>>>>>>>> In any case where the client is configured up front to know =
the RS and the AS it seems like that would not require Phil=E2=80=99s =
Solution, but that is the only case supported by that discovery.
>>>>>>>>>  =20
>>>>>>>>> If the client itself is bad there is not much you can do to =
stop it from passing on the AT in way way it wants.  That however is a =
different problem and needs claimed URI or attestations to prevent =
client spoofing.
>>>>>>>>> William and I are working on that in the mobile best practices =
draft.
>>>>>>>>>=20
>>>>>>>>> John B.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>>>>>>=20
>>>>>>>>>> I worry about two directions I see in this thread...
>>>>>>>>>>=20
>>>>>>>>>> 1. Client's accessing resources dynamically so that discovery =
is required to know the correct AS, etc. This is pretty much the classic =
use case for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>=20
>>>>>>>>>> 2. Creating a tight coupling between RS and AS such that RS =
endpoint changes must be continually communicated to the AS. If an RS =
supports multiple AS's then the RS has to deal with "guaranteed" =
delivery. The AS needs an endpoint to receive such communications. If =
not dynamic via APIs, then deployment of the new RS is bound by the =
associated AS's getting and deploying the new endpoints. Can both =
endpoints of the RS be supported within the AS for some period of time, =
etc. This is an operation nightmare and almost assuredly going to go =
wrong in production.
>>>>>>>>>>=20
>>>>>>>>>> Maybe an OAuth2 "audience binding" spec is what's needed for =
those deployments that require this. I believe that is what John Bradley =
is suggesting.
>>>>>>>>>>=20
>>>>>>>>>> Thanks,
>>>>>>>>>> George
>>>>>>>>>>=20
>>>>>>>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>>>>> +1, I've found the very same in OAuth deployments that I was =
involved in; the hard part is to give names and descriptions to these =
concepts so that they cover all use cases and can be applied =
unambiguously=20
>>>>>>>>>>>=20
>>>>>>>>>>> Hans.=20
>>>>>>>>>>>=20
>>>>>>>>>>> On 3/14/16 10:44 PM, Justin Richer wrote:=20
>>>>>>>>>>>> I agree that this is valuable, and not just for PoP. In all =
honesty,=20
>>>>>>>>>>>> it=E2=80=99s not even really required for PoP to function =
in many cases =E2=80=94 it=E2=80=99s=20
>>>>>>>>>>>> just an optimization for one particular kind of key =
distribution=20
>>>>>>>>>>>> mechanism in that case.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> In the years of deployment experience with OAuth 2, I think =
we=E2=80=99ve really=20
>>>>>>>>>>>> got three different kinds of things that currently get =
folded into=20
>>>>>>>>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try =
separating out better:=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>   - What things do I want to access? (photos, profile)=20
>>>>>>>>>>>>   - What actions do I want to take on these things? (read, =
write, delete)=20
>>>>>>>>>>>>   - How long do I want these tokens to work?=20
>>>>>>>>>>>> (offline_access/refresh_token, one time use, next hour, =
etc)=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> I think the first one is close to the audience/resource =
parameters that=20
>>>>>>>>>>>> have been bandied about a few times, including in the =
current token=20
>>>>>>>>>>>> exchange document. We should be consistent across drafts in =
that regard.=20
>>>>>>>>>>>> The second is more traditional scope-ish. The third has =
been patched in=20
>>>>>>>>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in =
certain APIs.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Just another vector to think about if we=E2=80=99re going =
to be adding things=20
>>>>>>>>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D=
 or both to the token requests.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>   =E2=80=94 Justin=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>>>>>>>>   =
> wrote:=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Yes I will work on another proposal for allowing clients =
to specify=20
>>>>>>>>>>>>> what resource they want a token for and providing the =
meta-data to the=20
>>>>>>>>>>>>> client about the resources that a token is valid for.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> We have part of it in the POP key distribution spec and =
talked about=20
>>>>>>>>>>>>> separating it, as it is used more places than just for =
assigning keys.=20
>>>>>>>>>>>>> I know some AS use different token formats for different =
RS so are=20
>>>>>>>>>>>>> all-ready needing to pass the resource in the request to =
avoid making=20
>>>>>>>>>>>>> a mess of scopes.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> John B.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) < =
phil.hunt@oracle.com =
=20
>>>>>>>>>>>>>>  =
 =
> wrote:=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Inline=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Phil=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley < =
ve7jtb@ve7jtb.com =20=

>>>>>>>>>>>>>>   =
> wrote:=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> We had two mandates.  One was to provide a spec for AS =
metadata.=20
>>>>>>>>>>>>>>> The other was to mitigate the client mixup attack.  The =
request was=20
>>>>>>>>>>>>>>> to do the latter without requiring the former for =
clients that don=E2=80=99t=20
>>>>>>>>>>>>>>> otherwise need discovery.=20
>>>>>>>>>>>>>> There is no mandate for any of this. See=20
>>>>>>>>>>>>>>  =
http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22=
.txt =
=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Returning the issuer and client_id from the =
authorization endpoint=20
>>>>>>>>>>>>>>> and the client checking them can be done by the client =
without=20
>>>>>>>>>>>>>>> discovery.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> How does this address the issue of whether the client is =
talking to=20
>>>>>>>>>>>>>> the wrong endpoint?=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Any client that has the resource and issuer hard coded =
probably=20
>>>>>>>>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>>>>>>>>> We agree=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> One of the things that a client will need discovery for =
is to find=20
>>>>>>>>>>>>>>> the RS, so requiring the client to know the RS URI =
before getting=20
>>>>>>>>>>>>>>> the AS config seems backwards to me.=20
>>>>>>>>>>>>>> How can you make an assumption on order? You seem to be =
conflating=20
>>>>>>>>>>>>>> authentication with authorization by assuming the =
identity drives=20
>>>>>>>>>>>>>> what the resource is.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> There are lots of applications that require user rights =
but are not=20
>>>>>>>>>>>>>> identify centric. For example a document service.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Unless the client tells the AS where it intends to use =
the token we=20
>>>>>>>>>>>>>>> will be leaving a security hole because the bearer =
tokens will have=20
>>>>>>>>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>>>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> True you are telling the AS (Webfinger service) what the =
RS is but=20
>>>>>>>>>>>>>>> that is not at a place that is useful in the token =
production process.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> This has nothing to do with token production.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> What we want to ensure is whether an honest client is =
correctly=20
>>>>>>>>>>>>>> configured and has not been mislead - eg by a phishing =
page.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> I also think there are use cases where the AS doesn=E2=80=99=
t know all the=20
>>>>>>>>>>>>>>> possible RS.   That is not something that a out of band =
check can=20
>>>>>>>>>>>>>>> address.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> May be. Lets identify them.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> There are also cases where a token might be good at =
multiple RS=20
>>>>>>>>>>>>>>> endpoints intentionally.=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>  In your solution the client would need to make a =
discovery request=20
>>>>>>>>>>>>>>> for each endpoint.=20
>>>>>>>>>>>>>> Sure. Otherwise how would it know if there is one AS or a =
pool of AS=20
>>>>>>>>>>>>>> servers assigned to each instance?=20
>>>>>>>>>>>>>>> Those requests lack the context of who the client and =
resource owner=20
>>>>>>>>>>>>>>> are.  I think that will be a problem in some use cases.=20=

>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Not sure I agree. This is about discovering a valid set =
of endpoints.=20
>>>>>>>>>>>>>> For mitm, we mainly want to check the hostname is =
correct. If a=20
>>>>>>>>>>>>>> client chooses evil.com   =
  the cert can be =
valid and=20
>>>>>>>>>>>>>> TLS will pass. How does it otherwise know it is supposed =
to talk to=20
>>>>>>>>>>>>>> res.example.com  =
 ?=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> If this is
>> ...
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =



--Apple-Mail=_A40897A3-9921-455A-B34A-A5A1F10EAA1E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

If you recall in Darmstadt, the group decided that the mix up =
attack needed to be addressed without requiring discovery.

    That is why I keep =
saying the are separate issues.

    The proposed fix from the group for the =
AS confusion was to return a issuer and client_id from the authorization =
endpoint, so that the client can check the authorization response and =
determine if the response came from the same AS that it made it=E2=80=99=E2=
=80=99s request to.

    This is predicated on the precondition that the attacker can =
modify/proxy the request , but not the response from the legitimate =
AS.

    The client =
checks each response and compares the request issuer with the response =
issuer.   It requires the client to be configured with a issuer for =
each AS.

    As a =
happy coincidence the issuer string is a HTTPS URI and could be used in =
a discovery spec to get the meta-data for the AS.
    I think that is confusing people into =
thinking that the IdP mixup mitigation used discovery.  It =
doesn=E2=80=99t.  

    You are the one who is requiring discovery in your =
proposal.

    I =
should point out that your proposal requires a trusted and validated =
issuer to be able to validate the RS.

    If I were an attacker I could trick the =
client into registering with me I can give it my bad issuer-x and =
 it would talk to my bad web-finger and validate my bad RS at =
registration time.

    On it=E2=80=99s own your discovery of the AS config and =
validation of the RS provides no improved security.

    The client would still =
need to do per request validation of the issuer and client_id returned =
by the Authorization endpoint.

    My proposal is to have the client send =
the RS URI to the AS and let it check with each request as well and skip =
the requirement for discovery.

    Your proposal doesn=E2=80=99t remove =
the per authorization request check.

    John B.


    On Mar 16, 2016, at 12:30 PM, =
Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    John,

    Mis configured token =
endpoint and resource endpoint is the same client misconfiguration issue =
where a client is mis-informed by mistake or mis-deed. 

    Why do you propose to =
solve token endpoint in config discovery but feel resource endpoint must =
be reverified each time in the core protocol? 

    Phil

    On Mar 16, 2016, at 07:46, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    If the client sends =
the uri of the resource it intends to send the token to in the token =
request the bad guy would get only a token audianced to itself and not =
to good RS.  
    You can't solve the =
problem of bearer tokens with multiple audiences leaking.   =
That is a risk inherent in using that sort of token.   =
Compromise in one RS will impact all of them.  
    The only safe way with bearer to deal with a RS the AS =
dosen't trust a RS is to only have one audianced in the token. (or by =
introspection)
    We have always known that =
and left it up to clients to make sure they are secure by not sending =
tokens to bad RS.  
    Now people want a =
AS check to prevent clients from being tricked if developers are given =
bad info statically or dynamically. 
    What =
you are doing is safe as long as your developers don't make any =
mistakes. 
    
If you want to be safe and not have to preconfigure the AS you need to =
use the refresh to get single audianced tokens, or PoP.
    John B. 
    

    On Mar 16, 2016 11:27 AM, "George Fletcher" =
<gffletch@aol.com> wrote:
    
 =20
   =20
 =20
  
    
    
    
    
    
    
    On 3/15/16 6:14 PM, John Bradley wrote:
    =

    
    
    
    
     =20
      If the AS is audience restricting the tokens then it just needs to
      put the right audience in the token based on what the client is
      asking for.  
      
    That is safe as the RS wouldn=E2=80=99t be able to =
replay
        the token someplace else.
    
    
    
    So let's assuming a client sends a token audience restricted to
    GoodRS instead to EvilRS. When EvilRS replays the token at the
    GoodRS endpoint, how does GoodRS reject the token because when
    GoodRS sends the token to the AS for introspection (or does so
    itself) the token will be audience restricted to the GoodRS and it
    will process the token. The only way to prevent this is with
    client-authentication so that the presenter can be matched against
    who is allowed to present the token (aka PoP).
    
    
    
    In the pure bearer token model, I don't see how this can be
    prevented at the protocol level.
    
    
    
      

    
      
    
      
    That would need to be a AS policy if it wanted to =
do
        that for unknown RS.   
    
      

    
      
    
      
    Allowing more than one audience in a token is a
        convince but a well known security risk with bearer =
tokens.
    
    
    
    True, but this means clients have to manage many tokens or call the
    token endpoint to get a "downscoped, audience restricted" token
    every time they need one. This is a very different model than what
    most people think of when they think of OAuth2. Not bad, just
    different:)
    
    
    
      

    
      
    
      
    A AS would probably want to have only one audience
        in a AT for a untrusted RS, but may allow multiple if they are
        all trusted.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 6:28 PM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
             =20
              
     
    
                
    On 3/15/16 3:26 PM, John
                  Bradley wrote:
    
                
    
                
    
                 =20
                  I think Phil and others are concerned that a developer
                  might get bad info to put in the client , some out of
                  band discovery goes wrong or the user is somehow
                  tricked into specifying a bad resource to the client.
                  

    
                  
    
                  
    So getting a bad resource is a touch
                    hypothetical. 
    
                  
    
                
    
                If we are really trying to solve this problem
                holistically, then we probably need to first describe
                the use cases we want to solve. I'm starting to wonder
                if we are all providing solutions to slightly different
                use cases.
    
                
    
                  

    
                  
    
                  
    For Connect we could suppose that
                    someone publishes a malicious discovery document
                    listing themselves as the RS but all the other
                    endpoints are at the good AS so the client
                    registers, authorizes the user and gives the AT to
                    the bad guy.  The confused client mitigation by
                    returning client_id_and issuer from the
                    authorization endpoint will stop the attack before
                    the token can be given to the token endpoint or =
RS.
    
                
    
                Agreed and I'm fine with this solution.
    
                
    
                  

    
                  
    
                  
    So protecting the AT at this point is
                    more for a unknown attack that would confuse
                    whatever protocol/API that is using OAuth about what
                    RS to use.
    
                
    
                Yes. This is where we need to describe some use cases
                (preferably real vs contrived) before we propose
                solutions. In most cases the RS endpoints are hard coded
                into the client or maybe pulled from a different central
                config endpoint (which is fixed).
    
                
    
                That's why the only case I could think of is a client
                that works with multiple RS endpoints from different
                providers that server the same content (e.g.
                PortableContacts API). In this use case, the user of the
                client would need to enter the location of the RS they
                wanted to use and then the flow would start from there.
                In reality, most services like this would have a fixed
                set of RS's they work with and again it wouldn't be
                dynamic.
    
                
    
                  

    
                  
    
                  
    In reality this is what PoP is =
supposed
                    to be for.
    
                  

    
                  
    
                  
    I guess the question is what short of
                    PoP can we do to prevent the client leaking tokens
                    to bad RS that confuse it via the application
                    protocol.
    
                  

    
                  
    
                  
    If we want to del with this in OAuth
                    then we need to tell the AS where the token is going
                    to be used or tel the client where the token can be
                    used. 
    
                  

    
                  
    
                  
    I think letting the client tell the AS
                    where it wants the token used having the AS
                    construct a audience out of that is probably the
                    best thing.  to get around having a =
pre-established
                    relationship between the AS and RS.
    
                
    
                Even if the client tells the AS where it wants to use
                the token (via some endpoint URL), the AS still needs to
                have a relationship with the RS (at a minimum as an
                endpointURL-to-RS map) otherwise how can it determine if
                it is allowed to issue an access token to the user for
                that RS. This map is what I want to avoid "building"
                into the AS. Do we need "dynamic RS registration" to
                support this?
    
                
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 3:14 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        

    
                            
    
                            I think Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used =
at
    
                              2. authorization privilege =
requests
    
                              3. token-timing adjustments
    
                            
    
                            I'm not sure passing the full endpoint to
                            the AS will help with my concerns... The AS
                            could potentially do a webfinger on the
                            resource URI and determine if it's an RS
                            that it supports... though that requires all
                            RS's to support webfinger. What I really
                            want to avoid is the AS having this list of
                            URIs to RS that is almost assuredly to get
                            out of sync.
    
                            
    
                            
    
                          
    
                          
    On
                            3/15/16 1:56 PM, John Bradley wrote:
    
                          
    
                          
    I think it is a AS policy decision
                            if it should error or take the requested
                            resource and issue a token audianced for
                            that resource.
    
                          Actually,
                            the error cases are interesting. What if the
                            passed in resource/audience doesn't actually
                            match a requested scope? Or some match and
                            some don't? Is it better to send back a
                            token with less capability? or error the
                            entire request?
                          
    
                            

    
                            
    
                            
    I guess the question is how =
to
                              transition from now to a future state. =
 
                              If you cannot upgrade all the clients at
                              once.
    
                            

    
                            
    
                            
    A processing rule on the AS
                              that allowed some clients to not send the
                              requested resource , but would error out
                              for other upgraded clients  with a
                              "resource not allowed=E2=80=9D oauth error =
would
                              work and not require the return of the
                              resources.  
    
                            

    
                            
    
                            
    If you return the resources
                              and let the client error if it is trying
                              to send to the wrong endpoint that make
                              upgrading easier, but gives less control
                              to the AS.
    
                            

    
                            
    
                            
    
                              
    
                                
    I could
                                    live with it ether way.
    
                                

    
                                
    
                                The advantage of always sending it in
                                the token request is that it allows the
                                AS to do the mapping from a resource URI
                                to one or more abstract audience for the
                                token.
    
                            
    
                          
    
                          I
                            thought Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used =
at
    
                              2. authorization privilege =
requests
    
                              3. token-timing adjustments
    
                            
    
                            The question is how does a client internally
                            reference a resource server? If it's a fixed
                            RS endpoint, then it sort of doesn't matter,
                            the client isn't going to send the token to
                            the wrong endpoint anyway and it can easily
                            reference the audience by an abstract =
URI.
    
                            
    
                            If the client can dynamically find new RS's
                            to interact with. How does that happen? Does
                            the client get handed an endpoint to use? or
                            does it do some sort of discovery to
                            determine the endpoint? I suppose both are
                            possible.
    
                            
    
                            Could we prescribe that the realm value of
                            RFC 6750 error response be effectively a
                            resource-service-id (like issuer for the
                            AS). The client would then need to do
                            discovery on that value to find the valid
                            endpoints of the RS. This could be done once
                            and the resource-service-id could be used as
                            the "abstract" RS identifier. This requires
                            no more discovery than adding an AS to the
                            client.
    
                              
                          
    
                            
    
                              

    
                              
    
                              
    That might help address
                                George=E2=80=99s concern.
    
                            
    
                          
    
                          I'm
                            not sure passing the full endpoint to the AS
                            will help with my concerns... The AS could
                            potentially do a webfinger on the resource
                            URI and determine if it's an RS that it
                            supports... though that requires all RS's to
                            support webfinger. What I really want to
                            avoid is the AS having this map of URIs to
                            RS that is almost assuredly to get out of
                            sync.
                          
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                              
    
                              

    
                                
    
                                  
    On Mar 15, 2016, at =
2:44
                                    PM, Brian Campbell <bcampbell@pingidentity.com>

                                    wrote:
    
                                  
    
                                  
    
                                    
    I was
                                      thinking it'd be simpler to error,
                                      if the requested resource(s)
                                      weren't okay. That puts the burden
                                      of checking in the AS. And doesn't
                                      add anything to the token or
                                      authorization response. I see the
                                      potential similarity to scope but
                                      not sure it's worth it.  =
  
    
                                    

    
                                      
    On Tue,
                                        Mar 15, 2016 at 11:37 AM, John
                                        Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                        
    
                                          
    If the client
                                            specifies the resource it
                                            wants the token for, then
                                            the meta-data would not be
                                            required unless the
                                            resources the token is good
                                            at are different from the
                                            request.  
                                            
    Lat is the
                                              same logic as =
scopes.
    
                                            

    
                                            
    
                                            
    For =
backwards
                                              compatibility if the
                                              client is happy with the
                                              default resources based on
                                              scopes then I think it is
                                              a good idea to tell the
                                              client what the resources
                                              are in the response.
    
                                            

    
                                            
    
                                            
    I suspect =
that
                                              it is simpler with less
                                              optionality and always
                                              return the resources, even
                                              if they are not =
required.
    
                                            

    
                                            
    
                                            
    John =
B.
    
                                            
    
                                              
    
                                                

    
                                                
    
                                                
    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:46 PM, Brian
                                                        Campbell <bcampbell@pingidentity.com>

                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
    If
                                                          the client
                                                          specifies the
                                                          desired
                                                          =
audience(s)/resource(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for. 
    
                                                          
    =

                                                          
    =

                                                          

    
                                                          
    On

                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                                          
    
                                                          
    Yes,

                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          

    
                                                          
    
                                                          
    The

                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          =
audience.
    
                                                          

    
                                                          
    
                                                          
    If

                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is =
leaking.
    
                                                          

    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over =
time. 
    
                                                          

    
                                                          
    
                                                          
    In

                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require =
Phil=E2=80=99s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          =
discovery.
    
                                                          
      
    
                                                          
    If

                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.  =
That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          =
spoofing.
    
                                                          
    William

                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          

    
                                                          
    
                                                          
    John

                                                          B.
    
                                                          

    
                                                          
    
                                                          

    
                                                          
    =

                                                          
    
                                                          
    On

                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher =
<gffletch@aol.com>

                                                          wrote:
    
                                                          
    
                                                          
    =

                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          =
communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    =

                                                          

    
                                                          
    On

                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          =
unambiguously 
    
                                                          
    
                                                          Hans. 
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: 
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty, 
    
                                                          it=E2=80=99s =
not even
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases =E2=80=
=94
                                                          it=E2=80=99s 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          =
distribution 
    
                                                          mechanism in
                                                          that =
case. 
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think =
we=E2=80=99ve
                                                          really 
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded =
into 
    
                                                          =E2=80=9Cscope=E2=
=80=9D that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: 
    
                                                          
    
                                                          
    
                                                            -
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile) 
    
                                                            -
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, =
delete) 
    
                                                            -
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? 
    
                                                          =
(offline_access/refresh_token,

                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          =
audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token 
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. 
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched =
in 
    
                                                          with things
                                                          like
                                                          =
=E2=80=9Coffline_access=E2=80=9D
                                                          in certain
                                                          APIs. 
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we=E2=80=99re =
going to
                                                          be adding
                                                          things 
    
                                                          like
                                                          =E2=80=9Caudienc=
e=E2=80=9D or
                                                          =E2=80=9Cresourc=
e=E2=80=9D or
                                                          both to the
                                                          token
                                                          requests. 
    
                                                          
    
                                                            =E2=80=94
                                                          Justin 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: 
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify 
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid =
for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked =
about 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. 
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are 
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid =
making 
    
                                                          a mess of
                                                          scopes. 
    
                                                          
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com 
    
                                                          <mailto:phil.hunt@oracle.com>>

                                                          wrote: 
    
                                                          
    
                                                          Inline 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: 
    
                                                          
    
                                                          
    We
                                                          had two
                                                          =
mandates.  One
                                                          was to provide
                                                          a spec for AS
                                                          metadata. 
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup =
attack. 
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don=E2=80=99t 
    
                                                          otherwise need
                                                          =
discovery. 
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                          http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-20=
16-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint 
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without 
    
                                                          =
discovery. 
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking =
to 
    
                                                          the wrong
                                                          endpoint? 
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded =
probably 
    
                                                          doesn=E2=80=99t =
need
                                                          =
discovery. 
    
                                                          
    
                                                          We agree 
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to =
find 
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before =
getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          =
conflating 
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives 
    
                                                          what the
                                                          resource =
is. 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are =
not 
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service. 
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have 
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. 
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have =
IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is =
but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process. 
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          =
production. 
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is =
correctly 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. 
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS =
doesn=E2=80=99t
                                                          know all =
the 
    
                                                          possible =
RS.  
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can 
    
                                                          address. 
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify =
them. 
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple =
RS 
    
                                                          endpoints
                                                          =
intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request 
    
                                                          for each
                                                          endpoint. 
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of =
AS 
    
                                                          servers
                                                          assigned to
                                                          each =
instance? 
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner 
    
                                                          are.  I =
think
                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. 
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          =
endpoints. 
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If =
a 
    
                                                          client =
chooses evil.com <http://evil.com/> the =
cert can be valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk =
to 
    
                                                          res.example.com <http://res.example.com/>? 
    
                                                          

    
                                                          If this is
             =

    ...
    

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

    =

--Apple-Mail=_A40897A3-9921-455A-B34A-A5A1F10EAA1E--

--Apple-Mail=_8FE1F88B-968A-48FE-803E-2FF3BFF804B6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTYyMzUwMjhaMCMGCSqGSIb3DQEJBDEWBBTDe4MqhKORNRWdT9C3hszM
dxIHzjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBpAh44G41yjzLVTLKz9idTjRYs8rgY/XnjAIx0fTEcCyr2dRCBuhHz
o/aJctDZmNcPWoSKRqiy5JiNSgY4BakvyMsv2W2YV8qToRcCYzEL44ZiGf8TybVJKIupz386q0St
SxnQhes/hlIxYJHOxJcDhj/qEe8p0+S+um9DUsyqT1uCw+W01RR+9lv8FhnNLb22VVUHqCd5abR9
vaAghsQDD9pD8EVJCLR9EF9s9XBYl3lp6qNPPcZSxgYV7cgxvIci7MEps9cCvPdtWF0w/wsQ83kD
OUg6bUECvXOFJhx7upiNK406UfjEQL2VxA0vppYiWNmRZsolSJkxAXaZ7OimAAAAAAAA
--Apple-Mail=_8FE1F88B-968A-48FE-803E-2FF3BFF804B6--


From nobody Wed Mar 16 17:05:32 2016
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 F2DB612D52F for ; Wed, 16 Mar 2016 17:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 53GKQeuH_Bs4 for ; Wed, 16 Mar 2016 17:05:27 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 8E85512D553 for ; Wed, 16 Mar 2016 17:05:26 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2H05M4G019746 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2016 00:05:23 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2H05MtR018092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2016 00:05:22 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2H05KE4020794; Thu, 17 Mar 2016 00:05:21 GMT
Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Mar 2016 17:05:18 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-75830F33-2774-4E6B-805B-CD715DD1CA21
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: <7E321541-BD4F-4EE6-9831-4EAF407F4733@ve7jtb.com>
Date: Wed, 16 Mar 2016 17:05:15 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <79223A97-A81E-4267-8068-A5C15F84DC0A@oracle.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>  <56E96D48.90704@aol.com>  <4128BA28-F6B1-43E7-A6DB-8A8CC3425095@oracle.com> <7E321541-BD4F-4EE6-9831-4EAF407F4733@ve7jtb.com>
To: John Bradley 
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 00:05:31 -0000

--Apple-Mail-75830F33-2774-4E6B-805B-CD715DD1CA21
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Nothing here has anything to do with mix-up. Thats another problem.=20

Phil

> On Mar 16, 2016, at 16:50, John Bradley  wrote:
>=20
> If you recall in Darmstadt, the group decided that the mix up attack neede=
d to be addressed without requiring discovery.
>=20
> That is why I keep saying the are separate issues.
>=20
> The proposed fix from the group for the AS confusion was to return a issue=
r and client_id from the authorization endpoint, so that the client can chec=
k the authorization response and determine if the response came from the sam=
e AS that it made it=E2=80=99=E2=80=99s request to.
>=20
> This is predicated on the precondition that the attacker can modify/proxy t=
he request , but not the response from the legitimate AS.
>=20
> The client checks each response and compares the request issuer with the r=
esponse issuer.   It requires the client to be configured with a issuer for e=
ach AS.
>=20
> As a happy coincidence the issuer string is a HTTPS URI and could be used i=
n a discovery spec to get the meta-data for the AS.
>=20
> I think that is confusing people into thinking that the IdP mixup mitigati=
on used discovery.  It doesn=E2=80=99t.=20
>=20
> You are the one who is requiring discovery in your proposal.
>=20
> I should point out that your proposal requires a trusted and validated iss=
uer to be able to validate the RS.
>=20
> If I were an attacker I could trick the client into registering with me I c=
an give it my bad issuer-x and  it would talk to my bad web-finger and valid=
ate my bad RS at registration time.
>=20
> On it=E2=80=99s own your discovery of the AS config and validation of the R=
S provides no improved security.
>=20
> The client would still need to do per request validation of the issuer and=
 client_id returned by the Authorization endpoint.
>=20
> My proposal is to have the client send the RS URI to the AS and let it che=
ck with each request as well and skip the requirement for discovery.
>=20
> Your proposal doesn=E2=80=99t remove the per authorization request check.
>=20
> John B.
>=20
>=20
>> On Mar 16, 2016, at 12:30 PM, Phil Hunt (IDM)  wrot=
e:
>>=20
>> John,
>>=20
>> Mis configured token endpoint and resource endpoint is the same client mi=
sconfiguration issue where a client is mis-informed by mistake or mis-deed.=20=

>>=20
>> Why do you propose to solve token endpoint in config discovery but feel r=
esource endpoint must be reverified each time in the core protocol?=20
>>=20
>> Phil
>>=20
>>> On Mar 16, 2016, at 07:46, John Bradley  wrote:
>>>=20
>>> If the client sends the uri of the resource it intends to send the token=
 to in the token request the bad guy would get only a token audianced to its=
elf and not to good RS.=20
>>>=20
>>> You can't solve the problem of bearer tokens with multiple audiences lea=
king.   That is a risk inherent in using that sort of token.   Compromise in=
 one RS will impact all of them.=20
>>>=20
>>> The only safe way with bearer to deal with a RS the AS dosen't trust a R=
S is to only have one audianced in the token. (or by introspection)
>>>=20
>>> We have always known that and left it up to clients to make sure they ar=
e secure by not sending tokens to bad RS.=20
>>>=20
>>> Now people want a AS check to prevent clients from being tricked if deve=
lopers are given bad info statically or dynamically.
>>>=20
>>> What you are doing is safe as long as your developers don't make any mis=
takes.=20
>>> If you want to be safe and not have to preconfigure the AS you need to u=
se the refresh to get single audianced tokens, or PoP.
>>>=20
>>> John B.
>>>=20
>>>> On Mar 16, 2016 11:27 AM, "George Fletcher"  wrote:
>>>>=20
>>>>=20
>>>>> On 3/15/16 6:14 PM, John Bradley wrote:
>>>>> If the AS is audience restricting the tokens then it just needs to put=
 the right audience in the token based on what the client is asking for. =20=

>>>>> That is safe as the RS wouldn=E2=80=99t be able to replay the token so=
meplace else.
>>>> So let's assuming a client sends a token audience restricted to GoodRS i=
nstead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, how d=
oes GoodRS reject the token because when GoodRS sends the token to the AS fo=
r introspection (or does so itself) the token will be audience restricted to=
 the GoodRS and it will process the token. The only way to prevent this is w=
ith client-authentication so that the presenter can be matched against who i=
s allowed to present the token (aka PoP).
>>>>=20
>>>> In the pure bearer token model, I don't see how this can be prevented a=
t the protocol level.
>>>>>=20
>>>>> That would need to be a AS policy if it wanted to do that for unknown R=
S.  =20
>>>>>=20
>>>>> Allowing more than one audience in a token is a convince but a well kn=
own security risk with bearer tokens.
>>>> True, but this means clients have to manage many tokens or call the tok=
en endpoint to get a "downscoped, audience restricted" token every time they=
 need one. This is a very different model than what most people think of whe=
n they think of OAuth2. Not bad, just different:)
>>>>>=20
>>>>> A AS would probably want to have only one audience in a AT for a untru=
sted RS, but may allow multiple if they are all trusted.
>>>>>=20
>>>>> John B.
>>>>>=20
>>>>>=20
>>>>>> On Mar 15, 2016, at 6:28 PM, George Fletcher  wrote=
:
>>>>>>=20
>>>>>>=20
>>>>>>> On 3/15/16 3:26 PM, John Bradley wrote:
>>>>>>> I think Phil and others are concerned that a developer might get bad=
 info to put in the client , some out of band discovery goes wrong or the us=
er is somehow tricked into specifying a bad resource to the client.
>>>>>>>=20
>>>>>>> So getting a bad resource is a touch hypothetical.
>>>>>> If we are really trying to solve this problem holistically, then we p=
robably need to first describe the use cases we want to solve. I'm starting t=
o wonder if we are all providing solutions to slightly different use cases.
>>>>>>>=20
>>>>>>> For Connect we could suppose that someone publishes a malicious disc=
overy document listing themselves as the RS but all the other endpoints are a=
t the good AS so the client registers, authorizes the user and gives the AT t=
o the bad guy.  The confused client mitigation by returning client_id_and is=
suer from the authorization endpoint will stop the attack before the token c=
an be given to the token endpoint or RS.
>>>>>> Agreed and I'm fine with this solution.
>>>>>>>=20
>>>>>>> So protecting the AT at this point is more for a unknown attack that=
 would confuse whatever protocol/API that is using OAuth about what RS to us=
e.
>>>>>> Yes. This is where we need to describe some use cases (preferably rea=
l vs contrived) before we propose solutions. In most cases the RS endpoints a=
re hard coded into the client or maybe pulled from a different central confi=
g endpoint (which is fixed).
>>>>>>=20
>>>>>> That's why the only case I could think of is a client that works with=
 multiple RS endpoints from different providers that server the same content=
 (e.g. PortableContacts API). In this use case, the user of the client would=
 need to enter the location of the RS they wanted to use and then the flow w=
ould start from there. In reality, most services like this would have a fixe=
d set of RS's they work with and again it wouldn't be dynamic.
>>>>>>>=20
>>>>>>> In reality this is what PoP is supposed to be for.
>>>>>>>=20
>>>>>>> I guess the question is what short of PoP can we do to prevent the c=
lient leaking tokens to bad RS that confuse it via the application protocol.=

>>>>>>>=20
>>>>>>> If we want to del with this in OAuth then we need to tell the AS whe=
re the token is going to be used or tel the client where the token can be us=
ed.=20
>>>>>>>=20
>>>>>>> I think letting the client tell the AS where it wants the token used=
 having the AS construct a audience out of that is probably the best thing. =
 to get around having a pre-established relationship between the AS and RS.
>>>>>> Even if the client tells the AS where it wants to use the token (via s=
ome endpoint URL), the AS still needs to have a relationship with the RS (at=
 a minimum as an endpointURL-to-RS map) otherwise how can it determine if it=
 is allowed to issue an access token to the user for that RS. This map is wh=
at I want to avoid "building" into the AS. Do we need "dynamic RS registrati=
on" to support this?
>>>>>>=20
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>>> On Mar 15, 2016, at 3:14 PM, George Fletcher  wro=
te:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> I think Justin provided a good break down of the different aspects a=
 client wants to specify about the requested token. (my paraphrase)
>>>>>>>>   1. what RS's the token will be used at
>>>>>>>>   2. authorization privilege requests
>>>>>>>>   3. token-timing adjustments
>>>>>>>>=20
>>>>>>>> I'm not sure passing the full endpoint to the AS will help with my c=
oncerns... The AS could potentially do a webfinger on the resource URI and d=
etermine if it's an RS that it supports... though that requires all RS's to s=
upport webfinger. What I really want to avoid is the AS having this list of U=
RIs to RS that is almost assuredly to get out of sync.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On 3/15/16 1:56 PM, John Bradley wrote:
>>>>>>>>> I think it is a AS policy decision if it should error or take the r=
equested resource and issue a token audianced for that resource.
>>>>>>>> Actually, the error cases are interesting. What if the passed in re=
source/audience doesn't actually match a requested scope? Or some match and s=
ome don't? Is it better to send back a token with less capability? or error t=
he entire request?
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> I guess the question is how to transition from now to a future sta=
te.   If you cannot upgrade all the clients at once.
>>>>>>>>>=20
>>>>>>>>> A processing rule on the AS that allowed some clients to not send t=
he requested resource , but would error out for other upgraded clients  with=
 a "resource not allowed=E2=80=9D oauth error would work and not require the=
 return of the resources. =20
>>>>>>>>>=20
>>>>>>>>> If you return the resources and let the client error if it is tryi=
ng to send to the wrong endpoint that make upgrading easier, but gives less c=
ontrol to the AS.
>>>>>>>>>=20
>>>>>>>>> I could live with it ether way.
>>>>>>>>>=20
>>>>>>>>> The advantage of always sending it in the token request is that it=
 allows the AS to do the mapping from a resource URI to one or more abstract=
 audience for the token.
>>>>>>>> I thought Justin provided a good break down of the different aspect=
s a client wants to specify about the requested token. (my paraphrase)
>>>>>>>>   1. what RS's the token will be used at
>>>>>>>>   2. authorization privilege requests
>>>>>>>>   3. token-timing adjustments
>>>>>>>>=20
>>>>>>>> The question is how does a client internally reference a resource s=
erver? If it's a fixed RS endpoint, then it sort of doesn't matter, the clie=
nt isn't going to send the token to the wrong endpoint anyway and it can eas=
ily reference the audience by an abstract URI.
>>>>>>>>=20
>>>>>>>> If the client can dynamically find new RS's to interact with. How d=
oes that happen? Does the client get handed an endpoint to use? or does it d=
o some sort of discovery to determine the endpoint? I suppose both are possi=
ble.
>>>>>>>>=20
>>>>>>>> Could we prescribe that the realm value of RFC 6750 error response b=
e effectively a resource-service-id (like issuer for the AS). The client wou=
ld then need to do discovery on that value to find the valid endpoints of th=
e RS. This could be done once and the resource-service-id could be used as t=
he "abstract" RS identifier. This requires no more discovery than adding an A=
S to the client.
>>>>>>>>>=20
>>>>>>>>> That might help address George=E2=80=99s concern.
>>>>>>>> I'm not sure passing the full endpoint to the AS will help with my c=
oncerns... The AS could potentially do a webfinger on the resource URI and d=
etermine if it's an RS that it supports... though that requires all RS's to s=
upport webfinger. What I really want to avoid is the AS having this map of U=
RIs to RS that is almost assuredly to get out of sync.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> John B.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell  wrote:
>>>>>>>>>>=20
>>>>>>>>>> I was thinking it'd be simpler to error, if the requested resourc=
e(s) weren't okay. That puts the burden of checking in the AS. And doesn't a=
dd anything to the token or authorization response. I see the potential simi=
larity to scope but not sure it's worth it.   =20
>>>>>>>>>>=20
>>>>>>>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley  wrote:
>>>>>>>>>>> If the client specifies the resource it wants the token for, the=
n the meta-data would not be required unless the resources the token is good=
 at are different from the request. =20
>>>>>>>>>>> Lat is the same logic as scopes.
>>>>>>>>>>>=20
>>>>>>>>>>> For backwards compatibility if the client is happy with the defa=
ult resources based on scopes then I think it is a good idea to tell the cli=
ent what the resources are in the response.
>>>>>>>>>>>=20
>>>>>>>>>>> I suspect that it is simpler with less optionality and always re=
turn the resources, even if they are not required.
>>>>>>>>>>>=20
>>>>>>>>>>> John B.
>>>>>>>>>>>=20
>>>>>>>>>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell  wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>> If the client specifies the desired audience(s)/resource(s), is=
 that metadata to the client needed? The AS can audience restrict the token a=
s needed or respond with an error if it can't or wont issue a token for the r=
esource the client asked for.=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley  wrote:
>>>>>>>>>>>>> Yes,  I think bearer tokens with no audience are a bad idea.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> The AS needs to infer an audience from the scopes snd/or have t=
he client specify the desired audience.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> If the AT has a audience or audiences then as long as the endp=
oint URI are provided as meta-data with the token, the client can determine i=
f it is sending the token to the correct place.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I think Phil would prefer the server rather than the client do=
 the check, but the client always needs to take some responsibility to not l=
eak tokens giving them to the wrong RS or the code to the wrong token endpoi=
nt is leaking.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I imagine that claims based access tokens are going to become m=
ore popular and the static relationship between one RS and one AS will not b=
e the majority of deployments over time.=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> In any case where the client is configured up front to know th=
e RS and the AS it seems like that would not require Phil=E2=80=99s Solution=
, but that is the only case supported by that discovery.
>>>>>>>>>>>>>  =20
>>>>>>>>>>>>> If the client itself is bad there is not much you can do to st=
op it from passing on the AT in way way it wants.  That however is a differe=
nt problem and needs claimed URI or attestations to prevent client spoofing.=

>>>>>>>>>>>>> William and I are working on that in the                      =
                                     mobile best practices draft.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> John B.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher  wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I worry about two directions I see in this thread...
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> 1. Client's accessing resources dynamically so that discovery=
 is required to know the correct AS, etc. This is pretty much the classic us=
e case for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> 2. Creating a tight coupling between RS and AS such that RS e=
ndpoint changes must be continually communicated to the AS. If an RS support=
s multiple AS's then the RS has to deal with "guaranteed" delivery. The AS n=
eeds an endpoint to receive such communications. If not dynamic via APIs, th=
en deployment of the new RS is bound by the associated AS's getting and depl=
oying the new endpoints. Can both endpoints of the RS be supported within th=
e AS for some period of time, etc. This is an operation nightmare and almost=
 assuredly going to go wrong in production.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Maybe an OAuth2 "audience binding" spec is what's needed for t=
hose deployments that require this. I believe that is what John Bradley is s=
uggesting.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> George
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote:
>>>>>>>>>>>>>>> +1, I've found the very same in OAuth deployments that I was=
 involved in; the hard part is to give names and descriptions to these conce=
pts so that they cover all use cases and can be applied unambiguously=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Hans.=20
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> On 3/14/16 10:44 PM, Justin Richer                         =
                                  wrote:=20
>>>>>>>>>>>>>>>> I agree that this is valuable, and not just for PoP. In all=
 honesty,=20
>>>>>>>>>>>>>>>> it=E2=80=99s not even really required for PoP to function i=
n many cases =E2=80=94 it=E2=80=99s=20
>>>>>>>>>>>>>>>> just an optimization for one particular kind of key distrib=
ution=20
>>>>>>>>>>>>>>>> mechanism in that case.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> In the years of deployment experience with OAuth 2, I think=
 we=E2=80=99ve really=20
>>>>>>>>>>>>>>>> got three different kinds of things that currently get fold=
ed into=20
>>>>>>>>>>>>>>>> =E2=80=9Cscope=E2=80=9D that we might want to try separatin=
g out better:=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>   - What things do I want to access?                       =
                                    (photos, profile)=20
>>>>>>>>>>>>>>>>   - What actions do I want to take on these things? (read, w=
rite, delete)=20
>>>>>>>>>>>>>>>>   - How long do I want these tokens to work?=20
>>>>>>>>>>>>>>>> (offline_access/refresh_token, one time use, next hour, etc=
)=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> I think the first one is close to the audience/resource par=
ameters that=20
>>>>>>>>>>>>>>>> have been bandied about a few times, including in the curre=
nt token=20
>>>>>>>>>>>>>>>> exchange document. We should be consistent across drafts in=
 that regard.=20
>>>>>>>>>>>>>>>> The second is more traditional scope-ish. The third has bee=
n patched in=20
>>>>>>>>>>>>>>>> with things like =E2=80=9Coffline_access=E2=80=9D in certai=
n APIs.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> Just another vector to think about if we=E2=80=99re going t=
o be adding things=20
>>>>>>>>>>>>>>>> like =E2=80=9Caudience=E2=80=9D or =E2=80=9Cresource=E2=80=9D=
 or both to the token requests.=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>   =E2=80=94 Justin=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley >>>>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> Yes I will work on another proposal for allowing clients t=
o specify=20
>>>>>>>>>>>>>>>>> what resource they want a token for and providing the meta=
-data to the=20
>>>>>>>>>>>>>>>>> client about the resources that a token is valid for.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> We have part of it in the POP key distribution spec and ta=
lked about=20
>>>>>>>>>>>>>>>>> separating it, as it is used more places than just for ass=
igning keys.=20
>>>>>>>>>>>>>>>>> I know some AS use different token formats for different R=
S so are=20
>>>>>>>>>>>>>>>>> all-ready needing to pass the resource in the request to a=
void making=20
>>>>>>>>>>>>>>>>> a mess of scopes.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>> John B.=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> Inline=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> Phil=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley >>>>>>>>>>>>>>>>> > wrote:=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> We had two mandates.  One was to provide a spec for AS m=
etadata.=20
>>>>>>>>>>>>>>>>>>> The other was to mitigate the client mixup attack.  The r=
equest                                                           was=20
>>>>>>>>>>>>>>>>>>> to do the latter without requiring the former for client=
s that don=E2=80=99t=20
>>>>>>>>>>>>>>>>>>> otherwise need discovery.=20
>>>>>>>>>>>>>>>>>> There is no mandate for any of this. See=20
>>>>>>>>>>>>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oa=
uth-2016-01-22.txt=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> Returning the issuer and client_id from the authorizatio=
n endpoint=20
>>>>>>>>>>>>>>>>>>> and the client checking them can be done by the client w=
ithout=20
>>>>>>>>>>>>>>>>>>> discovery.=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> How does this address the issue of whether the client is t=
alking to=20
>>>>>>>>>>>>>>>>>> the wrong endpoint?=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> Any client that has the resource and issuer hard coded p=
robably=20
>>>>>>>>>>>>>>>>>>> doesn=E2=80=99t need discovery.=20
>>>>>>>>>>>>>>>>>> We agree=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> One of the things that a client will need discovery for i=
s to find=20
>>>>>>>>>>>>>>>>>>> the RS, so requiring the client to know the RS URI befor=
e getting=20
>>>>>>>>>>>>>>>>>>> the AS config seems backwards to me.=20
>>>>>>>>>>>>>>>>>> How can you make an assumption on order? You seem to be c=
onflating=20
>>>>>>>>>>>>>>>>>> authentication with authorization by assuming the identit=
y drives=20
>>>>>>>>>>>>>>>>>> what the resource is.=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> There are lots of applications that require user rights b=
ut are not=20
>>>>>>>>>>>>>>>>>> identify centric. For example a document service.=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> Unless the client tells the AS where it intends to use t=
he token                                                           we=20
>>>>>>>>>>>>>>>>>>> will be leaving a security hole because the bearer token=
s will have=20
>>>>>>>>>>>>>>>>>>> too loose an audience if they have one at all.=20
>>>>>>>>>>>>>>>>>> This is the biggest risk we have IMHO.=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> True you are telling the AS (Webfinger service) what the=
 RS is but=20
>>>>>>>>>>>>>>>>>>> that is not at a place that is useful in the token produ=
ction process.=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> This has nothing to do with token production.=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> What we want to ensure is whether an honest client is cor=
rectly=20
>>>>>>>>>>>>>>>>>> configured and has not been mislead - eg by a phishing pa=
ge.=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> I also think there are use cases where the AS doesn=E2=80=
=99t know all the=20
>>>>>>>>>>>>>>>>>>> possible RS.   That is not something that a out of band c=
heck can=20
>>>>>>>>>>>>>>>>>>> address.=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> May be. Lets identify them.=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> There are also cases where a token might be good at mult=
iple RS=20
>>>>>>>>>>>>>>>>>>> endpoints intentionally.=20
>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>>  In your solution the client would need to make a discov=
ery request=20
>>>>>>>>>>>>>>>>>>> for each endpoint.=20
>>>>>>>>>>>>>>>>>> Sure. Otherwise how would it know if there is one AS or a=
 pool of AS=20
>>>>>>>>>>>>>>>>>> servers assigned to each instance?=20
>>>>>>>>>>>>>>>>>>> Those requests lack the context of who the client and re=
source owner=20
>>>>>>>>>>>>>>>>>>> are.  I think that will be a problem in some use cases.=20=

>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>> Not sure I agree. This is about discovering a valid set o=
f endpoints.=20
>>>>>>>>>>>>>>>>>> For mitm, we mainly want to check the hostname is correct=
. If a=20
>>>>>>>>>>>>>>>>>> client chooses evil.com  the cert can b=
e valid and=20
>>>>>>>>>>>>>>>>>> TLS will pass. How does it otherwise know it is supposed t=
o talk to=20
>>>>>>>>>>>>>>>>>> res.example.com ?=20
>>>>>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>>>>> If this is
>>>> ...
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-75830F33-2774-4E6B-805B-CD715DD1CA21
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Nothing here has anything to do with m=
ix-up. Thats another problem. 

    Phil

    On Mar 16, 201=
6, at 16:50, John Bradley <ve7jtb@ve=
7jtb.com> wrote:

    If you recal=
l in Darmstadt, the group decided that the mix up attack needed to be addres=
sed without requiring discovery.

    That is why I keep saying the are separate issues.

    The proposed fix from the group for t=
he AS confusion was to return a issuer and client_id from the authorization e=
ndpoint, so that the client can check the authorization response and determi=
ne if the response came from the same AS that it made it=E2=80=99=E2=80=99s r=
equest to.

    This is=
 predicated on the precondition that the attacker can modify/proxy the reque=
st , but not the response from the legitimate AS.

    The client checks each response and compares=
 the request issuer with the response issuer.   It requires the client t=
o be configured with a issuer for each AS.

    As a happy coincidence the issuer string is a HTTPS=
 URI and could be used in a discovery spec to get the meta-data for the AS.<=
/div>

    I think that is co=
nfusing people into thinking that the IdP mixup mitigation used discovery. &=
nbsp;It doesn=E2=80=99t.  

    You are the one who is requiring discovery in your proposal.

    I should point out t=
hat your proposal requires a trusted and validated issuer to be able to vali=
date the RS.

    If I w=
ere an attacker I could trick the client into registering with me I can give=
 it my bad issuer-x and  it would talk to my bad web-finger and validat=
e my bad RS at registration time.

    =

    On it=E2=80=99s own your discovery of the AS config and vali=
dation of the RS provides no improved security.

    The client would still need to do per request v=
alidation of the issuer and client_id returned by the Authorization endpoint=
.

    My proposal is t=
o have the client send the RS URI to the AS and let it check with each reque=
st as well and skip the requirement for discovery.

    Your proposal doesn=E2=80=99t remove the per=
 authorization request check.

    John B.


    O=
n Mar 16, 2016, at 12:30 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    John,

    Mis configured token endpoint and resource endpoint is the same clien=
t misconfiguration issue where a client is mis-informed by mistake or mis-de=
ed. 

    Why do y=
ou propose to solve token endpoint in config discovery but feel resource end=
point must be reverified each time in the core protocol? 

    Phil

    On Mar 16, 2016, at 07:46, John Bradley <ve7jtb@ve7jtb.com> wrote:

    If the client sends the uri of the resource it intends to send t=
he token to in the token request the bad guy would get only a token audiance=
d to itself and not to good RS.  
    You can'=
t solve the problem of bearer tokens with multiple audiences leaking. &=
nbsp; That is a risk inherent in using that sort of token.   Compr=
omise in one RS will impact all of them.  
    The only safe way with bearer to deal with a RS the AS dosen't trust a RS i=
s to only have one audianced in the token. (or by introspection)
    We have always known that and left it up to clients to make=
 sure they are secure by not sending tokens to bad RS.  
    Now people want a AS check to prevent clients from being tric=
ked if developers are given bad info statically or dynamically. 
    What you are doing is safe as long as your developers don't=
 make any mistakes. 
    
If you want to be safe and not have to preconfigure the AS you need to use t=
he refresh to get single audianced tokens, or PoP.
    John B. 
    

    On Mar 16, 2016 11:27 AM, "George Fletcher" <<=
a href=3D"mailto:gffletch@aol.com" class=3D"">gffletch@aol.com> wrote=
:
    
 =20
   =20
 =20
  
    
    
    
    
    
    
    On 3/15/16 6:14 PM, John Bradley wrote:
    
    
    
    
    
     =20
      If the AS is audience restricting the tokens then it just needs to
      put the right audience in the token based on what the client is
      asking for.  
      
    That is safe as the RS wouldn=E2=80=99t be able to rep=
lay
        the token someplace else.
    
    
    
    So let's assuming a client sends a token audience restricted to
    GoodRS instead to EvilRS. When EvilRS replays the token at the
    GoodRS endpoint, how does GoodRS reject the token because when
    GoodRS sends the token to the AS for introspection (or does so
    itself) the token will be audience restricted to the GoodRS and it
    will process the token. The only way to prevent this is with
    client-authentication so that the presenter can be matched against
    who is allowed to present the token (aka PoP).
    
    
    
    In the pure bearer token model, I don't see how this can be
    prevented at the protocol level.
    
    
    
      

    
      
    
      
    That would need to be a AS policy if it wanted to do
        that for unknown RS.   
    
      

    
      
    
      
    Allowing more than one audience in a token is a
        convince but a well known security risk with bearer tokens.
    
    
    
    True, but this means clients have to manage many tokens or call the
    token endpoint to get a "downscoped, audience restricted" token
    every time they need one. This is a very different model than what
    most people think of when they think of OAuth2. Not bad, just
    different:)
    
    
    
      

    
      
    
      
    A AS would probably want to have only one audience
        in a AT for a untrusted RS, but may allow multiple if they are
        all trusted.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 15, 2016, at 6:28 PM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    
             =20
              
     
    
                
    On 3/15/16 3:26 PM, John
                  Bradley wrote:
    
                
    
                
    
                 =20
                  I think Phil and others are concerned that a developer
                  might get bad info to put in the client , some out of
                  band discovery goes wrong or the user is somehow
                  tricked into specifying a bad resource to the client.
                  

    
                  
    
                  
    So getting a bad resource is a touch
                    hypothetical. 
    
                  
    
                
    
                If we are really trying to solve this problem
                holistically, then we probably need to first describe
                the use cases we want to solve. I'm starting to wonder
                if we are all providing solutions to slightly different
                use cases.
    
                
    
                  

    
                  
    
                  
    For Connect we could suppose that
                    someone publishes a malicious discovery document
                    listing themselves as the RS but all the other
                    endpoints are at the good AS so the client
                    registers, authorizes the user and gives the AT to
                    the bad guy.  The confused client mitigation by
                    returning client_id_and issuer from the
                    authorization endpoint will stop the attack before
                    the token can be given to the token endpoint or RS.
                
    
                Agreed and I'm fine with this solution.
    
                
    
                  

    
                  
    
                  
    So protecting the AT at this point is
                    more for a unknown attack that would confuse
                    whatever protocol/API that is using OAuth about what
                    RS to use.
    
                
    
                Yes. This is where we need to describe some use cases
                (preferably real vs contrived) before we propose
                solutions. In most cases the RS endpoints are hard coded
                into the client or maybe pulled from a different central
                config endpoint (which is fixed).
    
                
    
                That's why the only case I could think of is a client
                that works with multiple RS endpoints from different
                providers that server the same content (e.g.
                PortableContacts API). In this use case, the user of the
                client would need to enter the location of the RS they
                wanted to use and then the flow would start from there.
                In reality, most services like this would have a fixed
                set of RS's they work with and again it wouldn't be
                dynamic.
    
                
    
                  

    
                  
    
                  
    In reality this is what PoP is supposed
                    to be for.
    
                  

    
                  
    
                  
    I guess the question is what short of
                    PoP can we do to prevent the client leaking tokens
                    to bad RS that confuse it via the application
                    protocol.
    
                  

    
                  
    
                  
    If we want to del with this in OAuth
                    then we need to tell the AS where the token is going
                    to be used or tel the client where the token can be
                    used. 
    
                  

    
                  
    
                  
    I think letting the client tell the AS
                    where it wants the token used having the AS
                    construct a audience out of that is probably the
                    best thing.  to get around having a pre-established=

                    relationship between the AS and RS.
    
                
    
                Even if the client tells the AS where it wants to use
                the token (via some endpoint URL), the AS still needs to
                have a relationship with the RS (at a minimum as an
                endpointURL-to-RS map) otherwise how can it determine if
                it is allowed to issue an access token to the user for
                that RS. This map is what I want to avoid "building"
                into the AS. Do we need "dynamic RS registration" to
                support this?
    
                
    
                
    
                  

    
                  
    
                  
    John B.
    
                  

    
                    
    
                      
    
                        
    On Mar 15, 2016, at 3:14 PM,
                          George Fletcher <gffletch@aol.com>

                          wrote:
    
                        
    
                        

    
                            
    
                            I think Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            I'm not sure passing the full endpoint to
                            the AS will help with my concerns... The AS
                            could potentially do a webfinger on the
                            resource URI and determine if it's an RS
                            that it supports... though that requires all
                            RS's to support webfinger. What I really
                            want to avoid is the AS having this list of
                            URIs to RS that is almost assuredly to get
                            out of sync.
    
                            
    
                            
    
                          
    
                          
    On
                            3/15/16 1:56 PM, John Bradley wrote:
    
                          
    
                          
    I think it is a AS policy decision
                            if it should error or take the requested
                            resource and issue a token audianced for
                            that resource.
    
                          Actually,
                            the error cases are interesting. What if the
                            passed in resource/audience doesn't actually
                            match a requested scope? Or some match and
                            some don't? Is it better to send back a
                            token with less capability? or error the
                            entire request?
                          
    
                            

    
                            
    
                            
    I guess the question is how to
                              transition from now to a future state.  
                              If you cannot upgrade all the clients at
                              once.
    
                            

    
                            
    
                            
    A processing rule on the AS
                              that allowed some clients to not send the
                              requested resource , but would error out
                              for other upgraded clients  with a
                              "resource not allowed=E2=80=9D oauth error wou=
ld
                              work and not require the return of the
                              resources.  
    
                            

    
                            
    
                            
    If you return the resources
                              and let the client error if it is trying
                              to send to the wrong endpoint that make
                              upgrading easier, but gives less control
                              to the AS.
    
                            

    
                            
    
                            
    
                              
    
                                
    I could
                                    live with it ether way.
    
                                

    
                                
    
                                The advantage of always sending it in
                                the token request is that it allows the
                                AS to do the mapping from a resource URI
                                to one or more abstract audience for the
                                token.
    
                            
    
                          
    
                          I
                            thought Justin provided a good break down of
                            the different aspects a client wants to
                            specify about the requested token. (my
                            paraphrase)
    
                              1. what RS's the token will be used at
                              2. authorization privilege requests
    
                              3. token-timing adjustments
    
                            
    
                            The question is how does a client internally
                            reference a resource server? If it's a fixed
                            RS endpoint, then it sort of doesn't matter,
                            the client isn't going to send the token to
                            the wrong endpoint anyway and it can easily
                            reference the audience by an abstract URI.
    
                            
    
                            If the client can dynamically find new RS's
                            to interact with. How does that happen? Does
                            the client get handed an endpoint to use? or
                            does it do some sort of discovery to
                            determine the endpoint? I suppose both are
                            possible.
    
                            
    
                            Could we prescribe that the realm value of
                            RFC 6750 error response be effectively a
                            resource-service-id (like issuer for the
                            AS). The client would then need to do
                            discovery on that value to find the valid
                            endpoints of the RS. This could be done once
                            and the resource-service-id could be used as
                            the "abstract" RS identifier. This requires
                            no more discovery than adding an AS to the
                            client.
    
                              
                          
    
                            
    
                              

    
                              
    
                              
    That might help address
                                George=E2=80=99s concern.
    
                            
    
                          
    
                          I'm
                            not sure passing the full endpoint to the AS
                            will help with my concerns... The AS could
                            potentially do a webfinger on the resource
                            URI and determine if it's an RS that it
                            supports... though that requires all RS's to
                            support webfinger. What I really want to
                            avoid is the AS having this map of URIs to
                            RS that is almost assuredly to get out of
                            sync.
                          
    
                            
    
                              

    
                              
    
                              
    John B.
    
                              

    
                              
    
                              

    
                                
    
                                  
    On Mar 15, 2016, at 2:44
                                    PM, Brian Campbell <bcampbell@pingi=
dentity.com>

                                    wrote:
    
                                  
    
                                  
    
                                    
    I was
                                      thinking it'd be simpler to error,
                                      if the requested resource(s)
                                      weren't okay. That puts the burden
                                      of checking in the AS. And doesn't
                                      add anything to the token or
                                      authorization response. I see the
                                      potential similarity to scope but
                                      not sure it's worth it.    
    
                                    

    
                                      
    On Tue,
                                        Mar 15, 2016 at 11:37 AM, John
                                        Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                        
    
                                          
    If the client
                                            specifies the resource it
                                            wants the token for, then
                                            the meta-data would not be
                                            required unless the
                                            resources the token is good
                                            at are different from the
                                            request.  
                                            
    Lat is the
                                              same logic as scopes.
    
                                            

    
                                            
    
                                            
    For backwards
                                              compatibility if the
                                              client is happy with the
                                              default resources based on
                                              scopes then I think it is
                                              a good idea to tell the
                                              client what the resources
                                              are in the response.
    
                                            

    
                                            
    
                                            
    I suspect that
                                              it is simpler with less
                                              optionality and always
                                              return the resources, even
                                              if they are not required.
                                            

    
                                            
    
                                            
    John B.
    
                                            
    
                                              
    
                                                

    
                                                
    
                                                
    
                                                  
    
                                                    
    
                                                      
    On
                                                        Mar 15, 2016, at
                                                        12:46 PM, Brian
                                                        Campbell <bcamp=
bell@pingidentity.com>

                                                        wrote:
    
                                                      
    
                                                      
    
                                                        
    If
                                                          the client
                                                          specifies the
                                                          desired
                                                          audience(s)/resour=
ce(s),
                                                          is that
                                                          metadata to
                                                          the client
                                                          needed? The AS
                                                          can audience
                                                          restrict the
                                                          token as
                                                          needed or
                                                          respond with
                                                          an error if it
                                                          can't or wont
                                                          issue a token
                                                          for the
                                                          resource the
                                                          client asked
                                                          for. 
    
                                                          
    
                                                          
    
                                                          

    
                                                          
    On

                                                          Tue, Mar 15,
                                                          2016 at 9:37
                                                          AM, John
                                                          Bradley <ve7jtb@ve7jtb.com> wrote:
    
                                                          
    
                                                          
    Yes,

                                                           I think
                                                          bearer tokens
                                                          with no
                                                          audience are a
                                                          bad idea.
                                                          
    
                                                          
    
                                                          
    Th=
e

                                                          AS needs to
                                                          infer an
                                                          audience from
                                                          the scopes
                                                          snd/or have
                                                          the client
                                                          specify the
                                                          desired
                                                          audience.
    
                                                          
    
                                                          
    
                                                          
    If=


                                                          the AT has a
                                                          audience or
                                                          audiences then
                                                          as long as the
                                                          endpoint URI
                                                          are provided
                                                          as meta-data
                                                          with the
                                                          token, the
                                                          client can
                                                          determine if
                                                          it is sending
                                                          the token to
                                                          the correct
                                                          place.
    
                                                          
    
                                                          
    
                                                          
    I
                                                          think Phil
                                                          would prefer
                                                          the server
                                                          rather than
                                                          the client do
                                                          the check, but
                                                          the client
                                                          always needs
                                                          to take some
                                                          responsibility
                                                          to not leak
                                                          tokens giving
                                                          them to the
                                                          wrong RS or
                                                          the code to
                                                          the wrong
                                                          token endpoint
                                                          is leaking.
    
                                                          
    
                                                          
    
                                                          
    I
                                                          imagine that
                                                          claims based
                                                          access tokens
                                                          are going to
                                                          become more
                                                          popular and
                                                          the static
                                                          relationship
                                                          between one RS
                                                          and one AS
                                                          will not be
                                                          the majority
                                                          of deployments
                                                          over time. 
                                                          
    
                                                          
    
                                                          
    In=


                                                          any case where
                                                          the client is
                                                          configured up
                                                          front to know
                                                          the RS and the
                                                          AS it seems
                                                          like that
                                                          would not
                                                          require Phil=E2=80=
=99s
                                                          Solution, but
                                                          that is the
                                                          only case
                                                          supported by
                                                          that
                                                          discovery.
    
                                                          
    &n=
bsp; 
    
                                                          
    If=


                                                          the client
                                                          itself is bad
                                                          there is not
                                                          much you can
                                                          do to stop it
                                                          from passing
                                                          on the AT in
                                                          way way it
                                                          wants.  That
                                                          however is a
                                                          different
                                                          problem and
                                                          needs claimed
                                                          URI or
                                                          attestations
                                                          to prevent
                                                          client
                                                          spoofing.
    
                                                          
    Wi=
lliam

                                                          and I are
                                                          working on
                                                          that in the
                                                          mobile best
                                                          practices
                                                          draft.
    
                                                          
    
                                                          
    
                                                          
    Jo=
hn

                                                          B.
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On=


                                                          Mar 15, 2016,
                                                          at 12:09 PM,
                                                          George
                                                          Fletcher <gffletch@aol.com>=
;

                                                          wrote:
    
                                                          
    
                                                          
    
                                                          
    I
                                                          worry about
                                                          two directions
                                                          I see in this
                                                          thread...
    
                                                          
    
                                                          1. Client's
                                                          accessing
                                                          resources
                                                          dynamically so
                                                          that discovery
                                                          is required to
                                                          know the
                                                          correct AS,
                                                          etc. This is
                                                          pretty much
                                                          the classic
                                                          use case for
                                                          UMA and I'd
                                                          rather not
                                                          re-invent the
                                                          wheel.
    
                                                          
    
                                                          2. Creating a
                                                          tight coupling
                                                          between RS and
                                                          AS such that
                                                          RS endpoint
                                                          changes must
                                                          be continually
                                                          communicated
                                                          to the AS. If
                                                          an RS supports
                                                          multiple AS's
                                                          then the RS
                                                          has to deal
                                                          with
                                                          "guaranteed"
                                                          delivery. The
                                                          AS needs an
                                                          endpoint to
                                                          receive such
                                                          communications.
                                                          If not dynamic
                                                          via APIs, then
                                                          deployment of
                                                          the new RS is
                                                          bound by the
                                                          associated
                                                          AS's getting
                                                          and deploying
                                                          the new
                                                          endpoints. Can
                                                          both endpoints
                                                          of the RS be
                                                          supported
                                                          within the AS
                                                          for some
                                                          period of
                                                          time, etc.
                                                          This is an
                                                          operation
                                                          nightmare and
                                                          almost
                                                          assuredly
                                                          going to go
                                                          wrong in
                                                          production.
    
                                                          
    
                                                          Maybe an
                                                          OAuth2
                                                          "audience
                                                          binding" spec
                                                          is what's
                                                          needed for
                                                          those
                                                          deployments
                                                          that require
                                                          this. I
                                                          believe that
                                                          is what John
                                                          Bradley is
                                                          suggesting.
    
                                                          
    
                                                          Thanks,
    
                                                          George
    
                                                              
                                                          
    
                                                          
    
                                                          
    On=


                                                          3/14/16 7:29
                                                          PM, Hans
                                                          Zandbelt
                                                          wrote:
    
                                                          
    
                                                          
    +1,
                                                          I've found the
                                                          very same in
                                                          OAuth
                                                          deployments
                                                          that I was
                                                          involved in;
                                                          the hard part
                                                          is to give
                                                          names and
                                                          descriptions
                                                          to these
                                                          concepts so
                                                          that they
                                                          cover all use
                                                          cases and can
                                                          be applied
                                                          unambiguously 
    
                                                          
    
                                                          Hans. 
    
                                                          
    
                                                          On 3/14/16
                                                          10:44 PM,
                                                          Justin Richer
                                                          wrote: 
    
                                                          
    I
                                                          agree that
                                                          this is
                                                          valuable, and
                                                          not just for
                                                          PoP. In all
                                                          honesty, 
    
                                                          it=E2=80=99s not e=
ven
                                                          really
                                                          required for
                                                          PoP to
                                                          function in
                                                          many cases =E2=80=94=

                                                          it=E2=80=99s 
    
                                                          just an
                                                          optimization
                                                          for one
                                                          particular
                                                          kind of key
                                                          distribution 
    
                                                          mechanism in
                                                          that case. 
    
                                                          
    
                                                          In the years
                                                          of deployment
                                                          experience
                                                          with OAuth 2,
                                                          I think we=E2=80=99=
ve
                                                          really 
    
                                                          got three
                                                          different
                                                          kinds of
                                                          things that
                                                          currently get
                                                          folded into 
    
                                                          =E2=80=9Cscope=E2=80=
=9D that
                                                          we might want
                                                          to try
                                                          separating out
                                                          better: 
    
                                                          
    
                                                          
    
                                                            -
                                                          What things do
                                                          I want to
                                                          access?
                                                          (photos,
                                                          profile) 
    
                                                            -
                                                          What actions
                                                          do I want to
                                                          take on these
                                                          things? (read,
                                                          write, delete) 
    
                                                            -
                                                          How long do I
                                                          want these
                                                          tokens to
                                                          work? 
    
                                                          (offline_access/re=
fresh_token,

                                                          one time use,
                                                          next hour,
                                                          etc) 
    
                                                          
    
                                                          
    
                                                          I think the
                                                          first one is
                                                          close to the
                                                          audience/resource
                                                          parameters
                                                          that 
    
                                                          have been
                                                          bandied about
                                                          a few times,
                                                          including in
                                                          the current
                                                          token 
    
                                                          exchange
                                                          document. We
                                                          should be
                                                          consistent
                                                          across drafts
                                                          in that
                                                          regard. 
    
                                                          The second is
                                                          more
                                                          traditional
                                                          scope-ish. The
                                                          third has been
                                                          patched in 
    
                                                          with things
                                                          like
                                                          =E2=80=9Coffline_a=
ccess=E2=80=9D
                                                          in certain
                                                          APIs. 
    
                                                          
    
                                                          Just another
                                                          vector to
                                                          think about if
                                                          we=E2=80=99re goin=
g to
                                                          be adding
                                                          things 
    
                                                          like
                                                          =E2=80=9Caudience=E2=
=80=9D or
                                                          =E2=80=9Cresource=E2=
=80=9D or
                                                          both to the
                                                          token
                                                          requests. 
    
                                                          
    
                                                            =E2=80=94
                                                          Justin 
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 6:26 PM,
                                                          John Bradley
                                                          <ve7jtb@ve7jtb.com 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: 
    
                                                          
    
                                                          Yes I will
                                                          work on
                                                          another
                                                          proposal for
                                                          allowing
                                                          clients to
                                                          specify 
    
                                                          what resource
                                                          they want a
                                                          token for and
                                                          providing the
                                                          meta-data to
                                                          the 
    
                                                          client about
                                                          the resources
                                                          that a token
                                                          is valid for. 
    
                                                          
    
                                                          We have part
                                                          of it in the
                                                          POP key
                                                          distribution
                                                          spec and
                                                          talked about 
    
                                                          separating it,
                                                          as it is used
                                                          more places
                                                          than just for
                                                          assigning
                                                          keys. 
    
                                                          I know some AS
                                                          use different
                                                          token formats
                                                          for different
                                                          RS so are 
    
                                                          all-ready
                                                          needing to
                                                          pass the
                                                          resource in
                                                          the request to
                                                          avoid making 
    
                                                          a mess of
                                                          scopes. 
    
                                                          
    
                                                          John B. 
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    
                                                          
    On
                                                          Mar 14, 2016,
                                                          at 7:17 PM,
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com=
 
    
                                                          <mailto:phil.hunt@oracle.=
com>>

                                                          wrote: 
    
                                                          
    
                                                          Inline 
    
                                                          
    
                                                          Phil 
    
                                                          
    
                                                          On Mar 14,
                                                          2016, at
                                                          14:13, John
                                                          Bradley <ve7jtb@ve7jtb.com<=
span class=3D""> 
    
                                                          <mailto:ve7jtb@ve7jtb.com>>

                                                          wrote: 
    
                                                          
    
                                                          
    We
                                                          had two
                                                          mandates.  On=
e
                                                          was to provide
                                                          a spec for AS
                                                          metadata. 
    
                                                          The other was
                                                          to mitigate
                                                          the client
                                                          mixup attack. =
;
                                                          The request
                                                          was 
    
                                                          to do the
                                                          latter without
                                                          requiring the
                                                          former for
                                                          clients that
                                                          don=E2=80=99t 
    
                                                          otherwise need
                                                          discovery. 
    
                                                          
    
                                                          There is no
                                                          mandate for
                                                          any of this.
                                                          See 
    
                                                              http://t=
ools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2016-01-22.txt 
    
                                                          

    
                                                          Returning the
                                                          issuer and
                                                          client_id from
                                                          the
                                                          authorization
                                                          endpoint 
    
                                                          and the client
                                                          checking them
                                                          can be done by
                                                          the client
                                                          without 
    
                                                          discovery. 
    
                                                          
    
                                                          
    
                                                          How does this
                                                          address the
                                                          issue of
                                                          whether the
                                                          client is
                                                          talking to 
    
                                                          the wrong
                                                          endpoint? 
    
                                                          

    
                                                          Any client
                                                          that has the
                                                          resource and
                                                          issuer hard
                                                          coded probably 
    
                                                          doesn=E2=80=99t ne=
ed
                                                          discovery. 
    
                                                          
    
                                                          We agree 
    
                                                          
    
                                                          
    
                                                          
    One
                                                          of the things
                                                          that a client
                                                          will need
                                                          discovery for
                                                          is to find 
    
                                                          the RS, so
                                                          requiring the
                                                          client to know
                                                          the RS URI
                                                          before getting 
    
                                                          the AS config
                                                          seems
                                                          backwards to
                                                          me. 
    
                                                          
    
                                                          How can you
                                                          make an
                                                          assumption on
                                                          order? You
                                                          seem to be
                                                          conflating 
    
                                                          authentication
                                                          with
                                                          authorization
                                                          by assuming
                                                          the identity
                                                          drives 
    
                                                          what the
                                                          resource is. 
    
                                                          
    
                                                          There are lots
                                                          of
                                                          applications
                                                          that require
                                                          user rights
                                                          but are not 
    
                                                          identify
                                                          centric. For
                                                          example a
                                                          document
                                                          service. 
    
                                                          

    
                                                          Unless the
                                                          client tells
                                                          the AS where
                                                          it intends to
                                                          use the token
                                                          we 
    
                                                          will be
                                                          leaving a
                                                          security hole
                                                          because the
                                                          bearer tokens
                                                          will have 
    
                                                          too loose an
                                                          audience if
                                                          they have one
                                                          at all. 
    
                                                          
    
                                                          This is the
                                                          biggest risk
                                                          we have IMHO. 
    
                                                          

    
                                                          True you are
                                                          telling the AS
                                                          (Webfinger
                                                          service) what
                                                          the RS is but 
    
                                                          that is not at
                                                          a place that
                                                          is useful in
                                                          the token
                                                          production
                                                          process. 
    
                                                          
    
                                                          
    
                                                          This has
                                                          nothing to do
                                                          with token
                                                          production. 
    
                                                          
    
                                                          What we want
                                                          to ensure is
                                                          whether an
                                                          honest client
                                                          is correctly 
    
                                                          configured and
                                                          has not been
                                                          mislead - eg
                                                          by a phishing
                                                          page. 
    
                                                          

    
                                                          I also think
                                                          there are use
                                                          cases where
                                                          the AS doesn=E2=80=
=99t
                                                          know all the 
    
                                                          possible RS. =
 
                                                          That is not
                                                          something that
                                                          a out of band
                                                          check can 
    
                                                          address. 
    
                                                          
    
                                                          
    
                                                          May be. Lets
                                                          identify them. 
    
                                                          
    
                                                          
    There
                                                          are also cases
                                                          where a token
                                                          might be good
                                                          at multiple RS 
    
                                                          endpoints
                                                          intentionally. 
    
                                                          
    
                                                          
    
                                                          
     In
                                                          your solution
                                                          the client
                                                          would need to
                                                          make a
                                                          discovery
                                                          request 
    
                                                          for each
                                                          endpoint. 
    
                                                          
    
                                                          Sure.
                                                          Otherwise how
                                                          would it know
                                                          if there is
                                                          one AS or a
                                                          pool of AS 
    
                                                          servers
                                                          assigned to
                                                          each instance? 
    
                                                          
    Those
                                                          requests lack
                                                          the context of
                                                          who the client
                                                          and resource
                                                          owner 
    
                                                          are.  I think=

                                                          that will be a
                                                          problem in
                                                          some use
                                                          cases. 
    
                                                          
    
                                                          
    
                                                          Not sure I
                                                          agree. This is
                                                          about
                                                          discovering a
                                                          valid set of
                                                          endpoints. 
    
                                                          For mitm, we
                                                          mainly want to
                                                          check the
                                                          hostname is
                                                          correct. If a 
    
                                                          client chooses evil.com <http://evil.com/> =
the cert can be valid and 
    
                                                          TLS will pass.
                                                          How does it
                                                          otherwise know
                                                          it is supposed
                                                          to talk to 
    
                                                          res.example.com <http://res.example.com/>? <=
br class=3D"">
                                                          

    
                                                          If this is
             
    =

    ...
    

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

    =

--Apple-Mail-75830F33-2774-4E6B-805B-CD715DD1CA21--


From nobody Wed Mar 16 23:26:09 2016
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 6FB1A12D82D for ; Wed, 16 Mar 2016 23:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.009
X-Spam-Level: 
X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 uxcYK_QParNl for ; Wed, 16 Mar 2016 23:26:04 -0700 (PDT)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F9912D8B4 for ; Wed, 16 Mar 2016 23:26:03 -0700 (PDT)
Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs02.index.or.jp (Postfix) with SMTP id 6992E1968A1; Thu, 17 Mar 2016 15:26:02 +0900 (JST)
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp (unknown) with ESMTP id u2H6Q2I7019688; Thu, 17 Mar 2016 15:26:02 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u2H6Q1KC014870; Thu, 17 Mar 2016 15:26:01 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u2H6Q1Xh014869; Thu, 17 Mar 2016 15:26:01 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u2H6Q177014866; Thu, 17 Mar 2016 15:26:01 +0900
From: "Nat Sakimura" 
To: "'George Fletcher'" , "'John Bradley'" 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <1E57F72B-AE4B-4565-B976-A32EB5C61631@ve7jtb.com> <56E87E94.4060100@aol.com>
In-Reply-To: <56E87E94.4060100@aol.com>
Date: Thu, 17 Mar 2016 15:26:11 +0900
Message-ID: <007401d18015$e67d1280$b3773780$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01D18061.5667A0B0"
X-Mailer: Microsoft Outlook 15.0
Content-Language: ja
Thread-Index: AQHEZdZQi2eXWkFLB7/YhWzS03fSXgJWuf4XAglEkNwCjSWGNAFYrFPKAbVe4bICXCh0KgH9Nq5iAb7jtLQBi6IADAH79mgKAkDwxUwBM7kc/AJPnmsBAUtOk2wB8g7p1QGNdVcuAsaZ6E4DA4XRTJ5XvDsQ
X-MailAdviser: 20141126
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 06:26:08 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0075_01D18061.5667A0B0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Indeed, that=E2=80=99s what I suggested to Phil offline that we should =
draft a use case based requirement document. It looks to me that we are =
talking past each other with slightly different use-cases in mind.=20

=20

As far as I can tell, we do not have an agreement on the Requirements =
for discovery. We should first address it, then get back to the specific =
protocols.=20

=20

Best,=20

=20

Nat Sakimura

=20

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Wednesday, March 16, 2016 6:29 AM
To: John Bradley 
Cc:  
Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt

=20

(snip)=20

If we are really trying to solve this problem holistically, then we =
probably need to first describe the use cases we want to solve. I'm =
starting to wonder if we are all providing solutions to slightly =
different use cases.


(snip)

=20

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

=20


------=_NextPart_000_0075_01D18061.5667A0B0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    I=
ndeed, that=E2=80=99s what I suggested to Phil offline that we should =
draft a use case based requirement document. It looks to me that we are =
talking past each other with slightly different use-cases in mind. =

    <=
o:p> 
    A=
s far as I can tell, we do not have an agreement on the Requirements for =
discovery. We should first address it, then get back to the specific =
protocols. 
    <=
o:p> 
    B=
est, 
    <=
o:p> 
    N=
at Sakimura
    <=
o:p> 
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George =
Fletcher
    Sent: Wednesday, March 16, 2016 6:29 AM
    To: =
John Bradley <ve7jtb@ve7jtb.com>
    Cc: =
<oauth@ietf.org> <oauth@ietf.org>
    Subject: Re: =
[OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
     
    (snip) =

    If we are really trying to solve this problem holistically, =
then we probably need to first describe the use cases we want to solve. =
I'm starting to wonder if we are all providing solutions to slightly =
different use cases.
     <=
/span>
    (=
snip)
     
    --=

    PLEASE READ :This =
e-mail is confidential and intended for the
    named recipient =
only. If you are not an intended recipient,
    please notify the =
sender=C2=A0 and delete this e-mail.
    <=
o:p> 
    
------=_NextPart_000_0075_01D18061.5667A0B0--


From nobody Wed Mar 16 23:30:12 2016
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 E405A12D5C2 for ; Wed, 16 Mar 2016 23:30:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xj05esrkvsc4 for ; Wed, 16 Mar 2016 23:30:09 -0700 (PDT)
Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D2712D764 for ; Wed, 16 Mar 2016 23:30:08 -0700 (PDT)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs03.index.or.jp (Postfix) with SMTP id 3256217EA43; Thu, 17 Mar 2016 15:30:08 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id u2H6U7km018695; Thu, 17 Mar 2016 15:30:08 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u2H6U7m9050823; Thu, 17 Mar 2016 15:30:07 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u2H6U7BQ050821; Thu, 17 Mar 2016 15:30:07 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u2H6U7ea050817; Thu, 17 Mar 2016 15:30:07 +0900
From: "Nat Sakimura" 
To: "'John Bradley'" , "'Brian Campbell'" 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>  
In-Reply-To: 
Date: Thu, 17 Mar 2016 15:30:16 +0900
Message-ID: <007901d18016$79026150$6b0723f0$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01D18061.E8EC7A50"
X-Mailer: Microsoft Outlook 15.0
Content-Language: ja
Thread-Index: AQHEZdZQi2eXWkFLB7/YhWzS03fSXgJWuf4XAglEkNwCjSWGNAFYrFPKAbVe4bICXCh0KgH9Nq5iAb7jtLQBi6IADAH79mgKAkDwxUwBM7kc/AJPnmsBAUtOk2wB8g7p1Z6SetsQ
X-MailAdviser: 20141126
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 06:30:11 -0000

This is a multipart message in MIME format.

------=_NextPart_000_007A_01D18061.E8EC7A50
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

A disadvantage of this method is that it cannot be used in the case =
where concrete resource uri is unknown to the client until the user =
gives permission.=20

=20

Right, this is a different use case. That=E2=80=99s why we need a =
use-case driven Requirement document to start with.=20

=20

Nat

=20

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, March 16, 2016 2:57 AM
To: Brian Campbell 
Cc:  
Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt

(..snip..)

=20

The advantage of always sending it in the token request is that it =
allows the AS to do the mapping from a resource URI to one or more =
abstract audience for the token.

=20

That might help address George=E2=80=99s concern.

=20

John B.

=20

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

=20


------=_NextPart_000_007A_01D18061.E8EC7A50
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    A=
 disadvantage of this method is that it cannot be used in the case where =
concrete resource uri is unknown to the client until the user gives =
permission. 
    <=
o:p> 
    R=
ight, this is a different use case. That=E2=80=99s why we need a =
use-case driven Requirement document to start with. =

    <=
o:p> 
    N=
at
    <=
o:p> 
    From:<=
/b> OAuth =
[mailto:oauth-bounces@ietf.org] On Behalf Of John =
Bradley
    Sent: Wednesday, March 16, 2016 2:57 AM
    To: =
Brian Campbell <bcampbell@pingidentity.com>
    Cc: =
<oauth@ietf.org> <oauth@ietf.org>
    Subject: Re: =
[OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
    (..snip..)
     
    The advantage of always sending it =
in the token request is that it allows the AS to do the mapping from a =
resource URI to one or more abstract audience for the =
token.
     
    That might help address =
George=E2=80=99s concern.
     
    John =
B.
     
    --=

    PLEASE READ :This =
e-mail is confidential and intended for the
    named recipient =
only. If you are not an intended recipient,
    please notify the =
sender=C2=A0 and delete this e-mail.
     
    
------=_NextPart_000_007A_01D18061.E8EC7A50--


From nobody Wed Mar 16 23:42:34 2016
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 BC5DC12D78B for ; Wed, 16 Mar 2016 23:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 nL0p2kRhwJOI for ; Wed, 16 Mar 2016 23:42:31 -0700 (PDT)
Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92212D5B6 for ; Wed, 16 Mar 2016 23:42:31 -0700 (PDT)
Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs03.index.or.jp (Postfix) with SMTP id DD79817EA43; Thu, 17 Mar 2016 15:42:30 +0900 (JST)
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp (unknown) with ESMTP id u2H6gUap002730; Thu, 17 Mar 2016 15:42:30 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u2H6gUrt060171; Thu, 17 Mar 2016 15:42:30 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u2H6gUG1060170; Thu, 17 Mar 2016 15:42:30 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u2H6gUA2060167; Thu, 17 Mar 2016 15:42:30 +0900
From: "Nat Sakimura" 
To: "'George Fletcher'" , "'John Bradley'" , "'Brian Campbell'" 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com>
In-Reply-To: <56E85111.9030308@aol.com>
Date: Thu, 17 Mar 2016 15:42:40 +0900
Message-ID: <009a01d18018$33bfe700$9b3fb500$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01D18063.A3A93CB0"
X-Mailer: Microsoft Outlook 15.0
Content-Language: ja
Thread-Index: AQHEZdZQi2eXWkFLB7/YhWzS03fSXgJWuf4XAglEkNwCjSWGNAFYrFPKAbVe4bICXCh0KgH9Nq5iAb7jtLQBi6IADAH79mgKAkDwxUwBM7kc/AJPnmsBAUtOk2wB8g7p1QGNdVcunoYQbuA=
X-MailAdviser: 20141126
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 06:42:33 -0000

This is a multipart message in MIME format.

------=_NextPart_000_009B_01D18063.A3A93CB0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

IMHO, list of URIs that represent the partial paths under the same =
authority would not be too onerous.=20

=20

e.g., if you have=20

=20

  =
https://example.com/apis/v1/userinfo

  =
https://example.com/apis/v2/userinfo

  =
https://example.org/some/api/endpoint

=20

etc., then the AS may provide=20

=20

  https://example.com/apis/

  https://example.org/

=20

or something like that in the audiences.=20

=20

A completely new domain should not be trusted blindly.=20

The resource should at least make sure to provide the domain as being =
under the same authority.=20

=20

Bearer Token is a Password. It should not be shared among different =
authorities.=20

=20

Best,=20

=20

Nat

=20

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Wednesday, March 16, 2016 3:15 AM
To: John Bradley ; Brian Campbell =

Cc:  
Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt

=20

(..snip..)=20

I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.



(..snip..)

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

=20


------=_NextPart_000_009B_01D18063.A3A93CB0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    I=
MHO, list of URIs that represent the partial paths under the same =
authority would not be too onerous. 
    <=
o:p> 
    e=
.g., if you have 
    <=
o:p> 
    https://example=
.com/apis/v1/userinfo<=
o:p>
    https://example=
.com/apis/v2/userinfo<=
o:p>
    https://example=
.org/some/api/endpoint<=
o:p>
    <=
o:p> 
    e=
tc., then the AS may provide 
    <=
o:p> 
    https://example=
.com/apis/<=
o:p>
    https://example=
.org/<=
o:p>
    <=
o:p> 
    o=
r something like that in the audiences. 
    <=
o:p> 
    A=
 completely new domain should not be trusted blindly. =

    T=
he resource should at least make sure to provide the domain as being =
under the same authority. 
    <=
o:p> 
    B=
earer Token is a Password. It should not be shared among different =
authorities. 
    <=
o:p> 
    B=
est, 
    <=
o:p> 
    N=
at
    <=
o:p> 
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George =
Fletcher
    Sent: Wednesday, March 16, 2016 3:15 AM
    To: =
John Bradley <ve7jtb@ve7jtb.com>; Brian Campbell =
<bcampbell@pingidentity.com>
    Cc: <oauth@ietf.org> =
<oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for =
draft-hunt-oauth-bound-config-00.txt
     
    (..snip..) =

    I'm not sure passing the =
full endpoint to the AS will help with my concerns... The AS could =
potentially do a webfinger on the resource URI and determine if it's an =
RS that it supports... though that requires all RS's to support =
webfinger. What I really want to avoid is the AS having this list of =
URIs to RS that is almost assuredly to get out of =
sync.

    (=
..snip..)
    --=

    PLEASE READ :This =
e-mail is confidential and intended for the
    named recipient =
only. If you are not an intended recipient,
    please notify the =
sender=C2=A0 and delete this e-mail.
     
    
------=_NextPart_000_009B_01D18063.A3A93CB0--


From nobody Thu Mar 17 05:58:39 2016
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 043E112D537 for ; Thu, 17 Mar 2016 05:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.191
X-Spam-Level: 
X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 G5aY1041Ejrc for ; Thu, 17 Mar 2016 05:58:35 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 9DF5712D522 for ; Thu, 17 Mar 2016 05:58:35 -0700 (PDT)
X-AuditID: 12074423-10bff70000006fe3-26-56eaa9fade01
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id D8.51.28643.AF9AAE65; Thu, 17 Mar 2016 08:58:34 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u2HCwX2n024541; Thu, 17 Mar 2016 08:58:33 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2HCwUvm001091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Mar 2016 08:58:31 -0400
To: Nat Sakimura , "'George Fletcher'" , "'John Bradley'" , "'Brian Campbell'" 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp>
From: Justin Richer 
Message-ID: <56EAA9EF.2030507@mit.edu>
Date: Thu, 17 Mar 2016 08:58:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <009a01d18018$33bfe700$9b3fb500$@nri.co.jp>
Content-Type: multipart/alternative; boundary="------------050704070008010601050100"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsUixCmqrPtr5aswgwnnJSxW/7/JaHGnawW7 xa7bRxgtTr59xWax+u5fNgdWj/u7V7J7LFnyk8ljya/zjB53j15k8bh9eyNLAGsUl01Kak5m WWqRvl0CV8a6C19ZC96UVJy/+Jy1gXFLXBcjJ4eEgInE1f3zmbsYuTiEBNqYJFrvP2eCcDYy Spxr6YJybjNJTGk7xQjSIiwQLXHh8XWwhIjAYUaJqUcbGSGqNrBLTNx9nAWkillASOLDpSYw m01AVWL6mhYmEJtXQE1i0bQdYJNYgOJ7di5mBbFFBWIkjr87xwhRIyhxcuYTsF5OAQuJNz8/ MELMDJP4eu8p+wRG/llIymYhSUHYZhJdW7sYIWx5ie1v5zBD2GoSt7ddZYeJN2+dzbyAkW0V o2xKbpVubmJmTnFqsm5xcmJeXmqRrplebmaJXmpK6SZGUGywuyjvYHzZ532IUYCDUYmHd8Xp l2FCrIllxZW5hxglOZiURHmfL38VJsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE9/JSoBxvSmJl VWpRPkxKmoNFSZyXkYGBQUggPbEkNTs1tSC1CCYrw8GhJMHrAEwBQoJFqempFWmZOSUIaSYO TpDhPEDDt4ENLy5IzC3OTIfIn2I05jg298ZaJo596+6sZRJiycvPS5US5+UHGScAUppRmgc3 DZTeEt4eNn3FKA70nDCvNUgVDzA1ws17BbSKCWjVsTiwVSWJCCmpBkaJPVl6U7ffffMkrHnN MZ2HfKtqXHcEJmnprhAWfH340qcXRoyWHH3zFi9zuJbx3ourTYC/8MPRW5tZ+9UjX/3ofTD7 n8AFcabF80W3eN0S2sFuIFwrOf3Nb75jIYLLE5mibCfK/2GbvD+EqYLrtcHpb5ujv6b6bjG+ rta4Y3dDZNu0KLvbGw8rsRRnJBpqMRcVJwIATtIvokoDAAA=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 12:58:38 -0000

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

The problem here is that the "authority" model built into the URI 
definition is completely broken by user-hosted content, as we saw in the 
attack on ESPN and several against Google+ in the last few years.

  -- Justin

On 3/17/2016 2:42 AM, Nat Sakimura wrote:
>
> IMHO, list of URIs that represent the partial paths under the same 
> authority would not be too onerous.
>
> e.g., if you have
>
> https://example.com/apis/v1/userinfo
>
> https://example.com/apis/v2/userinfo
>
> https://example.org/some/api/endpoint
>
> etc., then the AS may provide
>
> https://example.com/apis/
>
> https://example.org/
>
> or something like that in the audiences.
>
> A completely new domain should not be trusted blindly.
>
> The resource should at least make sure to provide the domain as being 
> under the same authority.
>
> Bearer Token is a Password. It should not be shared among different 
> authorities.
>
> Best,
>
> Nat
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George 
> Fletcher
> *Sent:* Wednesday, March 16, 2016 3:15 AM
> *To:* John Bradley ; Brian Campbell 
> 
> *Cc:*  
> *Subject:* Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-bound-config-00.txt
>
> (..snip..)
>
> I'm not sure passing the full endpoint to the AS will help with my 
> concerns... The AS could potentially do a webfinger on the resource 
> URI and determine if it's an RS that it supports... though that 
> requires all RS's to support webfinger. What I really want to avoid is 
> the AS having this list of URIs to RS that is almost assuredly to get 
> out of sync.
>
> (..snip..)
>
> --
>
> PLEASE READ :This e-mail is confidential and intended for the
>
> named recipient only. If you are not an intended recipient,
>
> please notify the sender  and delete this e-mail.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------050704070008010601050100
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    The problem here is that the "authority" model built into the URI
    definition is completely broken by user-hosted content, as we saw in
    the attack on ESPN and several against Google+ in the last few
    years.
    
    
    
     -- Justin
    
    
    
    
    On 3/17/2016 2:42 AM, Nat Sakimura
      wrote:
    
    
    
    
    
      
      
      
      
    
        
    IMHO, list of URIs that represent the partial
              paths under the same authority would not be too onerous. 
    
        
     
    
        
    e.g., if you have 
    
        
     
    
        
    https://example.com/apis/v1/userinfo
    
        
    https://example.com/apis/v2/userinfo
    
        
    https://example.org/some/api/endpoint
    
        
     
    
        
    etc., then the AS may provide 
    
        
     
    
        
    https://example.com/apis/
    
        
    https://example.org/
    
        
     
    
        
    or something like that in the audiences. 
    
        
     
    
        
    A completely new domain should not be trusted
            blindly. 
    
        
    The resource should at least make sure to
            provide the domain as being under the same authority. 
    
        
     
    
        
    Bearer Token is a Password. It should not be
            shared among different authorities. 
    
        
     
    
        
    Best, 
    
        
     
    
        
    Nat
    
        
     
    
        
    
          
    
            
    From: OAuth [mailto:oauth-bounces@ietf.org] On
                  Behalf Of George Fletcher
    
                Sent: Wednesday, March 16, 2016 3:15 AM
    
                To: John Bradley <ve7jtb@ve7jtb.com>; Brian
                Campbell <bcampbell@pingidentity.com>
    
                Cc: <oauth@ietf.org> <oauth@ietf.org>
    
                Subject: Re: [OAUTH-WG] New Version Notification
                for draft-hunt-oauth-bound-config-00.txt
    
          
    
        
    
        
     
    
        
    (..snip..) 
    
        
    I'm not sure passing the full endpoint to the
            AS will help with my concerns... The AS could potentially do
            a webfinger on the resource URI and determine if it's an RS
            that it supports... though that requires all RS's to support
            webfinger. What I really want to avoid is the AS having this
            list of URIs to RS that is almost assuredly to get out of
            sync.
    
            
    
          
    
        
    (..snip..)
    
        
    --
    
        
    PLEASE READ :This
            e-mail is confidential and intended for the
    
        
    named recipient only.
            If you are not an intended recipient,
    
        
    please notify the
            sender  and delete this e-mail.
    
        
     
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  


--------------050704070008010601050100--


From nobody Thu Mar 17 07:36:15 2016
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 BE93D12D6E2 for ; Thu, 17 Mar 2016 07:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mx.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 kZg6UHubEeRQ for ; Thu, 17 Mar 2016 07:36:07 -0700 (PDT)
Received: from omr-a011e.mx.aol.com (omr-a011e.mx.aol.com [204.29.186.59]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F6612D572 for ; Thu, 17 Mar 2016 07:36:06 -0700 (PDT)
Received: from mtaout-aak01.mx.aol.com (mtaout-aak01.mx.aol.com [172.27.2.225]) by omr-a011e.mx.aol.com (Outbound Mail Relay) with ESMTP id DBE7D3800056; Thu, 17 Mar 2016 10:36:05 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aak01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B62B23800009C; Thu, 17 Mar 2016 10:35:59 -0400 (EDT)
To: John Bradley , Phil Hunt 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAC0D2.3090108@aol.com>
Date: Thu, 17 Mar 2016 10:36:02 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------020607070909040300060900"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458225365; bh=HO/9rga4Ny5wS8F7fWQAa0hm7zo3mkdbvAMQDKWDB50=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=H5/BapzEWH9bYByFJ+Ti/Jq/DUOZbbeGCyjxZQumHBGujYABZGcJ7pqyT09tWyAsc sPqD1bwfuQ+9ODfbeKYd24VQOinXUxWl7XWV/EjOcUDgxWmGABe1yXmn2qHgYP8n/1 MRr1J8mAt32Wq0I3otlLPo+Res5o2ENIFfjGyTRM=
x-aol-sid: 3039ac1b02e156eac0cf5f75
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 14:36:14 -0000

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



On 3/16/16 6:37 PM, John Bradley wrote:
> I agree with Phil that the client can’t trust any abstract identifier 
> that it might get from a bad RS unless it is were a URI that the 
> client or AS could deference to get a list of the concrete URI for the RS.
I guess I'm confused on this front as we are asking the client to 
"trust" the AS identifier that is being returned by the AS as well as 
the value the client gets from discovery if it uses that method to 
obtain the AS endpoints.

I don't understand why the same philosophy can't be used for Resource 
Service identifier and endpoints.
>
> That seems like a lot of work that clients are unlikely to do.
If I can discover the RS endpoints once and cache them, that doesn't 
seem that difficult. This only applies to clients that have some support 
for dynamically accepting RS's and their endpoints.

For clients that only support a single AS we are saying they can get the 
AS identifier out-of-band and use that. We can easily do the same thing 
for an RS identifier. They can either get it out-of-band (i.e. 
hardcoded) or they can get them dynamically (not likely initially but we 
shouldn't preclude it).
>
> A AS might do it if it wanted to look up the identifier for a given 
> resource.
>
> Something like do get on resource get back Abstract identifier 
> (probably well known location, as recently pointed out in another 
> thread you can’t allow it to point to user content.)
Yes, you could do it this way, though the client still needs to get 
those endpoints and if it's doing it dynamically, it will likely use the 
same method to discover the endpoints:)
>
> The AS gets the file and maps the uri to a abstract identifier for 
> audience.
>
> I guess that would be one way that you could map AS URI to a abstract 
> identifier, but I wouldn’t want to count on clients doing it.
This will work fine, if the client has hardcoded endpoints.

My main concern is that I don't want the AS to have to manage a map of 
endpoint URLs for each RS it's supporting.

Think of an RS that supports multiple AS's. If the RS adds a new 
endpoint, that endpoint can't go live until each AS receives the 
endpoint and adds it to it's map. That is a deployment nightmare. The 
mapping of RS to current endpoints has to dynamic even if it's done by 
the AS rather than the client.

Wildcard'ing the endpoint URLs or only using domains, I don't think will 
work as we've proven that open redirect holes break this thinking. It 
needs to be an exact match.
>
> John B.
>
>
>
>
>
>> On Mar 16, 2016, at 3:46 PM, Phil Hunt > > wrote:
>>
>> George,
>>
>> Thanks. It would be good to get a draft that sketches out the overall 
>> picture of this for BA — even if in very rough form given the 
>> deadline is monday.  Or, maybe just a PPT walkthru.
>>
>> Interested to see what comes out.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>
>>
>>
>>
>>
>>> On Mar 16, 2016, at 11:29 AM, George Fletcher >> > wrote:
>>>
>>> Inline...
>>>
>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com 
>>>> phil.hunt@oracle.com 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher >>>> > wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>> George
>>>>>>
>>>>>> Very good question...
>>>>>>
>>>>>> I considered that the RS metadata discovery could be fake.
>>>>> Same way that the 'iss' claim must "match" the url used to 
>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>> -- I think that should suffice to ensuring the 'rsid' identifier 
>>>>> can't be spoofed by another site
>>>>
>>>> So the attacker makes iss and url match for the resource discovery. 
>>>> Yet the AS service provider doesn’t know where the client is using 
>>>> the tokens.  How would the client or the AS detect that the wrong 
>>>> iss was given?
>>> Because if the attacker makes the rsid and the url match, then the 
>>> client will submit an rsid that isn't "registered" with the AS and 
>>> the AS won't issue the token. This assumes the client is not talking 
>>> to an evil AS (as there are other mitigations for that case).
>>>>
>>>>>>
>>>>>> So the final step in configuration validation is to bind the 
>>>>>> relationship between as and rs discovery together to confirm the 
>>>>>> relationship is valid.
>>>>> And what I'd like to see is the 'rsid' value used to represent the 
>>>>> RS rather than some unique endpoint (even if wildcards are allowed)
>>>>
>>>> Long term, I think this would be better. Do we have a way to issue 
>>>> RSID values in the works?
>>> No, but that is what this email thread is contemplating:) Just as 
>>> the AS iss value is selfdefined by the AS, the rsid should be 
>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata 
>>> is a mirror of how the AS 'iss' claim is defined for the AS in it's 
>>> metadata.
>>>>
>>>> That said, I would have thought this is more ownerous than checking 
>>>> *.example.com  matches the given URL by the 
>>>> client.
>>> My problem with the URL level checking is that a RS may legitimately 
>>> have endpoints on multiple domains. An RS may move endpoints from 
>>> one domain to another (say when moving from version 1 to version 2 
>>> of an API). Using the rsid for audience restriction and as an 
>>> indirect mechanism for specifying actual endpoints, the RS has a 
>>> much looser coupling with the AS.
>>>
>>> AS we move into "federated authorization" meaning that an RS 
>>> outsources it's API authorization to one or more AS's, this will 
>>> become more important.
>>>>>
>>>>> Another step that may be required is for the RS to return it's 
>>>>> 'rsid' in the realm field of the WWW-Authenticate response header. 
>>>>> This allows a client to discover metadata about the RS and it's 
>>>>> endpoints. It also allows the client to determine if the 'rsid' 
>>>>> returned by the RS matches the 'rsid' it is expecting.
>>>>
>>>> Agreed. This might work. But should the check be when the client 
>>>> asks for the configuration metadata or when the client asks for 
>>>> tokens?  I think it only needs to happen at config time.
>>> What I see here is that the desire is to audience protect tokens. To 
>>> do that, the audience need to be specified everytime a token is 
>>> requested. I really don't the AS to have to manage the complex state 
>>> of which audiences have previously been issued to refresh_tokens and 
>>> then reconstruct the correct audience for a requested downscoped 
>>> access_token. It's much simpler, since the client knows which RS 
>>> it's going to send the token to, to provide that when requesting tokens.
>>>
>>> The complication comes when exchanging the code for the tokens, it 
>>> needs to specify all possible audiences (rsid's) it might send the 
>>> token to based on the requested scopes. There will be a fair amount 
>>> of complex logic at the AS to ensure the correct behavior. I do 
>>> worry about this complexity.
>>>>>>
>>>>>> We are of course assuming that a hacker needs to use the real AS 
>>>>>> authorize endpoint to succeed in obtaining an access token(it 
>>>>>> can't be mitm'd). Once the grant is obtained by the client, the 
>>>>>> threat comes when the client uses the grant at a mitm'd token 
>>>>>> endpoint OR an access token at a mitm'd resource endpoint.
>>>>>>
>>>>>> So the AS and its config set becomes the trust anchor. Binding 
>>>>>> allows us to extend trust to the RS discovery giving some 
>>>>>> assurance that a client has a correct set of endpoints including 
>>>>>> resource.
>>>>> Are you recommending that the AS metadata provide a list of the 
>>>>> 'rsid' supported by the AS?
>>>> No.  I think that is a bad idea.  Better to use an identity oracle 
>>>> function and say, give me the config for rsid=xyz
>>> Good :)
>>>>
>>>> That also allows a common AS discovery endpoint to actually do 
>>>> discovery for multiple AS systems.  E.g. to configure a client to a 
>>>> specific AS service designated by the customer paying for the 
>>>> resource service.
>>>>
>>>> IOW. by providing a resource query, the meta-data config discovery 
>>>> actually looks more like discovery.  :-)
>>>>>>
>>>>>> John's solution requires translating aud to res url and changes 
>>>>>> to core oauth. He seems to imply there is a need for ongoing 
>>>>>> validation of resource. I'm not yet convinced that is really 
>>>>>> needed.  Maybe it is needed because the client could be convinced 
>>>>>> to follow a link embedded in a resource that is somehow not part 
>>>>>> of the defined audience?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On Mar 16, 2016, at 08:57, George Fletcher  wrote:
>>>>>>
>>>>>>> So, in thinking about all this AS restricting tokens to RS and 
>>>>>>> "discovery" of RS endpoints, etc. I wondered why we don't just 
>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>
>>>>>>> For an AS we require an 'iss' claim to use as an identifier of 
>>>>>>> the AS. We could do the same with RS metadata retrieving the 
>>>>>>> metadata from a .well-known location and including a claim of 
>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>
>>>>>>> This 'rsid' identifier could then be used for registration with 
>>>>>>> the AS and presentation by the client when requesting tokens.
>>>>>>>
>>>>>>> This provides a separation between an identifier for a resource 
>>>>>>> and the specific endpoints the token will be sent to. A client 
>>>>>>> could "discover" the necessary endpoint on a periodic basis and 
>>>>>>> use a single identifier with the AS for any of the endpoints or 
>>>>>>> scopes supported by the RS. If desired the RS could expose the 
>>>>>>> supported scopes in the RS metadata file.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> George
>>>>>>> _______________________________________________
>>>>>>> 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
>

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------020607070909040300060900
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    
    
    
    
    On 3/16/16 6:37 PM, John Bradley wrote:
    
    
    
    
    
      
      I agree with Phil that the client can’t trust any abstract
      identifier that it might get from a bad RS unless it is were a URI
      that the client or AS could deference to get a list of the
      concrete URI for the RS.
    
    I guess I'm confused on this front as we are asking the client to
    "trust" the AS identifier that is being returned by the AS as well
    as the value the client gets from discovery if it uses that method
    to obtain the AS endpoints.
    
    
    
    I don't understand why the same philosophy can't be used for
    Resource Service identifier and endpoints.
    
    
    
      

    
      
    
      
    That seems like a lot of work that clients are
        unlikely to do.
    
    
    
    If I can discover the RS endpoints once and cache them, that doesn't
    seem that difficult. This only applies to clients that have some
    support for dynamically accepting RS's and their endpoints. 
    
    
    
    For clients that only support a single AS we are saying they can get
    the AS identifier out-of-band and use that. We can easily do the
    same thing for an RS identifier. They can either get it out-of-band
    (i.e. hardcoded) or they can get them dynamically (not likely
    initially but we shouldn't preclude it).
    
    
    
      

    
      
    
      
    A AS might do it if it wanted to look up the
        identifier for a given resource. 
    
      

    
      
    
      
    Something like do get on resource get back Abstract
        identifier (probably well known location, as recently pointed
        out in another thread you can’t allow it to point to user
        content.) 
    
      
    
    
    
    Yes, you could do it this way, though the client still needs to get
    those endpoints and if it's doing it dynamically, it will likely use
    the same method to discover the endpoints:)
    
    
    
      

    
      
    
      
    The AS gets the file and maps the uri to a abstract
        identifier for audience.
    
      

    
      
    
      
    I guess that would be one way that you could map AS
        URI to a abstract identifier, but I wouldn’t want to count on
        clients doing it.
    
    
    
    This will work fine, if the client has hardcoded endpoints.
    
    
    
    My main concern is that I don't want the AS to have to manage a map
    of endpoint URLs for each RS it's supporting.
    
    
    
    Think of an RS that supports multiple AS's. If the RS adds a new
    endpoint, that endpoint can't go live until each AS receives the
    endpoint and adds it to it's map. That is a deployment nightmare.
    The mapping of RS to current endpoints has to dynamic even if it's
    done by the AS rather than the client.
    
    
    
    Wildcard'ing the endpoint URLs or only using domains, I don't think
    will work as we've proven that open redirect holes break this
    thinking. It needs to be an exact match.
    
    
    
      

    
      
    
      
    John B.
    
      

    
      
    
      
    
        

    
        
    
        

    
          

    
          
    
          

    
            
    
              
    
                
    On Mar 16, 2016, at 3:46 PM, Phil Hunt
                  <phil.hunt@oracle.com>
                  wrote:
    
                
    
                
    
                  
                  
    George,
                    

    
                    
    
                    
    Thanks. It would be good to get a
                      draft that sketches out the overall picture of
                      this for BA — even if in very rough form given the
                      deadline is monday.  Or, maybe just a PPT
                      walkthru.
    
                    

    
                    
    
                    
    Interested to see what comes out.
    
                    

    
                      
                      
    
                      
    
                        
    
                          
    On Mar 16, 2016, at 11:29 AM,
                            George Fletcher <gffletch@aol.com>
                            wrote:
    
                          
    
                          
    
                            
                            
     Inline...
    
                              
    
                              
    On 3/16/16
                                2:16 PM, Phil Hunt wrote:
    
                              
    
                              
    
                                
                                
    
                                
                                
    
                                
    
                                  
    
                                    
    On Mar 16, 2016, at
                                      10:59 AM, George Fletcher <gffletch@aol.com>
                                      wrote:
    
                                    
    
                                    

    
                                      
    
                                      
    On 3/16/16 12:20 PM, Phil
                                        Hunt (IDM) wrote:
    
                                      
    
                                      
    
                                        
    George
    
                                        

    
                                        
    
                                        
    Very good
                                          question...
    
                                        

    
                                        
    
                                        
    I considered that
                                          the RS metadata discovery
                                          could be fake. 
    
                                        
    
                                      
    
                                      Same way that
                                        the 'iss' claim must "match" the
                                        url used to retrieve the
                                        metadata would apply to the
                                        'rsid' claim
    
                                        -- I think that should suffice
                                        to ensuring the 'rsid'
                                        identifier can't be spoofed by
                                        another site
    
                                      
    
                                  
    
                                  

    
                                  
    
                                  So the attacker makes iss and url
                                  match for the resource discovery. Yet
                                  the AS service provider doesn’t know
                                  where the client is using the tokens.
                                   How would the client or the AS detect
                                  that the wrong iss was given?
    
                              
    
                              Because if the attacker makes the rsid and
                              the url match, then the client will submit
                              an rsid that isn't "registered" with the
                              AS and the AS won't issue the token. This
                              assumes the client is not talking to an
                              evil AS (as there are other mitigations
                              for that case).
    
                              
    
                                

    
                                  
    
                                    
    
                                      
    
                                        

    
                                        
    
                                        
    So the final step
                                          in configuration validation is
                                          to bind the relationship
                                          between as and rs discovery
                                          together to confirm the
                                          relationship is valid. 
    
                                        
    
                                      
    
                                      And
                                        what I'd like to see is the
                                        'rsid' value used to represent
                                        the RS rather than some unique
                                        endpoint (even if wildcards are
                                        allowed)
    
                                    
    
                                  
    
                                  

    
                                  
    
                                  Long term, I think this would be
                                  better. Do we have a way to issue RSID
                                  values in the works?
    
                              
    
                              No, but that is what this email thread is
                              contemplating:) Just as the AS iss value
                              is selfdefined by the AS, the rsid should
                              be selfdefined by the RS. Requiring a
                              'rsid' claim in the RS metadata is a
                              mirror of how the AS 'iss' claim is
                              defined for the AS in it's metadata.
    
                              
    
                                

    
                                
    
                                
    That said, I would have
                                  thought this is more ownerous than
                                  checking *.example.com
                                  matches the given URL by the client.
    
                                
    
                              
    
                              My problem with the URL level checking is
                              that a RS may legitimately have endpoints
                              on multiple domains. An RS may move
                              endpoints from one domain to another (say
                              when moving from version 1 to version 2 of
                              an API). Using the rsid for audience
                              restriction and as an indirect mechanism
                              for specifying actual endpoints, the RS
                              has a much looser coupling with the AS.
    
                              
    
                              AS we move into "federated authorization"
                              meaning that an RS outsources it's API
                              authorization to one or more AS's, this
                              will become more important.
    
                              
    
                                
    
                                  
    
                                    

    
                                      Another
                                        step that may be required is for
                                        the RS to return it's 'rsid' in
                                        the realm field of the
                                        WWW-Authenticate response
                                        header. This allows a client to
                                        discover metadata about the RS
                                        and it's endpoints. It also
                                        allows the client to determine
                                        if the 'rsid' returned by the RS
                                        matches the 'rsid' it is
                                        expecting.
    
                                    
    
                                  
    
                                  

    
                                  
    
                                  Agreed. This might work. But should
                                  the check be when the client asks for
                                  the configuration metadata or when the
                                  client asks for tokens?  I think it
                                  only needs to happen at config time.
    
                                
    
                              
    
                              What I see here is that the desire is to
                              audience protect tokens. To do that, the
                              audience need to be specified everytime a
                              token is requested. I really don't the AS
                              to have to manage the complex state of
                              which audiences have previously been
                              issued to refresh_tokens and then
                              reconstruct the correct audience for a
                              requested downscoped access_token. It's
                              much simpler, since the client knows which
                              RS it's going to send the token to, to
                              provide that when requesting tokens.
    
                              
    
                              The complication comes when exchanging the
                              code for the tokens, it needs to specify
                              all possible audiences (rsid's) it might
                              send the token to based on the requested
                              scopes. There will be a fair amount of
                              complex logic at the AS to ensure the
                              correct behavior. I do worry about this
                              complexity.
    
                              
    
                                
    
                                  
    
                                    
    
                                      
    
                                        

    
                                        
    
                                        
    We are of course
                                          assuming that a hacker needs
                                          to use the real AS authorize
                                          endpoint to succeed in
                                          obtaining an access token(it
                                          can't be mitm'd). Once the
                                          grant is obtained by the
                                          client, the threat comes when
                                          the client uses the grant at a
                                          mitm'd token endpoint OR an
                                          access token at a mitm'd
                                          resource endpoint. 
    
                                        

    
                                        
    
                                        
    So the AS and its
                                          config set becomes the trust
                                          anchor. Binding allows us to
                                          extend trust to the RS
                                          discovery giving some
                                          assurance that a client has a
                                          correct set of endpoints
                                          including resource. 
    
                                        
    
                                      
    
                                      Are
                                        you recommending that the AS
                                        metadata provide a list of the
                                        'rsid' supported by the AS?
    
                                    
    
                                  
    
                                  No.  I think that is a bad idea.
                                   Better to use an identity oracle
                                  function and say, give me the config
                                  for rsid=xyz
    
                              
    
                              Good :)
    
                              
    
                                

    
                                
    
                                
    That also allows a common
                                  AS discovery endpoint to actually do
                                  discovery for multiple AS systems.
                                   E.g. to configure a client to a
                                  specific AS service designated by the
                                  customer paying for the resource
                                  service.  
    
                                

    
                                
    
                                
    IOW. by providing a
                                  resource query, the meta-data config
                                  discovery actually looks more like
                                  discovery.  :-)
    
                                
    
                                  
    
                                    
    
                                      
    
                                        

    
                                        
    
                                        
    John's solution
                                          requires translating aud to
                                          res url and changes to core
                                          oauth. He seems to imply there
                                          is a need for ongoing
                                          validation of resource. I'm
                                          not yet convinced that is
                                          really needed.  Maybe it is
                                          needed because the client
                                          could be convinced to follow a
                                          link embedded in a resource
                                          that is somehow not part of
                                          the defined audience?
    
                                        

    
                                        
    
                                        
    Thanks
    
                                          
    
                                          Phil
    
                                        

    
                                          On Mar 16, 2016, at 08:57,
                                          George Fletcher <gffletch@aol.com> wrote:
    
                                          
    
                                        
    
                                        
    
                                          
    So, in
                                              thinking about all this AS
                                              restricting tokens to RS
                                              and "discovery" of RS
                                              endpoints, etc. I wondered
                                              why we don't just leverage
                                              RS metadata like we have
                                              AS metadata.
    
                                              
    
                                              For an AS we require an
                                              'iss' claim to use as an
                                              identifier of the AS. We
                                              could do the same with RS
                                              metadata retrieving the
                                              metadata from a
                                              .well-known location and
                                              including a claim of
                                              'rsid' to use as an
                                              identifier of the Resource
                                              Server.
    
                                              
    
                                              This 'rsid' identifier
                                              could then be used for
                                              registration with the AS
                                              and presentation by the
                                              client when requesting
                                              tokens.
    
                                              
    
                                              This provides a separation
                                              between an identifier for
                                              a resource and the
                                              specific endpoints the
                                              token will be sent to. A
                                              client could "discover"
                                              the necessary endpoint on
                                              a periodic basis and use a
                                              single identifier with the
                                              AS for any of the
                                              endpoints or scopes
                                              supported by the RS. If
                                              desired the RS could
                                              expose the supported
                                              scopes in the RS metadata
                                              file.
    
                                              
    
                                              Thoughts?
    
                                              
    
                                              Thanks,
    
                                              George
    
                                          
    
                                        
    
                                        
    
                                          
    _______________________________________________
    
                                            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
    
                
    
              
    
            
    
            
    
          
    
        
    
      
    
    
    
    
    
    
    -- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

    
  


--------------020607070909040300060900--


From nobody Thu Mar 17 07:43:25 2016
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 7BCDB12DBF0 for ; Thu, 17 Mar 2016 07:43:24 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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=mx.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 GYu51F9YzeRQ for ; Thu, 17 Mar 2016 07:43:22 -0700 (PDT)
Received: from omr-m014e.mx.aol.com (omr-m014e.mx.aol.com [204.29.186.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BB512DBF2 for ; Thu, 17 Mar 2016 07:43:19 -0700 (PDT)
Received: from mtaout-aac01.mx.aol.com (mtaout-aac01.mx.aol.com [172.27.2.33]) by omr-m014e.mx.aol.com (Outbound Mail Relay) with ESMTP id 21E0238000B8; Thu, 17 Mar 2016 10:43:18 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 08A9538000096; Thu, 17 Mar 2016 10:43:17 -0400 (EDT)
To: Nat Sakimura , 'John Bradley' , 'Brian Campbell' 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAC287.30601@aol.com>
Date: Thu, 17 Mar 2016 10:43:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <009a01d18018$33bfe700$9b3fb500$@nri.co.jp>
Content-Type: multipart/alternative; boundary="------------030807020403040705020602"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458225798; bh=7DQW3X5w7F6lJBmjAZQ37N+6TL6ArS238Vn/7VQ+M/c=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=sS0c/2HeGEvWzgzAHwqS8xV3mcnNJMZ4K+SXKQHId+Aiw5BdmqTnX7GdOXnz8ZIY2 rVFLZbmu2kE/bm7LmuZxTi0ArUgIovsHTWZADQvjFn1f51QS9vogY067BfGTRRMoOs MFJSopnmQSUXX6W8BVsp9bXhT8qPSzVZnXgjl/6U=
x-aol-sid: 3039ac1b022156eac2851a9d
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 14:43:24 -0000

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

If one of the APIs has an open-redirect problem, won't that cause the 
token to leak to the attacker? That's why we went to exact match in 
OpenID Connect. Does it not apply in this case?

Thanks,
George

On 3/17/16 2:42 AM, Nat Sakimura wrote:
>
> IMHO, list of URIs that represent the partial paths under the same 
> authority would not be too onerous.
>
> e.g., if you have
>
> https://example.com/apis/v1/userinfo
>
> https://example.com/apis/v2/userinfo
>
> https://example.org/some/api/endpoint
>
> etc., then the AS may provide
>
> https://example.com/apis/
>
> https://example.org/
>
> or something like that in the audiences.
>
> A completely new domain should not be trusted blindly.
>
> The resource should at least make sure to provide the domain as being 
> under the same authority.
>
> Bearer Token is a Password. It should not be shared among different 
> authorities.
>
> Best,
>
> Nat
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George 
> Fletcher
> *Sent:* Wednesday, March 16, 2016 3:15 AM
> *To:* John Bradley ; Brian Campbell 
> 
> *Cc:*  
> *Subject:* Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-bound-config-00.txt
>
> (..snip..)
>
> I'm not sure passing the full endpoint to the AS will help with my 
> concerns... The AS could potentially do a webfinger on the resource 
> URI and determine if it's an RS that it supports... though that 
> requires all RS's to support webfinger. What I really want to avoid is 
> the AS having this list of URIs to RS that is almost assuredly to get 
> out of sync.
>
> (..snip..)
>
> --
>
> PLEASE READ :This e-mail is confidential and intended for the
>
> named recipient only. If you are not an intended recipient,
>
> please notify the sender  and delete this e-mail.
>


--------------030807020403040705020602
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    If one of the APIs has an
      open-redirect problem, won't that cause the token to leak to the attacker?
      That's why we went to exact match in OpenID Connect. Does it not
      apply in this case?
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/17/16 2:42 AM, Nat Sakimura wrote:
    
    
    
    
    
      
      
      
      
    
        
    IMHO, list of URIs that represent the partial
              paths under the same authority would not be too onerous. 
    
        
     
    
        
    e.g., if you have 
    
        
     
    
        
    https://example.com/apis/v1/userinfo
    
        
    https://example.com/apis/v2/userinfo
    
        
    https://example.org/some/api/endpoint
    
        
     
    
        
    etc., then the AS may provide 
    
        
     
    
        
    https://example.com/apis/
    
        
    https://example.org/
    
        
     
    
        
    or something like that in the audiences. 
    
        
     
    
        
    A completely new domain should not be trusted
            blindly. 
    
        
    The resource should at least make sure to
            provide the domain as being under the same authority. 
    
        
     
    
        
    Bearer Token is a Password. It should not be
            shared among different authorities. 
    
        
     
    
        
    Best, 
    
        
     
    
        
    Nat
    
        
     
    
        
    
          
    
            
    From: OAuth [mailto:oauth-bounces@ietf.org] On
                  Behalf Of George Fletcher
    
                Sent: Wednesday, March 16, 2016 3:15 AM
    
                To: John Bradley <ve7jtb@ve7jtb.com>; Brian
                Campbell <bcampbell@pingidentity.com>
    
                Cc: <oauth@ietf.org> <oauth@ietf.org>
    
                Subject: Re: [OAUTH-WG] New Version Notification
                for draft-hunt-oauth-bound-config-00.txt
    
          
    
        
    
        
     
    
        
    (..snip..) 
    
        
    I'm not sure passing the full endpoint to the
            AS will help with my concerns... The AS could potentially do
            a webfinger on the resource URI and determine if it's an RS
            that it supports... though that requires all RS's to support
            webfinger. What I really want to avoid is the AS having this
            list of URIs to RS that is almost assuredly to get out of
            sync.
    
            
    
          
    
        
    (..snip..)
    
        
    --
    
        
    PLEASE READ :This
            e-mail is confidential and intended for the
    
        
    named recipient only.
            If you are not an intended recipient,
    
        
    please notify the
            sender  and delete this e-mail.
    
        
     
    
      
    
    
    
    
    
  


--------------030807020403040705020602--


From nobody Thu Mar 17 07:44:25 2016
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 2F69912DBF4 for ; Thu, 17 Mar 2016 07:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 Ys9RdkUHLHnM for ; Thu, 17 Mar 2016 07:44:22 -0700 (PDT)
Received: from omr-m014e.mx.aol.com (omr-m014e.mx.aol.com [204.29.186.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40AF12D888 for ; Thu, 17 Mar 2016 07:44:19 -0700 (PDT)
Received: from mtaout-aad02.mx.aol.com (mtaout-aad02.mx.aol.com [172.26.127.226]) by omr-m014e.mx.aol.com (Outbound Mail Relay) with ESMTP id 0A3EA3800066; Thu, 17 Mar 2016 10:44:19 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aad02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2D2953800009A; Thu, 17 Mar 2016 10:44:15 -0400 (EDT)
To: Nat Sakimura , 'John Bradley' , 'Brian Campbell' 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <007901d18016$79026150$6b0723f0$@nri.co.jp>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAC2C2.1000002@aol.com>
Date: Thu, 17 Mar 2016 10:44:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <007901d18016$79026150$6b0723f0$@nri.co.jp>
Content-Type: multipart/alternative; boundary="------------020508000000010906040201"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458225858; bh=FUbkwoc3cTKNGUEPYVBLmyDNRGDF2iplI5HF/CXxmBo=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=BbCbBwM3exStN3MQbkJc0TQZz10sA5k9YPxlYkEUQrcU14YiwulAw+ArwYhaZ7Oqo t8Ei+raz7dnTpaVutGW2QO4FbPJeb+dueis8bN09cXD04fABigBNF9PiiPKTaiuIeC 0zu7F0HtS1lgymxOX/2DGEn0GvOGh9OAWi3UYrPI=
x-aol-sid: 3039ac1a7fe256eac2bf76c9
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 14:44:24 -0000

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

+1 for a list of use cases :)

On 3/17/16 2:30 AM, Nat Sakimura wrote:
>
> A disadvantage of this method is that it cannot be used in the case 
> where concrete resource uri is unknown to the client until the user 
> gives permission.
>
> Right, this is a different use case. That’s why we need a use-case 
> driven Requirement document to start with.
>
> Nat
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley
> *Sent:* Wednesday, March 16, 2016 2:57 AM
> *To:* Brian Campbell 
> *Cc:*  
> *Subject:* Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-bound-config-00.txt
>
> (..snip..)
>
> The advantage of always sending it in the token request is that it 
> allows the AS to do the mapping from a resource URI to one or more 
> abstract audience for the token.
>
> That might help address George’s concern.
>
> John B.
>
> --
>
> PLEASE READ :This e-mail is confidential and intended for the
>
> named recipient only. If you are not an intended recipient,
>
> please notify the sender  and delete this e-mail.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------020508000000010906040201
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    +1 for a list of use cases
      :)
    
    
    
    
    On 3/17/16 2:30 AM, Nat Sakimura wrote:
    
    
    
    
    
      
      
      
      
    
        
    A disadvantage of this method is that it
              cannot be used in the case where concrete resource uri is
              unknown to the client until the user gives permission. 
    
        
     
    
        
    Right, this is a different use case. That’s why
            we need a use-case driven Requirement document to start
            with. 
    
        
     
    
        
    Nat
    
        
     
    
        
    
          
    
            
    From: OAuth [mailto:oauth-bounces@ietf.org] On
                  Behalf Of John Bradley
    
                Sent: Wednesday, March 16, 2016 2:57 AM
    
                To: Brian Campbell
                <bcampbell@pingidentity.com>
    
                Cc: <oauth@ietf.org> <oauth@ietf.org>
    
                Subject: Re: [OAUTH-WG] New Version Notification
                for draft-hunt-oauth-bound-config-00.txt
    
          
    
        
    
        
    
          
    
            
    
              
    (..snip..)
    
            
    
            
    
              
     
    
            
    
            
    The advantage of
                always sending it in the token request is that it allows
                the AS to do the mapping from a resource URI to one or
                more abstract audience for the token.
    
          
    
          
    
            
     
    
          
    
          
    
            
    That might help
                address George’s concern.
    
          
    
          
    
            
     
    
          
    
          
    
            
    John B.
    
          
    
          
    
            
     
    
          
    
          
    --
    
          
    PLEASE READ :This
              e-mail is confidential and intended for the
    
          
    named recipient
              only. If you are not an intended recipient,
    
          
    please notify the
              sender  and delete this e-mail.
    
          
     
    
        
    
      
    
      
    
      
    
      
    
      
    _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

    
    
    
    
    
  


--------------020508000000010906040201--


From nobody Thu Mar 17 08:48:54 2016
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 90DA612D9A7 for ; Thu, 17 Mar 2016 08:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 39y916OiDxix for ; Thu, 17 Mar 2016 08:48:47 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 1C1B312D9B0 for ; Thu, 17 Mar 2016 08:48:41 -0700 (PDT)
Received: by mail-qg0-x22c.google.com with SMTP id y89so76071522qge.2 for ; Thu, 17 Mar 2016 08:48:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QE8PmFa/ySkVlfvRr2swkDSZTHLmRjb/NzJjxlBfkhs=; b=l9BJZLEryUsyL8Lvkk9ZApOjW3kB5SwPP+HdXtehNVwFO9d24GXRvb48Pafmiu1osd jDvWqWjs9XCTEXu2250yAaJgaKzLQ0MWcqOfK6jX+R8uK8EDlqhws0mArvOEiWXue6B0 HECKpiWZ2kdDVQUW01fRcOdjetRuPdOFhIhWpK+HeESklA034LYMFhn4YiQBDkSept9j fDDm7dCN95Uqrxq0Yd6H7lyON33CRV+fcCXUJvFMrEBDTAjXEOdIVhLPgcqbuTTJpuQs CJH7TYZHejgDOW3jZXHCN7buaF1C8A/h5Gt6SsvXZC6m7fDn9qOPQr9fpMYkX7LPohRD uRJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QE8PmFa/ySkVlfvRr2swkDSZTHLmRjb/NzJjxlBfkhs=; b=GVS1MQZnKc9k9nF/BUwiuPAF7vG5GarIjma/xy2PMQbx1eT5PAd7GYwijFu/6zsnRG xKzWzLIDph8n8q/SWG9kOURoyDecmSWF3s/3R6YLNANdtzuIWAeSfqtuZ4Es796xyi/x HKwttWl3VKLrtLcJzvaYlD2rjlnClnhsQoqVg38IUyR+mKmDy9DOeaDzszo+WfeBdd2S UiB5URvfNwgNLaET3AMLAewm7pgG4LmL/RDvA2r2vsHHuc4HD4Qp4Md0iz8l/SU1yH9n KRhlWsFOuUgyU5cg5vAZCuSkMxKAd9pU7zhTOh/IidtA9N3KGwphWIjjUJ/ZDYVhcxqU rnwQ==
X-Gm-Message-State: AD7BkJL4ZhecmM0NX4AtQvwpB/w8nWbymOc680yU/VSPn9Dx+nnIheexJUAAC9MP0BI6/Q==
X-Received: by 10.140.25.161 with SMTP id 30mr15170761qgt.73.1458229720135; Thu, 17 Mar 2016 08:48:40 -0700 (PDT)
Received: from [192.168.1.33] ([191.115.15.25]) by smtp.gmail.com with ESMTPSA id r16sm4017502qha.8.2016.03.17.08.48.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Mar 2016 08:48:38 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_38452338-9AE8-419E-BF21-64CF41985BAD"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56EAC287.30601@aol.com>
Date: Thu, 17 Mar 2016 12:48:31 -0300
Message-Id: <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <56EAC287.30601@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 15:48:50 -0000

--Apple-Mail=_38452338-9AE8-419E-BF21-64CF41985BAD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D20E93C1-986E-4EAC-9CD8-939A11D7B7C4"


--Apple-Mail=_D20E93C1-986E-4EAC-9CD8-939A11D7B7C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The problem is similar to the one with redirect_uri,  if you allow user =
hosted content on the domain they will be able to get the token if it is =
sent as a query parameter, and might be able to if it is sent as a =
header. =20

Unfortunately many OAuth clients are badly behaved and make use of the =
query parameter not considering the security issues.

Anything other than the AS or the client doing an exact URI match is =
going to leave some hole.

This is why we are working on POP that is the correct way to solve this =
for AS.

I think anything other than the client giving the AS the whole URI and =
the AS including that as a audience/destination and letting the RS =
figure out if it is correct is largely hopeless, as it will be to =
fragile or the client won=E2=80=99t do it. =20

In the case of Phil=E2=80=99s proposal the discovery happens once at =
client setup so the AS has no idea if the client checked  before issuing =
the token.

I honestly think there are two viable options:
1 PoP tokens
2 Including the destination URI / RS URI (pick name) in the token in =
full and letting the RS decide if it has been man in the middled.

Everything else will be an endless game of wack-a-mole that increases =
complexity but gets little real security.

John B.


> On Mar 17, 2016, at 11:43 AM, George Fletcher  =
wrote:
>=20
> If one of the APIs has an open-redirect problem, won't that cause the =
token to leak to the attacker? That's why we went to exact match in =
OpenID Connect. Does it not apply in this case?
>=20
> Thanks,
> George
>=20
> On 3/17/16 2:42 AM, Nat Sakimura wrote:
>> IMHO, list of URIs that represent the partial paths under the same =
authority would not be too onerous.=C2=A0 <>
>> =20
>> e.g., if you have=20
>> =20
>> https://example.com/apis/v1/userinfo =

>> https://example.com/apis/v2/userinfo =

>> https://example.org/some/api/endpoint =

>> =20
>> etc., then the AS may provide=20
>> =20
>> https://example.com/apis/ 
>> https://example.org/ 
>> =20
>> or something like that in the audiences.=20
>> =20
>> A completely new domain should not be trusted blindly.=20
>> The resource should at least make sure to provide the domain as being =
under the same authority.=20
>> =20
>> Bearer Token is a Password. It should not be shared among different =
authorities.=20
>> =20
>> Best,=20
>> =20
>> Nat
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
>> Sent: Wednesday, March 16, 2016 3:15 AM
>> To: John Bradley  ; =
Brian Campbell  =

>> Cc:    =

>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>> =20
>> (..snip..)=20
>>=20
>> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.
>>=20
>>=20
>> (..snip..)
>>=20
>> --
>> PLEASE READ :This e-mail is confidential and intended for the
>> named recipient only. If you are not an intended recipient,
>> please notify the sender  and delete this e-mail.
>> =20
>=20
>=20


--Apple-Mail=_D20E93C1-986E-4EAC-9CD8-939A11D7B7C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The problem is similar to the one with redirect_uri,  if =
you allow user hosted content on the domain they will be able to get the =
token if it is sent as a query parameter, and might be able to if it is =
sent as a header.  

    Unfortunately many OAuth clients are badly behaved and make =
use of the query parameter not considering the security =
issues.

    Anything=
 other than the AS or the client doing an exact URI match is going to =
leave some hole.

    This is why we are working on POP that is the correct way to =
solve this for AS.

    I think anything other than the client giving the AS the =
whole URI and the AS including that as a audience/destination and =
letting the RS figure out if it is correct is largely hopeless, as it =
will be to fragile or the client won=E2=80=99t do it.  

    In the case of Phil=E2=80=99=
s proposal the discovery happens once at client setup so the AS has no =
idea if the client checked  before issuing the token.

    I honestly think there =
are two viable options:
    1 PoP tokens
    2 Including the destination URI / RS URI (pick name) in the =
token in full and letting the RS decide if it has been man in the =
middled.

    Everything else will be an endless game of wack-a-mole that =
increases complexity but gets little real security.

    John B.


    On =
Mar 17, 2016, at 11:43 AM, George Fletcher <gffletch@aol.com> =
wrote:

    If one of the APIs has an open-redirect =
problem, won't that cause the token to leak to the attacker? That's why =
we went to exact match in OpenID Connect. Does it not apply in this =
case?

    Thanks,
    George

    On 3/17/16 2:42 AM, Nat Sakimura wrote:
    IMHO, list of =
URIs that represent the partial paths under the same authority would not =
be too onerous. 
     
    e.g., if you have 
     
    https://example.com/apis/v1/userinfo
    https://example.com/apis/v2/userinfo
    https://example.org/some/api/endpoint
     
    etc., then the =
AS may provide 
     
    https://example.com/apis/
    https://example.org/
     
    or something like that in the =
audiences. 
     
    A completely new =
domain should not be trusted blindly. 
    The resource should at least make sure to provide =
the domain as being under the same authority. 
     
    Bearer Token is =
a Password. It should not be shared among different authorities. 
     
    Best, 
     
    Nat
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of George =
Fletcher
    Sent: Wednesday, March 16, 2016 =
3:15 AM
    To: John Bradley <ve7jtb@ve7jtb.com>; Brian Campbell <bcampbell@pingidentity.com>
    Cc: <oauth@ietf.org> <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    (..snip..) 
    I'm not sure =
passing the full endpoint to the AS will help with my concerns... The AS =
could potentially do a webfinger on the resource URI and determine if =
it's an RS that it supports... though that requires all RS's to support =
webfinger. What I really want to avoid is the AS having this list of =
URIs to RS that is almost assuredly to get out of sync.

    (..snip..)
    --
    PLEASE READ :This e-mail is =
confidential and intended for the
    named recipient only. If you are not an intended =
recipient,
    please notify the =
sender  and delete this e-mail.
     



    =

--Apple-Mail=_D20E93C1-986E-4EAC-9CD8-939A11D7B7C4--

--Apple-Mail=_38452338-9AE8-419E-BF21-64CF41985BAD
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTcxNTQ4MzFaMCMGCSqGSIb3DQEJBDEWBBTWEpI01LUcPx/xt82liMaT
u8yOMTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCsL4X7OQv0Rjx9fdE2jTugskLBWBYYRs9YniCrFMKd2t+AzorfPm+8
9Q6bgg7h7CaomBoZzIRcADZCval7bNckUa0B0g1IjAum50tnyePVm/jldWE+sszB073dbltmVzBm
/GMRYX35isaDUzRcVmh/BKycNvw5KuUno70kh99U+PlMIAo4fmBgbJTp0S4Qy4hRurL6BMR69WbA
+WeQikXmcYHtect/bFhBVDLf9E03Qfg8ZFeyeiaaLQeoNza+GClIJV7P2SIJqOqQ9ljReTiS55LW
MCks6p4VLoYpio/8R0ONPOSxWAjb10EVcHCMn8zvwteyaxeWvkiPIWUM7y4XAAAAAAAA
--Apple-Mail=_38452338-9AE8-419E-BF21-64CF41985BAD--


From nobody Thu Mar 17 09:16:52 2016
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 6B9DB12D9E6 for ; Thu, 17 Mar 2016 09:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 vjEwDd-MeGjW for ; Thu, 17 Mar 2016 09:16:49 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 9C92D12DC11 for ; Thu, 17 Mar 2016 09:16:38 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2HGGZAg026599 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2016 16:16:35 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2HGGYW4012191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2016 16:16:34 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2HGGXcg008961; Thu, 17 Mar 2016 16:16:33 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Mar 2016 09:16:33 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_76B3F576-4274-4367-981B-A731356EF681"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <56EAC0D2.3090108@aol.com>
Date: Thu, 17 Mar 2016 09:16:31 -0700
Message-Id: <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com>
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 16:16:51 -0000

--Apple-Mail=_76B3F576-4274-4367-981B-A731356EF681
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

George,

For the attacks we looked at in Darmstadt, we discussed that in order =
for the attack to succeed (at least as envisioned), the attacker needs =
to have the client invoke the real authorize endpoint in order for the =
user to be successful in issuing the grant.

Assuming that it is the case, the attacker can use a proxied token =
endpoint or a proxied resource endpoint.  A client that doesn=92t know =
what the real endpoint should be could be confused depending on how =
discovery occurs.

Keep in mind that the token endpoint and the resource communications =
happens in the back channel. The user is never going to see the URL that =
has been invoked.  So=85.we need to make sure the set of endpoints are =
bound together or  confirmed.

Note: This hasn=92t been a big issue to date because current apps tend =
to work with fixed or singleton infrastructure.

One we expand OAuth out to scenarios where there are multiple service =
providers with different relationships with OAuth AS=92s, we move into =
this dynamic category that opens the threat.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 17, 2016, at 7:36 AM, George Fletcher  wrote:
>=20
>=20
>=20
> On 3/16/16 6:37 PM, John Bradley wrote:
>> I agree with Phil that the client can=92t trust any abstract =
identifier that it might get from a bad RS unless it is were a URI that =
the client or AS could deference to get a list of the concrete URI for =
the RS.
> I guess I'm confused on this front as we are asking the client to =
"trust" the AS identifier that is being returned by the AS as well as =
the value the client gets from discovery if it uses that method to =
obtain the AS endpoints.
>=20
> I don't understand why the same philosophy can't be used for Resource =
Service identifier and endpoints.
>>=20
>> That seems like a lot of work that clients are unlikely to do.
> If I can discover the RS endpoints once and cache them, that doesn't =
seem that difficult. This only applies to clients that have some support =
for dynamically accepting RS's and their endpoints.=20
>=20
> For clients that only support a single AS we are saying they can get =
the AS identifier out-of-band and use that. We can easily do the same =
thing for an RS identifier. They can either get it out-of-band (i.e. =
hardcoded) or they can get them dynamically (not likely initially but we =
shouldn't preclude it).
>>=20
>> A AS might do it if it wanted to look up the identifier for a given =
resource.=20
>>=20
>> Something like do get on resource get back Abstract identifier =
(probably well known location, as recently pointed out in another thread =
you can=92t allow it to point to user content.)=20
> Yes, you could do it this way, though the client still needs to get =
those endpoints and if it's doing it dynamically, it will likely use the =
same method to discover the endpoints:)
>>=20
>> The AS gets the file and maps the uri to a abstract identifier for =
audience.
>>=20
>> I guess that would be one way that you could map AS URI to a abstract =
identifier, but I wouldn=92t want to count on clients doing it.
> This will work fine, if the client has hardcoded endpoints.
>=20
> My main concern is that I don't want the AS to have to manage a map of =
endpoint URLs for each RS it's supporting.
>=20
> Think of an RS that supports multiple AS's. If the RS adds a new =
endpoint, that endpoint can't go live until each AS receives the =
endpoint and adds it to it's map. That is a deployment nightmare. The =
mapping of RS to current endpoints has to dynamic even if it's done by =
the AS rather than the client.
>=20
> Wildcard'ing the endpoint URLs or only using domains, I don't think =
will work as we've proven that open redirect holes break this thinking. =
It needs to be an exact match.
>>=20
>> John B.
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt > wrote:
>>>=20
>>> George,
>>>=20
>>> Thanks. It would be good to get a draft that sketches out the =
overall picture of this for BA =97 even if in very rough form given the =
deadline is monday.  Or, maybe just a PPT walkthru.
>>>=20
>>> Interested to see what comes out.
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>>  www.independentid.com =
phil.hunt@oracle.com =

>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>=20
>>>> Inline...
>>>>=20
>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>>  www.independentid.com =
phil.hunt@oracle.com =

>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>> George
>>>>>>>=20
>>>>>>> Very good question...
>>>>>>>=20
>>>>>>> I considered that the RS metadata discovery could be fake.=20
>>>>>> Same way that the 'iss' claim must "match" the url used to =
retrieve the metadata would apply to the 'rsid' claim
>>>>>> -- I think that should suffice to ensuring the 'rsid' identifier =
can't be spoofed by another site
>>>>>=20
>>>>> So the attacker makes iss and url match for the resource =
discovery. Yet the AS service provider doesn=92t know where the client =
is using the tokens.  How would the client or the AS detect that the =
wrong iss was given?
>>>> Because if the attacker makes the rsid and the url match, then the =
client will submit an rsid that isn't "registered" with the AS and the =
AS won't issue the token. This assumes the client is not talking to an =
evil AS (as there are other mitigations for that case).
>>>>>=20
>>>>>>>=20
>>>>>>> So the final step in configuration validation is to bind the =
relationship between as and rs discovery together to confirm the =
relationship is valid.=20
>>>>>> And what I'd like to see is the 'rsid' value used to represent =
the RS rather than some unique endpoint (even if wildcards are allowed)
>>>>>=20
>>>>> Long term, I think this would be better. Do we have a way to issue =
RSID values in the works?
>>>> No, but that is what this email thread is contemplating:) Just as =
the AS iss value is selfdefined by the AS, the rsid should be =
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a =
mirror of how the AS 'iss' claim is defined for the AS in it's metadata.
>>>>>=20
>>>>> That said, I would have thought this is more ownerous than =
checking *.example.com  matches the given URL by =
the client.
>>>> My problem with the URL level checking is that a RS may =
legitimately have endpoints on multiple domains. An RS may move =
endpoints from one domain to another (say when moving from version 1 to =
version 2 of an API). Using the rsid for audience restriction and as an =
indirect mechanism for specifying actual endpoints, the RS has a much =
looser coupling with the AS.
>>>>=20
>>>> AS we move into "federated authorization" meaning that an RS =
outsources it's API authorization to one or more AS's, this will become =
more important.
>>>>>>=20
>>>>>> Another step that may be required is for the RS to return it's =
'rsid' in the realm field of the WWW-Authenticate response header. This =
allows a client to discover metadata about the RS and it's endpoints. It =
also allows the client to determine if the 'rsid' returned by the RS =
matches the 'rsid' it is expecting.
>>>>>=20
>>>>> Agreed. This might work. But should the check be when the client =
asks for the configuration metadata or when the client asks for tokens?  =
I think it only needs to happen at config time.
>>>> What I see here is that the desire is to audience protect tokens. =
To do that, the audience need to be specified everytime a token is =
requested. I really don't the AS to have to manage the complex state of =
which audiences have previously been issued to refresh_tokens and then =
reconstruct the correct audience for a requested downscoped =
access_token. It's much simpler, since the client knows which RS it's =
going to send the token to, to provide that when requesting tokens.
>>>>=20
>>>> The complication comes when exchanging the code for the tokens, it =
needs to specify all possible audiences (rsid's) it might send the token =
to based on the requested scopes. There will be a fair amount of complex =
logic at the AS to ensure the correct behavior. I do worry about this =
complexity.
>>>>>>>=20
>>>>>>> We are of course assuming that a hacker needs to use the real AS =
authorize endpoint to succeed in obtaining an access token(it can't be =
mitm'd). Once the grant is obtained by the client, the threat comes when =
the client uses the grant at a mitm'd token endpoint OR an access token =
at a mitm'd resource endpoint.=20
>>>>>>>=20
>>>>>>> So the AS and its config set becomes the trust anchor. Binding =
allows us to extend trust to the RS discovery giving some assurance that =
a client has a correct set of endpoints including resource.=20
>>>>>> Are you recommending that the AS metadata provide a list of the =
'rsid' supported by the AS?
>>>>> No.  I think that is a bad idea.  Better to use an identity oracle =
function and say, give me the config for rsid=3Dxyz
>>>> Good :)
>>>>>=20
>>>>> That also allows a common AS discovery endpoint to actually do =
discovery for multiple AS systems.  E.g. to configure a client to a =
specific AS service designated by the customer paying for the resource =
service. =20
>>>>>=20
>>>>> IOW. by providing a resource query, the meta-data config discovery =
actually looks more like discovery.  :-)
>>>>>>>=20
>>>>>>> John's solution requires translating aud to res url and changes =
to core oauth. He seems to imply there is a need for ongoing validation =
of resource. I'm not yet convinced that is really needed.  Maybe it is =
needed because the client could be convinced to follow a link embedded =
in a resource that is somehow not part of the defined audience?
>>>>>>>=20
>>>>>>> Thanks
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher < =
gffletch@aol.com > =
wrote:
>>>>>>>=20
>>>>>>>> So, in thinking about all this AS restricting tokens to RS and =
"discovery" of RS endpoints, etc. I wondered why we don't just leverage =
RS metadata like we have AS metadata.
>>>>>>>>=20
>>>>>>>> For an AS we require an 'iss' claim to use as an identifier of =
the AS. We could do the same with RS metadata retrieving the metadata =
from a .well-known location and including a claim of 'rsid' to use as an =
identifier of the Resource Server.
>>>>>>>>=20
>>>>>>>> This 'rsid' identifier could then be used for registration with =
the AS and presentation by the client when requesting tokens.
>>>>>>>>=20
>>>>>>>> This provides a separation between an identifier for a resource =
and the specific endpoints the token will be sent to. A client could =
"discover" the necessary endpoint on a periodic basis and use a single =
identifier with the AS for any of the endpoints or scopes supported by =
the RS. If desired the RS could expose the supported scopes in the RS =
metadata file.
>>>>>>>>=20
>>>>>>>> Thoughts?
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>> George
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>>  OAuth@ietf.org 
>>>>>>>>  =
https://www.ietf.org/mailman/=
listinfo/oauth 
>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>>=20
>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 


--Apple-Mail=_76B3F576-4274-4367-981B-A731356EF681
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

George,

    For=
 the attacks we looked at in Darmstadt, we discussed that in order for =
the attack to succeed (at least as envisioned), the attacker needs to =
have the client invoke the real authorize endpoint in order for the user =
to be successful in issuing the grant.

    Assuming that it is the case, the =
attacker can use a proxied token endpoint or a proxied resource =
endpoint.  A client that doesn=92t know what the real endpoint =
should be could be confused depending on how discovery occurs.

    Keep in mind that the =
token endpoint and the resource communications happens in the back =
channel. The user is never going to see the URL that has been invoked. =
 So=85.we need to make sure the set of endpoints are bound together =
or  confirmed.

    Note: This hasn=92t been a big issue to date because current =
apps tend to work with fixed or singleton infrastructure.

    One we expand OAuth out =
to scenarios where there are multiple service providers with different =
relationships with OAuth AS=92s, we move into this dynamic category that =
opens the threat.

    


    

    

    On Mar 17, 2016, at 7:36 AM, George Fletcher <gffletch@aol.com> =
wrote:



    On 3/16/16 6:37 PM, John Bradley wrote:
    I agree with Phil that the client can=92t trust any abstract =
identifier that it might get from a bad RS unless it is were a URI that =
the client or AS could deference to get a list of the concrete URI for =
the RS.
    I=
 guess I'm confused on this front as we are asking the client to "trust" =
the AS identifier that is being returned by the AS as well as the value =
the client gets from discovery if it uses that method to obtain the AS =
endpoints.

    I don't understand =
why the same philosophy can't be used for Resource Service identifier =
and endpoints.

    That =
seems like a lot of work that clients are unlikely to =
do.
    If I can discover the RS endpoints once and cache them, that =
doesn't seem that difficult. This only applies to clients that have some =
support for dynamically accepting RS's and their endpoints. 

    For clients that only support a single AS we are =
saying they can get the AS identifier out-of-band and use that. We can =
easily do the same thing for an RS identifier. They can either get it =
out-of-band (i.e. hardcoded) or they can get them dynamically (not =
likely initially but we shouldn't preclude it).

    A AS =
might do it if it wanted to look up the identifier for a given =
resource. 

    Something like do get on resource get back Abstract =
identifier (probably well known location, as recently pointed out in =
another thread you can=92t allow it to point to user content.) 
    Yes, you could do it this way, though the client =
still needs to get those endpoints and if it's doing it dynamically, it =
will likely use the same method to discover the endpoints:)

    The AS =
gets the file and maps the uri to a abstract identifier for =
audience.

    I =
guess that would be one way that you could map AS URI to a abstract =
identifier, but I wouldn=92t want to count on clients doing =
it.
    This will work fine, if the client has hardcoded =
endpoints.

    My main concern is =
that I don't want the AS to have to manage a map of endpoint URLs for =
each RS it's supporting.

    Think of an RS that supports multiple AS's. If the RS adds a =
new endpoint, that endpoint can't go live until each AS receives the =
endpoint and adds it to it's map. That is a deployment nightmare. The =
mapping of RS to current endpoints has to dynamic even if it's done by =
the AS rather than the client.

    Wildcard'ing the endpoint URLs or only using domains, I don't =
think will work as we've proven that open redirect holes break this =
thinking. It needs to be an exact match.

    John =
B.





    On Mar =
16, 2016, at 3:46 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    George,

    Thanks. It would be good to get a draft =
that sketches out the overall picture of this for BA =97 even if in very =
rough form given the deadline is monday.  Or, maybe just a PPT =
walkthru.

    Interested to see what comes out.

    Phil

    @independentid
    www.independentid.com
    phil.hunt@oracle.com





    On Mar =
16, 2016, at 11:29 AM, George Fletcher <gffletch@aol.com> =
wrote:

    Inline...

    On 3/16/16 2:16 =
PM, Phil Hunt wrote:

    Phil

    @independentid
    www.independentid.com
    phil.hunt@oracle.com





    On Mar =
16, 2016, at 10:59 AM, George Fletcher <gffletch@aol.com> =
wrote:



    On 3/16/16 12:20 PM, Phil Hunt =
(IDM) wrote:
    George

    Very good question...

    I considered that the RS =
metadata discovery could be fake. 
    Same way that the 'iss' claim =
must "match" the url used to retrieve the metadata would apply to the =
'rsid' claim
    -- I think that should suffice to ensuring =
the 'rsid' identifier can't be spoofed by another site

    So the attacker makes iss and url match for the =
resource discovery. Yet the AS service provider doesn=92t know where the =
client is using the tokens.  How would the client or the AS detect =
that the wrong iss was given?
    Because if the attacker =
makes the rsid and the url match, then the client will submit an rsid =
that isn't "registered" with the AS and the AS won't issue the token. =
This assumes the client is not talking to an evil AS (as there are other =
mitigations for that case).


    So the final step in configuration validation is to bind the =
relationship between as and rs discovery together to confirm the =
relationship is valid. 
    And what I'd like to see is the 'rsid' value used to =
represent the RS rather than some unique endpoint (even if wildcards are =
allowed)

    Long term, I think this would be better. =
Do we have a way to issue RSID values in the =
works?
    No, but that is what this email thread is =
contemplating:) Just as the AS iss value is selfdefined by the AS, the =
rsid should be selfdefined by the RS. Requiring a 'rsid' claim in the RS =
metadata is a mirror of how the AS 'iss' claim is defined for the AS in =
it's metadata.

    That =
said, I would have thought this is more ownerous than checking *.example.com matches the given URL by =
the client.
    My problem with the URL =
level checking is that a RS may legitimately have endpoints on multiple =
domains. An RS may move endpoints from one domain to another (say when =
moving from version 1 to version 2 of an API). Using the rsid for =
audience restriction and as an indirect mechanism for specifying actual =
endpoints, the RS has a much looser coupling with the AS.

    AS we move into "federated authorization" =
meaning that an RS outsources it's API authorization to one or more =
AS's, this will become more important.

    Another step that may be required is for the RS to return =
it's 'rsid' in the realm field of the WWW-Authenticate response header. =
This allows a client to discover metadata about the RS and it's =
endpoints. It also allows the client to determine if the 'rsid' returned =
by the RS matches the 'rsid' it is expecting.

    Agreed. =
This might work. But should the check be when the client asks for the =
configuration metadata or when the client asks for tokens?  I think =
it only needs to happen at config time.
    What I see here is that the desire is to =
audience protect tokens. To do that, the audience need to be specified =
everytime a token is requested. I really don't the AS to have to manage =
the complex state of which audiences have previously been issued to =
refresh_tokens and then reconstruct the correct audience for a requested =
downscoped access_token. It's much simpler, since the client knows which =
RS it's going to send the token to, to provide that when requesting =
tokens.

    The complication comes when =
exchanging the code for the tokens, it needs to specify all possible =
audiences (rsid's) it might send the token to based on the requested =
scopes. There will be a fair amount of complex logic at the AS to ensure =
the correct behavior. I do worry about this complexity.

    We are of course assuming that a hacker needs to use the real =
AS authorize endpoint to succeed in obtaining an access token(it can't =
be mitm'd). Once the grant is obtained by the client, the threat comes =
when the client uses the grant at a mitm'd token endpoint OR an access =
token at a mitm'd resource endpoint. 

    So the AS and its config set becomes =
the trust anchor. Binding allows us to extend trust to the RS discovery =
giving some assurance that a client has a correct set of endpoints =
including resource. 
    Are you recommending that the AS metadata provide a list of =
the 'rsid' supported by the AS?
    No.  I =
think that is a bad idea.  Better to use an identity oracle =
function and say, give me the config for rsid=3Dxyz
    Good=
 :)

    That =
also allows a common AS discovery endpoint to actually do discovery for =
multiple AS systems.  E.g. to configure a client to a specific AS =
service designated by the customer paying for the resource service. =
 

    IOW. by =
providing a resource query, the meta-data config discovery actually =
looks more like discovery.  :-)

    John's solution requires translating aud to res url and =
changes to core oauth. He seems to imply there is a need for ongoing =
validation of resource. I'm not yet convinced that is really needed. =
 Maybe it is needed because the client could be convinced to follow =
a link embedded in a resource that is somehow not part of the defined =
audience?

    Thanks

    Phil

    On Mar 16, 2016, at 08:57, George Fletcher =
<gffletch@aol.com> wrote:

    So, in =
thinking about all this AS restricting tokens to RS and "discovery" of =
RS endpoints, etc. I wondered why we don't just leverage RS metadata =
like we have AS metadata.

    For an AS we =
require an 'iss' claim to use as an identifier of the AS. We could do =
the same with RS metadata retrieving the metadata from a .well-known =
location and including a claim of 'rsid' to use as an identifier of the =
Resource Server.

    This 'rsid' identifier =
could then be used for registration with the AS and presentation by the =
client when requesting tokens.

    This =
provides a separation between an identifier for a resource and the =
specific endpoints the token will be sent to. A client could "discover" =
the necessary endpoint on a periodic basis and use a single identifier =
with the AS for any of the endpoints or scopes supported by the RS. If =
desired the RS could expose the supported scopes in the RS metadata =
file.

    Thoughts?

    Thanks,
    George
    _______________________________________________
    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


    --=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


    =

--Apple-Mail=_76B3F576-4274-4367-981B-A731356EF681--


From nobody Thu Mar 17 09:27:49 2016
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 4763212D93D for ; Thu, 17 Mar 2016 09:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.192
X-Spam-Level: 
X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 bhtpMF3vykQi for ; Thu, 17 Mar 2016 09:27:42 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 F20E012D9B1 for ; Thu, 17 Mar 2016 09:27:41 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2HGRYZC001482 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Mar 2016 16:27:35 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2HGRXNq000569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2016 16:27:34 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2HGRXkP015509; Thu, 17 Mar 2016 16:27:33 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Mar 2016 09:27:33 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_00F34336-5807-4376-BC1B-65156309AA77"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com>
Date: Thu, 17 Mar 2016 09:27:31 -0700
Message-Id: <448DED6D-9DA6-4DA4-A107-A0E56F5060EF@oracle.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <56EAC287.30601@aol.com> <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 16:27:47 -0000

--Apple-Mail=_00F34336-5807-4376-BC1B-65156309AA77
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


I think in the mis-configuration case, it is different form the redirect =
issues.

What we are concerned about is an attackers ability to convince the =
client to set up a connection via an attackers proxy which can even have =
a valid TLS enabled.  The client won=E2=80=99t know it has done =
something wrong. In fact it will confirm it has correctly connected to =
the attackers proxy.

I don=E2=80=99t believe we have to have exact-match to work here.  We =
need preferable an exact host match.=20

I agree there can be a redirect issue pop up once we allow domain =
matching.  What we could ask the client to do is reconfirm discovery =
when it receives a redirect from a resource.  I=E2=80=99m not a fan of =
this because it depends on the client doing something that seems =
optional (even when it isn=E2=80=99t).  BUT=E2=80=A6.this might be the =
out for SP=E2=80=99s like George=E2=80=99s case where they don=E2=80=99t =
know the exact URL=E2=80=99s clients will be using.


Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 17, 2016, at 8:48 AM, John Bradley  wrote:
>=20
> The problem is similar to the one with redirect_uri,  if you allow =
user hosted content on the domain they will be able to get the token if =
it is sent as a query parameter, and might be able to if it is sent as a =
header. =20
>=20
> Unfortunately many OAuth clients are badly behaved and make use of the =
query parameter not considering the security issues.
>=20
> Anything other than the AS or the client doing an exact URI match is =
going to leave some hole.
>=20
> This is why we are working on POP that is the correct way to solve =
this for AS.
>=20
> I think anything other than the client giving the AS the whole URI and =
the AS including that as a audience/destination and letting the RS =
figure out if it is correct is largely hopeless, as it will be to =
fragile or the client won=E2=80=99t do it. =20
>=20
> In the case of Phil=E2=80=99s proposal the discovery happens once at =
client setup so the AS has no idea if the client checked  before issuing =
the token.
>=20
> I honestly think there are two viable options:
> 1 PoP tokens
> 2 Including the destination URI / RS URI (pick name) in the token in =
full and letting the RS decide if it has been man in the middled.
>=20
> Everything else will be an endless game of wack-a-mole that increases =
complexity but gets little real security.
>=20
> John B.
>=20
>=20
>> On Mar 17, 2016, at 11:43 AM, George Fletcher > wrote:
>>=20
>> If one of the APIs has an open-redirect problem, won't that cause the =
token to leak to the attacker? That's why we went to exact match in =
OpenID Connect. Does it not apply in this case?
>>=20
>> Thanks,
>> George
>>=20
>> On 3/17/16 2:42 AM, Nat Sakimura wrote:
>>> IMHO, list of URIs that represent the partial paths under the same =
authority would not be too onerous.=C2=A0 <>
>>> =20
>>> e.g., if you have=20
>>> =20
>>> https://example.com/apis/v1/userinfo =

>>> https://example.com/apis/v2/userinfo =

>>> https://example.org/some/api/endpoint =

>>> =20
>>> etc., then the AS may provide=20
>>> =20
>>> https://example.com/apis/ 
>>> https://example.org/ 
>>> =20
>>> or something like that in the audiences.=20
>>> =20
>>> A completely new domain should not be trusted blindly.=20
>>> The resource should at least make sure to provide the domain as =
being under the same authority.=20
>>> =20
>>> Bearer Token is a Password. It should not be shared among different =
authorities.=20
>>> =20
>>> Best,=20
>>> =20
>>> Nat
>>> =20
>>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
>>> Sent: Wednesday, March 16, 2016 3:15 AM
>>> To: John Bradley  ; =
Brian Campbell  =

>>> Cc:    =

>>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>> =20
>>> (..snip..)=20
>>>=20
>>> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.
>>>=20
>>>=20
>>> (..snip..)
>>>=20
>>> --
>>> PLEASE READ :This e-mail is confidential and intended for the
>>> named recipient only. If you are not an intended recipient,
>>> please notify the sender  and delete this e-mail.
>>> =20
>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_00F34336-5807-4376-BC1B-65156309AA77
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



    I think in the =
mis-configuration case, it is different form the redirect issues.

    What we are concerned =
about is an attackers ability to convince the client to set up a =
connection via an attackers proxy which can even have a valid TLS =
enabled.  The client won=E2=80=99t know it has done something =
wrong. In fact it will confirm it has correctly connected to the =
attackers proxy.

    I don=E2=80=99t believe we have to have exact-match to work =
here.  We need preferable an exact host match. 

    I agree there can be a =
redirect issue pop up once we allow domain matching.  What we could =
ask the client to do is reconfirm discovery when it receives a redirect =
from a resource.  I=E2=80=99m not a fan of this because it depends =
on the client doing something that seems optional (even when it =
isn=E2=80=99t).  BUT=E2=80=A6.this might be the out for SP=E2=80=99s =
like George=E2=80=99s case where they don=E2=80=99t know the exact =
URL=E2=80=99s clients will be using.


    


    

    

    On Mar 17, 2016, at 8:48 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    The problem is =
similar to the one with redirect_uri,  if you allow user hosted =
content on the domain they will be able to get the token if it is sent =
as a query parameter, and might be able to if it is sent as a header. =
 

    Unfortunately =
many OAuth clients are badly behaved and make use of the query parameter =
not considering the security issues.

    Anything other than the AS or the =
client doing an exact URI match is going to leave some hole.

    This is why we are =
working on POP that is the correct way to solve this for AS.

    I think anything other =
than the client giving the AS the whole URI and the AS including that as =
a audience/destination and letting the RS figure out if it is correct is =
largely hopeless, as it will be to fragile or the client won=E2=80=99t =
do it.  

    In=
 the case of Phil=E2=80=99s proposal the discovery happens once at =
client setup so the AS has no idea if the client checked  before =
issuing the token.

    I honestly think there are two viable options:
    1 PoP tokens
    2 Including the destination =
URI / RS URI (pick name) in the token in full and letting the RS decide =
if it has been man in the middled.

    Everything else will be an endless game =
of wack-a-mole that increases complexity but gets little real =
security.

    John =
B.


    On Mar 17, 2016, at 11:43 AM, George Fletcher <gffletch@aol.com> =
wrote:

    If one of the APIs has an open-redirect =
problem, won't that cause the token to leak to the attacker? That's why =
we went to exact match in OpenID Connect. Does it not apply in this =
case?

    Thanks,
    George

    On 3/17/16 2:42 AM, Nat Sakimura wrote:
    IMHO, list of =
URIs that represent the partial paths under the same authority would not =
be too onerous. 
     
    e.g., if you have 
     
    https://example.com/apis/v1/userinfo
    https://example.com/apis/v2/userinfo
    https://example.org/some/api/endpoint
     
    etc., then the =
AS may provide 
     
    https://example.com/apis/
    https://example.org/
     
    or something like that in the =
audiences. 
     
    A completely new =
domain should not be trusted blindly. 
    The resource should at least make sure to provide =
the domain as being under the same authority. 
     
    Bearer Token is =
a Password. It should not be shared among different authorities. 
     
    Best, 
     
    Nat
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of George =
Fletcher
    Sent: Wednesday, March 16, 2016 =
3:15 AM
    To: John Bradley <ve7jtb@ve7jtb.com>; Brian Campbell <bcampbell@pingidentity.com>
    Cc: <oauth@ietf.org> <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    (..snip..) 
    I'm not sure =
passing the full endpoint to the AS will help with my concerns... The AS =
could potentially do a webfinger on the resource URI and determine if =
it's an RS that it supports... though that requires all RS's to support =
webfinger. What I really want to avoid is the AS having this list of =
URIs to RS that is almost assuredly to get out of sync.

    (..snip..)
    --
    PLEASE READ :This e-mail is =
confidential and intended for the
    named recipient only. If you are not an intended =
recipient,
    please notify the =
sender  and delete this e-mail.
     



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

    =

--Apple-Mail=_00F34336-5807-4376-BC1B-65156309AA77--


From nobody Thu Mar 17 09:35:03 2016
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 F178212D95F for ; Thu, 17 Mar 2016 09:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.192
X-Spam-Level: 
X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 DiB3jlVJLvSy for ; Thu, 17 Mar 2016 09:34:58 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 7325B12D50D for ; Thu, 17 Mar 2016 09:34:48 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2HGYin8021670 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2016 16:34:45 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2HGYhhU012383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2016 16:34:44 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2HGYgpF018635; Thu, 17 Mar 2016 16:34:42 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Mar 2016 09:34:42 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_412C3C74-18C5-49C4-BC85-62F28A3EEC7E"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <009a01d18018$33bfe700$9b3fb500$@nri.co.jp>
Date: Thu, 17 Mar 2016 09:34:40 -0700
Message-Id: <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp>
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 16:35:02 -0000

--Apple-Mail=_412C3C74-18C5-49C4-BC85-62F28A3EEC7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1 for Nat's last few emails (avoiding generating too much traffic :-).

Re: below, this is where I was thinking of masking/filter in bound =
config.  The main thing that needs to be checked at=20
configuration time is whether the client has a valid set of server host =
names to prevent a malicious proxy.

So all the examples you mention below do boil down to =
https://example.org or https://example.com

It=E2=80=99s not that the AS needs to return them. It simply needs to =
match them. If one of them matches, then the oauth config can be =
returned.

I do agree re-directs (of the ESPN scenario) can become an issue if a =
discovery system matches on *.example.com.  It presumes there are no =
open redirect servers in the example.com domain.  As I mention in =
another email, we should discuss what happens when any oauth connection =
is redirected.  Should the client re-validate the configuration?

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 16, 2016, at 11:42 PM, Nat Sakimura  =
wrote:
>=20
> IMHO, list of URIs that represent the partial paths under the same =
authority would not be too onerous.=C2=A0 <>
> =20
> e.g., if you have=20
> =20
> https://example.com/apis/v1/userinfo =

> https://example.com/apis/v2/userinfo =

> https://example.org/some/api/endpoint =

> =20
> etc., then the AS may provide=20
> =20
> https://example.com/apis/ 
> https://example.org/ 
> =20
> or something like that in the audiences.=20
> =20
> A completely new domain should not be trusted blindly.=20
> The resource should at least make sure to provide the domain as being =
under the same authority.=20
> =20
> Bearer Token is a Password. It should not be shared among different =
authorities.=20
> =20
> Best,=20
> =20
> Nat
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
> Sent: Wednesday, March 16, 2016 3:15 AM
> To: John Bradley >; Brian =
Campbell >
> Cc: > >
> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
> =20
> (..snip..)=20
>=20
> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.
>=20
>=20
> (..snip..)
>=20
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender  and delete this e-mail.
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =



--Apple-Mail=_412C3C74-18C5-49C4-BC85-62F28A3EEC7E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 for Nat's last few emails (avoiding generating too much =
traffic :-).

    Re: =
below, this is where I was thinking of masking/filter in bound config. =
 The main thing that needs to be checked at 
    configuration time is whether the client has a valid set of =
server host names to prevent a malicious proxy.

    So all the examples you mention below =
do boil down to https://example.org or https://example.com

    It=E2=80=99s not that the AS needs to =
return them. It simply needs to match them. If one of them matches, then =
the oauth config can be returned.

    I do agree re-directs (of the ESPN =
scenario) can become an issue if a discovery system matches on *.example.com.  It =
presumes there are no open redirect servers in the example.com domain.  As =
I mention in another email, we should discuss what happens when any =
oauth connection is redirected.  Should the client re-validate the =
configuration?

    


    

    

    On Mar 16, 2016, at 11:42 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

    IMHO, list of URIs that represent the partial =
paths under the same authority would not be too onerous. 
     
    e.g., if you have 
     
    https://example.com/apis/v1/userinfo
    https://example.com/apis/v2/userinfo
    https://example.org/some/api/endpoint
     
    etc., then the =
AS may provide 
     
    https://example.com/apis/
    https://example.org/
     
    or something like that in the =
audiences. 
     
    A completely new =
domain should not be trusted blindly. 
    The resource should at least make sure to provide =
the domain as being under the same authority. 
     
    Bearer Token is =
a Password. It should not be shared among different authorities. 
     
    Best, 
     
    Nat
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of George =
Fletcher
    Sent: Wednesday, March 16, 2016 =
3:15 AM
    To: John Bradley <ve7jtb@ve7jtb.com>; Brian =
Campbell <bcampbell@pingidentity.com>
    Cc: <oauth@ietf.org> <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    (..snip..) 
    I'm not sure =
passing the full endpoint to the AS will help with my concerns... The AS =
could potentially do a webfinger on the resource URI and determine if =
it's an RS that it supports... though that requires all RS's to support =
webfinger. What I really want to avoid is the AS having this list of =
URIs to RS that is almost assuredly to get out of sync.

    (..snip..)
    --
    PLEASE READ :This e-mail is confidential and intended for =
the
    named recipient only. If you are not an intended =
recipient,
    please notify the sender  and delete this e-mail.
     
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    =

--Apple-Mail=_412C3C74-18C5-49C4-BC85-62F28A3EEC7E--


From nobody Thu Mar 17 10:07:15 2016
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 1A58412D9D9 for ; Thu, 17 Mar 2016 10:07:14 -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=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 E2uY4tWApWkv for ; Thu, 17 Mar 2016 10:07:10 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 DA94F12DC3D for ; Thu, 17 Mar 2016 10:06:12 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id p65so35187560wmp.1 for ; Thu, 17 Mar 2016 10:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IGrZ2HgaKui9bUBFDSaBEUsdwOBQi9cdWG9hhPeZqzw=; b=cE8jebeN/GftWU/Y/65AR0EDgkJERQrUDrHb+Xt+O2Sbxna4kg88R7Dv6FbTHcI5f4 L8cHmVMGBqpcflVrS1wlsvIciKhJVRLehHOCfkHLYIXb/0Am32OXUrtC3yDYh3olRBX/ +7FhonQbPGWVa+PfJfrnTUkQL8Kuqe8CNlUW0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IGrZ2HgaKui9bUBFDSaBEUsdwOBQi9cdWG9hhPeZqzw=; b=KIxteH0nq9v6+L6bjBdhEq6JO5wuLVBRShougjpi36Rw64jt+2ZP7+Cz0mfgq9nHf5 rBqYScEQHmYomMnBmwEexsBhNXVeIS0Uf129zY7DFcj+MORtfdpv1d3EQt0AnPX1tqgI ldCM8IB7aFXBl3X7Twnc2b9A31hqMoucv6IYFgJ4zpfGGyc67iwkNEmjphckd/1WINsW vgmY6CBRHx0VbHao6VEccAcBzSZ6B3fBegitFszJH8sq6qF2WveoG5cvFLIDlQcRpqFe oCMEP8m1yzElpEwlcx/fUe3qRNZclW7w9E316BxW9i+V12wKgAXkh0yjWxAkylccHJ9s JnDQ==
X-Gm-Message-State: AD7BkJLFLbpuOdlAslGFNImB7AEHrdXzaA/6+bWbn18cxkXYCi9EKmQWSy0jgld3Zn58zuai
X-Received: by 10.28.50.133 with SMTP id y127mr36340642wmy.4.1458234371389; Thu, 17 Mar 2016 10:06:11 -0700 (PDT)
Received: from [192.168.12.137] ([81.144.134.66]) by smtp.gmail.com with ESMTPSA id d2sm8524675wjf.28.2016.03.17.10.06.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 10:06:10 -0700 (PDT)
To: Phil Hunt , George Fletcher 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com> <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com>
From: Hans Zandbelt 
Message-ID: <56EAE401.6090608@pingidentity.com>
Date: Thu, 17 Mar 2016 17:06:09 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:07:14 -0000

I'm sorry to keep pushing on this but the attack is not opened up by 
discovery, having two fixed ASes is already a threat: multiple ASes in 
general leaves the client exposed. Discovery just increases the attack 
surface.

Hans.

On 3/17/16 4:16 PM, Phil Hunt wrote:
> George,
>
> For the attacks we looked at in Darmstadt, we discussed that in order
> for the attack to succeed (at least as envisioned), the attacker needs
> to have the client invoke the real authorize endpoint in order for the
> user to be successful in issuing the grant.
>
> Assuming that it is the case, the attacker can use a proxied token
> endpoint or a proxied resource endpoint.  A client that doesn’t know
> what the real endpoint should be could be confused depending on how
> discovery occurs.
>
> Keep in mind that the token endpoint and the resource communications
> happens in the back channel. The user is never going to see the URL that
> has been invoked.  So….we need to make sure the set of endpoints are
> bound together or  confirmed.
>
> Note: This hasn’t been a big issue to date because current apps tend to
> work with fixed or singleton infrastructure.
>
> One we expand OAuth out to scenarios where there are multiple service
> providers with different relationships with OAuth AS’s, we move into
> this dynamic category that opens the threat.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Mar 17, 2016, at 7:36 AM, George Fletcher > > wrote:
>>
>>
>>
>> On 3/16/16 6:37 PM, John Bradley wrote:
>>> I agree with Phil that the client can’t trust any abstract identifier
>>> that it might get from a bad RS unless it is were a URI that the
>>> client or AS could deference to get a list of the concrete URI for
>>> the RS.
>> I guess I'm confused on this front as we are asking the client to
>> "trust" the AS identifier that is being returned by the AS as well as
>> the value the client gets from discovery if it uses that method to
>> obtain the AS endpoints.
>>
>> I don't understand why the same philosophy can't be used for Resource
>> Service identifier and endpoints.
>>>
>>> That seems like a lot of work that clients are unlikely to do.
>> If I can discover the RS endpoints once and cache them, that doesn't
>> seem that difficult. This only applies to clients that have some
>> support for dynamically accepting RS's and their endpoints.
>>
>> For clients that only support a single AS we are saying they can get
>> the AS identifier out-of-band and use that. We can easily do the same
>> thing for an RS identifier. They can either get it out-of-band (i.e.
>> hardcoded) or they can get them dynamically (not likely initially but
>> we shouldn't preclude it).
>>>
>>> A AS might do it if it wanted to look up the identifier for a given
>>> resource.
>>>
>>> Something like do get on resource get back Abstract identifier
>>> (probably well known location, as recently pointed out in another
>>> thread you can’t allow it to point to user content.)
>> Yes, you could do it this way, though the client still needs to get
>> those endpoints and if it's doing it dynamically, it will likely use
>> the same method to discover the endpoints:)
>>>
>>> The AS gets the file and maps the uri to a abstract identifier for
>>> audience.
>>>
>>> I guess that would be one way that you could map AS URI to a abstract
>>> identifier, but I wouldn’t want to count on clients doing it.
>> This will work fine, if the client has hardcoded endpoints.
>>
>> My main concern is that I don't want the AS to have to manage a map of
>> endpoint URLs for each RS it's supporting.
>>
>> Think of an RS that supports multiple AS's. If the RS adds a new
>> endpoint, that endpoint can't go live until each AS receives the
>> endpoint and adds it to it's map. That is a deployment nightmare. The
>> mapping of RS to current endpoints has to dynamic even if it's done by
>> the AS rather than the client.
>>
>> Wildcard'ing the endpoint URLs or only using domains, I don't think
>> will work as we've proven that open redirect holes break this
>> thinking. It needs to be an exact match.
>>>
>>> John B.
>>>
>>>
>>>
>>>
>>>
>>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt >>> > wrote:
>>>>
>>>> George,
>>>>
>>>> Thanks. It would be good to get a draft that sketches out the
>>>> overall picture of this for BA — even if in very rough form given
>>>> the deadline is monday.  Or, maybe just a PPT walkthru.
>>>>
>>>> Interested to see what comes out.
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher
>>>>> <gffletch@aol.com> wrote:
>>>>>
>>>>> Inline...
>>>>>
>>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher
>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>>> George
>>>>>>>>
>>>>>>>> Very good question...
>>>>>>>>
>>>>>>>> I considered that the RS metadata discovery could be fake.
>>>>>>> Same way that the 'iss' claim must "match" the url used to
>>>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>>>> -- I think that should suffice to ensuring the 'rsid' identifier
>>>>>>> can't be spoofed by another site
>>>>>>
>>>>>> So the attacker makes iss and url match for the resource
>>>>>> discovery. Yet the AS service provider doesn’t know where the
>>>>>> client is using the tokens.  How would the client or the AS detect
>>>>>> that the wrong iss was given?
>>>>> Because if the attacker makes the rsid and the url match, then the
>>>>> client will submit an rsid that isn't "registered" with the AS and
>>>>> the AS won't issue the token. This assumes the client is not
>>>>> talking to an evil AS (as there are other mitigations for that case).
>>>>>>
>>>>>>>>
>>>>>>>> So the final step in configuration validation is to bind the
>>>>>>>> relationship between as and rs discovery together to confirm the
>>>>>>>> relationship is valid.
>>>>>>> And what I'd like to see is the 'rsid' value used to represent
>>>>>>> the RS rather than some unique endpoint (even if wildcards are
>>>>>>> allowed)
>>>>>>
>>>>>> Long term, I think this would be better. Do we have a way to issue
>>>>>> RSID values in the works?
>>>>> No, but that is what this email thread is contemplating:) Just as
>>>>> the AS iss value is selfdefined by the AS, the rsid should be
>>>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
>>>>> is a mirror of how the AS 'iss' claim is defined for the AS in it's
>>>>> metadata.
>>>>>>
>>>>>> That said, I would have thought this is more ownerous than
>>>>>> checking *.example.com matches the given URL
>>>>>> by the client.
>>>>> My problem with the URL level checking is that a RS may
>>>>> legitimately have endpoints on multiple domains. An RS may move
>>>>> endpoints from one domain to another (say when moving from version
>>>>> 1 to version 2 of an API). Using the rsid for audience restriction
>>>>> and as an indirect mechanism for specifying actual endpoints, the
>>>>> RS has a much looser coupling with the AS.
>>>>>
>>>>> AS we move into "federated authorization" meaning that an RS
>>>>> outsources it's API authorization to one or more AS's, this will
>>>>> become more important.
>>>>>>>
>>>>>>> Another step that may be required is for the RS to return it's
>>>>>>> 'rsid' in the realm field of the WWW-Authenticate response
>>>>>>> header. This allows a client to discover metadata about the RS
>>>>>>> and it's endpoints. It also allows the client to determine if the
>>>>>>> 'rsid' returned by the RS matches the 'rsid' it is expecting.
>>>>>>
>>>>>> Agreed. This might work. But should the check be when the client
>>>>>> asks for the configuration metadata or when the client asks for
>>>>>> tokens?  I think it only needs to happen at config time.
>>>>> What I see here is that the desire is to audience protect tokens.
>>>>> To do that, the audience need to be specified everytime a token is
>>>>> requested. I really don't the AS to have to manage the complex
>>>>> state of which audiences have previously been issued to
>>>>> refresh_tokens and then reconstruct the correct audience for a
>>>>> requested downscoped access_token. It's much simpler, since the
>>>>> client knows which RS it's going to send the token to, to provide
>>>>> that when requesting tokens.
>>>>>
>>>>> The complication comes when exchanging the code for the tokens, it
>>>>> needs to specify all possible audiences (rsid's) it might send the
>>>>> token to based on the requested scopes. There will be a fair amount
>>>>> of complex logic at the AS to ensure the correct behavior. I do
>>>>> worry about this complexity.
>>>>>>>>
>>>>>>>> We are of course assuming that a hacker needs to use the real AS
>>>>>>>> authorize endpoint to succeed in obtaining an access token(it
>>>>>>>> can't be mitm'd). Once the grant is obtained by the client, the
>>>>>>>> threat comes when the client uses the grant at a mitm'd token
>>>>>>>> endpoint OR an access token at a mitm'd resource endpoint.
>>>>>>>>
>>>>>>>> So the AS and its config set becomes the trust anchor. Binding
>>>>>>>> allows us to extend trust to the RS discovery giving some
>>>>>>>> assurance that a client has a correct set of endpoints including
>>>>>>>> resource.
>>>>>>> Are you recommending that the AS metadata provide a list of the
>>>>>>> 'rsid' supported by the AS?
>>>>>> No.  I think that is a bad idea.  Better to use an identity oracle
>>>>>> function and say, give me the config for rsid=xyz
>>>>> Good :)
>>>>>>
>>>>>> That also allows a common AS discovery endpoint to actually do
>>>>>> discovery for multiple AS systems.  E.g. to configure a client to
>>>>>> a specific AS service designated by the customer paying for the
>>>>>> resource service.
>>>>>>
>>>>>> IOW. by providing a resource query, the meta-data config discovery
>>>>>> actually looks more like discovery.  :-)
>>>>>>>>
>>>>>>>> John's solution requires translating aud to res url and changes
>>>>>>>> to core oauth. He seems to imply there is a need for ongoing
>>>>>>>> validation of resource. I'm not yet convinced that is really
>>>>>>>> needed.  Maybe it is needed because the client could be
>>>>>>>> convinced to follow a link embedded in a resource that is
>>>>>>>> somehow not part of the defined audience?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher  wrote:
>>>>>>>>
>>>>>>>>> So, in thinking about all this AS restricting tokens to RS and
>>>>>>>>> "discovery" of RS endpoints, etc. I wondered why we don't just
>>>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>>>
>>>>>>>>> For an AS we require an 'iss' claim to use as an identifier of
>>>>>>>>> the AS. We could do the same with RS metadata retrieving the
>>>>>>>>> metadata from a .well-known location and including a claim of
>>>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>>>
>>>>>>>>> This 'rsid' identifier could then be used for registration with
>>>>>>>>> the AS and presentation by the client when requesting tokens.
>>>>>>>>>
>>>>>>>>> This provides a separation between an identifier for a resource
>>>>>>>>> and the specific endpoints the token will be sent to. A client
>>>>>>>>> could "discover" the necessary endpoint on a periodic basis and
>>>>>>>>> use a single identifier with the AS for any of the endpoints or
>>>>>>>>> scopes supported by the RS. If desired the RS could expose the
>>>>>>>>> supported scopes in the RS metadata file.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> George
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>
>>
>> --
>> Chief Architect
>> Identity Services Engineering     Work:george.fletcher@teamaol.com
>> AOL Inc.                          AIM:  gffletch
>> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
>> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Thu Mar 17 10:19:55 2016
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 57B5612DD6C for ; Thu, 17 Mar 2016 10:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level: 
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, 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=mx.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 MP6qWHbJ0xuM for ; Thu, 17 Mar 2016 10:19:51 -0700 (PDT)
Received: from omr-m004e.mx.aol.com (omr-m004e.mx.aol.com [204.29.186.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0E312DCAF for ; Thu, 17 Mar 2016 10:14:55 -0700 (PDT)
Received: from mtaout-mce01.mx.aol.com (mtaout-mce01.mx.aol.com [172.29.27.205]) by omr-m004e.mx.aol.com (Outbound Mail Relay) with ESMTP id EBE9538000C0; Thu, 17 Mar 2016 13:14:54 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mce01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 818B13800009D; Thu, 17 Mar 2016 13:14:53 -0400 (EDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <56EAC287.30601@aol.com> <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAE60D.8080703@aol.com>
Date: Thu, 17 Mar 2016 13:14:53 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------040807010509040001030607"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458234894; bh=WpHMNLZPsmEFthpR6o5mo6K5Czrwn2eNKpApUdYh0Vw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=PF79n06HLoJXUrNUdrwcVNHFUG5s1xBeJKZ89wLntNr1RorTCqPuy44+O2w7hBPHs GvGFY15Ry3ouX8NJxHFyShohrErNMmZuhZeiwEzeQSdRbEwVtzJkpg2dvPOdUo8O6E 6+zlL+MFMeV1IhUr1XaP3xyMnhRF49iVq7iI+aME=
x-aol-sid: 3039ac1d1bcd56eae60d2984
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:19:54 -0000

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

If this assumption is true, then there is really no point to try and 
come up with a middle ground. If the client MUST present the full 
endpoint URL to protect against possible open-redirect flaws then we 
have the following case.

Client implements an instant messaging app. For the client to work, it 
needs to invoke 25 different APIs at the Instant Messaging service. When 
the client goes to get a token with scopes "sendIM" and "readBuddyList" 
it MUST present all 25 endpoint URLs so that the AS can determine if any 
of them are possible MITM endpoints.

This means the AS has to have a map (or be able to construct a map) of 
all 25 endpoints to the RS that implements the Instant Messaging 
service. This will be come a non-managable map quickly.

Now suppose the client also wants to show a new mail count and wants to 
add a scope of "mailCount". That might only be one additional API, but 
it's easy to extrapolate to this becoming untenable as well.

Thanks,
George

On 3/17/16 11:48 AM, John Bradley wrote:
> The problem is similar to the one with redirect_uri,  if you allow 
> user hosted content on the domain they will be able to get the token 
> if it is sent as a query parameter, and might be able to if it is sent 
> as a header.
>
> Unfortunately many OAuth clients are badly behaved and make use of the 
> query parameter not considering the security issues.
>
> Anything other than the AS or the client doing an exact URI match is 
> going to leave some hole.
>
> This is why we are working on POP that is the correct way to solve 
> this for AS.
>
> I think anything other than the client giving the AS the whole URI and 
> the AS including that as a audience/destination and letting the RS 
> figure out if it is correct is largely hopeless, as it will be to 
> fragile or the client won’t do it.
>
> In the case of Phil’s proposal the discovery happens once at client 
> setup so the AS has no idea if the client checked  before issuing the 
> token.
>
> I honestly think there are two viable options:
> 1 PoP tokens
> 2 Including the destination URI / RS URI (pick name) in the token in 
> full and letting the RS decide if it has been man in the middled.
>
> Everything else will be an endless game of wack-a-mole that increases 
> complexity but gets little real security.
>
> John B.
>
>
>> On Mar 17, 2016, at 11:43 AM, George Fletcher > > wrote:
>>
>> If one of the APIs has an open-redirect problem, won't that cause the 
>> token to leak to the attacker? That's why we went to exact match in 
>> OpenID Connect. Does it not apply in this case?
>>
>> Thanks,
>> George
>>
>> On 3/17/16 2:42 AM, Nat Sakimura wrote:
>>> IMHO, list of URIs that represent the partial paths under the same 
>>> authority would not be too onerous.
>>> e.g., if you have
>>> https://example.com/apis/v1/userinfo
>>> https://example.com/apis/v2/userinfo
>>> https://example.org/some/api/endpoint
>>> etc., then the AS may provide
>>> https://example.com/apis/
>>> https://example.org/
>>> or something like that in the audiences.
>>> A completely new domain should not be trusted blindly.
>>> The resource should at least make sure to provide the domain as 
>>> being under the same authority.
>>> Bearer Token is a Password. It should not be shared among different 
>>> authorities.
>>> Best,
>>> Nat
>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*George 
>>> Fletcher
>>> *Sent:*Wednesday, March 16, 2016 3:15 AM
>>> *To:*John Bradley; Brian 
>>> Campbell
>>> *Cc:*
>>> *Subject:*Re: [OAUTH-WG] New Version Notification for 
>>> draft-hunt-oauth-bound-config-00.txt
>>>
>>> (..snip..)
>>>
>>> I'm not sure passing the full endpoint to the AS will help with my 
>>> concerns... The AS could potentially do a webfinger on the resource 
>>> URI and determine if it's an RS that it supports... though that 
>>> requires all RS's to support webfinger. What I really want to avoid 
>>> is the AS having this list of URIs to RS that is almost assuredly to 
>>> get out of sync.
>>>
>>> (..snip..)
>>>
>>> --
>>> PLEASE READ :This e-mail is confidential and intended for the
>>> named recipient only. If you are not an intended recipient,
>>> please notify the sender  and delete this e-mail.
>>
>>


--------------040807010509040001030607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    If this assumption is
      true, then there is really no point to try and come up with a
      middle ground. If the client MUST present the full endpoint URL to
      protect against possible open-redirect flaws then we have the
      following case.
    
      
    
      Client implements an instant messaging app. For the client to
      work, it needs to invoke 25 different APIs at the Instant
      Messaging service. When the client goes to get a token with scopes
      "sendIM" and "readBuddyList" it MUST present all 25 endpoint URLs
      so that the AS can determine if any of them are possible MITM
      endpoints.
    
      
    
      This means the AS has to have a map (or be able to construct a
      map) of all 25 endpoints to the RS that implements the Instant
      Messaging service. This will be come a non-managable map quickly.
    
      
    
      Now suppose the client also wants to show a new mail count and
      wants to add a scope of "mailCount". That might only be one
      additional API, but it's easy to extrapolate to this becoming
      untenable as well.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/17/16 11:48 AM, John Bradley
      wrote:
    
    
    
    
    
      
      The problem is similar to the one with redirect_uri,  if you allow
      user hosted content on the domain they will be able to get the
      token if it is sent as a query parameter, and might be able to if
      it is sent as a header.  
      

    
      
    
      
    Unfortunately many OAuth clients are badly behaved
        and make use of the query parameter not considering the security
        issues.
    
      

    
      
    
      
    Anything other than the AS or the client doing an
        exact URI match is going to leave some hole.
    
      

    
      
    
      
    This is why we are working on POP that is the
        correct way to solve this for AS.
    
      

    
      
    
      
    I think anything other than the client giving the AS
        the whole URI and the AS including that as a
        audience/destination and letting the RS figure out if it is
        correct is largely hopeless, as it will be to fragile or the
        client won’t do it.  
    
      

    
      
    
      
    In the case of Phil’s proposal the discovery happens
        once at client setup so the AS has no idea if the client checked
         before issuing the token.
    
      

    
      
    
      
    I honestly think there are two viable options:
    
      
    1 PoP tokens
    
      
    2 Including the destination URI / RS URI (pick name)
        in the token in full and letting the RS decide if it has been
        man in the middled.
    
      

    
      
    
      
    Everything else will be an endless game of
        wack-a-mole that increases complexity but gets little real
        security.
    
      

    
      
    
      
    John B.
    
      

    
      
    
      

    
        
    
          
    
            
    On Mar 17, 2016, at 11:43 AM, George Fletcher
              <gffletch@aol.com>
              wrote:
    
            
    
            
    If one of the APIs has an open-redirect
                problem, won't that cause the token to leak to the
                attacker? That's why we went to exact match in OpenID
                Connect. Does it not apply in this case?
    
                
    
                Thanks,
    
                George
    
              
    
              
    On 3/17/16 2:42 AM, Nat Sakimura
                wrote:
    
              
    
              
    
                
    
                  
                  
     
    
                  
    e.g., if you have 
    
                  
     
    
                  
                  
                  
                  
     
    
                  
    etc., then the AS may provide 
    
                  
     
    
                  
                  
                  
     
    
                  
    or something like that in the
                      audiences. 
    
                  
     
    
                  
    A completely new domain should not be
                      trusted blindly. 
    
                  
    The resource should at least make
                      sure to provide the domain as being under the same
                      authority. 
    
                  
     
    
                  
    Bearer Token is a Password. It should
                      not be shared among different authorities. 
    
                  
     
    
                  
    Best, 
    
                  
     
    
                  
    Nat
    
                  
     
    
                  
    
                    
    
                      
    From: OAuth
                          [mailto:oauth-bounces@ietf.org] On Behalf Of George
                          Fletcher
    
                          Sent: Wednesday,
                          March 16, 2016 3:15 AM
    
                          To: John
                          Bradley <ve7jtb@ve7jtb.com>;
                          Brian Campbell <bcampbell@pingidentity.com>
    
                          Cc: <oauth@ietf.org> <oauth@ietf.org>
    
                          Subject: Re:
                          [OAUTH-WG] New Version Notification for
                          draft-hunt-oauth-bound-config-00.txt
    
                    
    
                  
    
                  
     
    
                  
    (..snip..) 
    
                  
    I'm not sure passing the
                      full endpoint to the AS will help with my
                      concerns... The AS could potentially do a
                      webfinger on the resource URI and determine if
                      it's an RS that it supports... though that
                      requires all RS's to support webfinger. What I
                      really want to avoid is the AS having this list of
                      URIs to RS that is almost assuredly to get out of
                      sync.
    
                      
    
                    
    
                  
    (..snip..)
    
                  
    --
    
                  
    PLEASE
                      READ :This e-mail is confidential and intended for
                      the
    
                  
    named
                      recipient only. If you are not an intended
                      recipient,
    
                  
    please
                      notify the sender  and delete this e-mail.
    
                  
     
    
                
    
              
    
              
    
              
    
            
    
          
    
        
    
      
    
    
    
    
    
  


--------------040807010509040001030607--


From nobody Thu Mar 17 10:22:56 2016
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 6D37212DD21 for ; Thu, 17 Mar 2016 10:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 xBCqzHcMiIWy for ; Thu, 17 Mar 2016 10:22:47 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 148D112DD18 for ; Thu, 17 Mar 2016 10:16:43 -0700 (PDT)
X-AuditID: 1209190c-ec3ff7000000022a-dd-56eae67a0c2b
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 6F.41.00554.A76EAE65; Thu, 17 Mar 2016 13:16:42 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u2HHGfoQ001401; Thu, 17 Mar 2016 13:16:42 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2HHGd0h008262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Mar 2016 13:16:40 -0400
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <56EAE401.6090608@pingidentity.com>
Date: Thu, 17 Mar 2016 13:16:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com> <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com> <56EAE401.6090608@pingidentity.com>
To: Hans Zandbelt 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT16169irM4MxxGYs7XSvYLbb+3cts cfLtKzaLBfMb2R1YPO7vXsnusWTJTyaPj09vsXjcPXqRJYAlissmJTUnsyy1SN8ugStj2cnz LAX3SisezIhoYDwT38XIySEhYCIxdc4Dti5GLg4hgTYmiddP/7NCOBsZJbqn9rFDOA+ZJDav uskG0sIsoCex4/ovVhCbF8h+desymC0sYCjxfds3ZhCbTUBVYvqaFiYQm1PAQOJJ/2xGEJsF KN7dtp4RYk6ZxIbX25kgbG2JZQtfM0PMtJLY8XYW2C4hgcnMEjNfOYLYIkC79l5ayARxtqzE 7t+PmCYwCsxCctIsJCfNQjJ2ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJN jKCA5pTk2cF45o3XIUYBDkYlHt4Vp1+GCbEmlhVX5h5ilORgUhLlPfLwVZgQX1J+SmVGYnFG fFFpTmrxIUYJDmYlEV7tp0A53pTEyqrUonyYlDQHi5I4b+H+02FCAumJJanZqakFqUUwWRkO DiUJ3gKQRsGi1PTUirTMnBKENBMHJ8hwHqDhamDDiwsSc4sz0yHypxh1Ofatu7OWSYglLz8v VUqc9/gToCIBkKKM0jy4OaBElPD2sOkrRnGgt4R5VUFG8QCTGNykV0BLmICWHIsDW1KSiJCS amC0rUz7uFyGZfFVU9Nrc61i9mZ335U5r3Xj9zSDE071M9+env1F+ligWpBwkNmzneKPH0oF znAt47ycM+/y28Tfr5Pyiq8Hrjmp+9zyiuzdbYvfhV2Sj6wQ/nrn5qcq73UHXsZLn9+6ZU3m vi2Fs+oXy+uFpNTu/xnJJXGs6vD+0EsfXsVkylrFK7EUZyQaajEXFScCAIrTmlMfAwAA
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:22:55 -0000

But it=92s less likely (or less easy?) to have a malicious combination =
of endpoints in a static configuration. What this all boils down to is =
managing a set of endpoints as a =93thing=94 that represents an AS (and =
some would argue associated RS). You can create that set manually or =
dynamically and fall prey to this attack, but it=92s much more likely in =
the dynamic sense. That=92s why this attack was propagated against OIDC =
first, where dynamic discovery of server information is almost expected =
by client libraries, and clients are designed to be used across domains.

 =97 Justin

> On Mar 17, 2016, at 1:06 PM, Hans Zandbelt =
 wrote:
>=20
> I'm sorry to keep pushing on this but the attack is not opened up by =
discovery, having two fixed ASes is already a threat: multiple ASes in =
general leaves the client exposed. Discovery just increases the attack =
surface.
>=20
> Hans.
>=20
> On 3/17/16 4:16 PM, Phil Hunt wrote:
>> George,
>>=20
>> For the attacks we looked at in Darmstadt, we discussed that in order
>> for the attack to succeed (at least as envisioned), the attacker =
needs
>> to have the client invoke the real authorize endpoint in order for =
the
>> user to be successful in issuing the grant.
>>=20
>> Assuming that it is the case, the attacker can use a proxied token
>> endpoint or a proxied resource endpoint.  A client that doesn=92t =
know
>> what the real endpoint should be could be confused depending on how
>> discovery occurs.
>>=20
>> Keep in mind that the token endpoint and the resource communications
>> happens in the back channel. The user is never going to see the URL =
that
>> has been invoked.  So=85.we need to make sure the set of endpoints =
are
>> bound together or  confirmed.
>>=20
>> Note: This hasn=92t been a big issue to date because current apps =
tend to
>> work with fixed or singleton infrastructure.
>>=20
>> One we expand OAuth out to scenarios where there are multiple service
>> providers with different relationships with OAuth AS=92s, we move =
into
>> this dynamic category that opens the threat.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 17, 2016, at 7:36 AM, George Fletcher >> > wrote:
>>>=20
>>>=20
>>>=20
>>> On 3/16/16 6:37 PM, John Bradley wrote:
>>>> I agree with Phil that the client can=92t trust any abstract =
identifier
>>>> that it might get from a bad RS unless it is were a URI that the
>>>> client or AS could deference to get a list of the concrete URI for
>>>> the RS.
>>> I guess I'm confused on this front as we are asking the client to
>>> "trust" the AS identifier that is being returned by the AS as well =
as
>>> the value the client gets from discovery if it uses that method to
>>> obtain the AS endpoints.
>>>=20
>>> I don't understand why the same philosophy can't be used for =
Resource
>>> Service identifier and endpoints.
>>>>=20
>>>> That seems like a lot of work that clients are unlikely to do.
>>> If I can discover the RS endpoints once and cache them, that doesn't
>>> seem that difficult. This only applies to clients that have some
>>> support for dynamically accepting RS's and their endpoints.
>>>=20
>>> For clients that only support a single AS we are saying they can get
>>> the AS identifier out-of-band and use that. We can easily do the =
same
>>> thing for an RS identifier. They can either get it out-of-band (i.e.
>>> hardcoded) or they can get them dynamically (not likely initially =
but
>>> we shouldn't preclude it).
>>>>=20
>>>> A AS might do it if it wanted to look up the identifier for a given
>>>> resource.
>>>>=20
>>>> Something like do get on resource get back Abstract identifier
>>>> (probably well known location, as recently pointed out in another
>>>> thread you can=92t allow it to point to user content.)
>>> Yes, you could do it this way, though the client still needs to get
>>> those endpoints and if it's doing it dynamically, it will likely use
>>> the same method to discover the endpoints:)
>>>>=20
>>>> The AS gets the file and maps the uri to a abstract identifier for
>>>> audience.
>>>>=20
>>>> I guess that would be one way that you could map AS URI to a =
abstract
>>>> identifier, but I wouldn=92t want to count on clients doing it.
>>> This will work fine, if the client has hardcoded endpoints.
>>>=20
>>> My main concern is that I don't want the AS to have to manage a map =
of
>>> endpoint URLs for each RS it's supporting.
>>>=20
>>> Think of an RS that supports multiple AS's. If the RS adds a new
>>> endpoint, that endpoint can't go live until each AS receives the
>>> endpoint and adds it to it's map. That is a deployment nightmare. =
The
>>> mapping of RS to current endpoints has to dynamic even if it's done =
by
>>> the AS rather than the client.
>>>=20
>>> Wildcard'ing the endpoint URLs or only using domains, I don't think
>>> will work as we've proven that open redirect holes break this
>>> thinking. It needs to be an exact match.
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt >>>> > wrote:
>>>>>=20
>>>>> George,
>>>>>=20
>>>>> Thanks. It would be good to get a draft that sketches out the
>>>>> overall picture of this for BA =97 even if in very rough form =
given
>>>>> the deadline is monday.  Or, maybe just a PPT walkthru.
>>>>>=20
>>>>> Interested to see what comes out.
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com 
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher
>>>>>> <gffletch@aol.com> wrote:
>>>>>>=20
>>>>>> Inline...
>>>>>>=20
>>>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> @independentid
>>>>>>> www.independentid.com
>>>>>>> phil.hunt@oracle.com 
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher
>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>>>> George
>>>>>>>>>=20
>>>>>>>>> Very good question...
>>>>>>>>>=20
>>>>>>>>> I considered that the RS metadata discovery could be fake.
>>>>>>>> Same way that the 'iss' claim must "match" the url used to
>>>>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>>>>> -- I think that should suffice to ensuring the 'rsid' =
identifier
>>>>>>>> can't be spoofed by another site
>>>>>>>=20
>>>>>>> So the attacker makes iss and url match for the resource
>>>>>>> discovery. Yet the AS service provider doesn=92t know where the
>>>>>>> client is using the tokens.  How would the client or the AS =
detect
>>>>>>> that the wrong iss was given?
>>>>>> Because if the attacker makes the rsid and the url match, then =
the
>>>>>> client will submit an rsid that isn't "registered" with the AS =
and
>>>>>> the AS won't issue the token. This assumes the client is not
>>>>>> talking to an evil AS (as there are other mitigations for that =
case).
>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> So the final step in configuration validation is to bind the
>>>>>>>>> relationship between as and rs discovery together to confirm =
the
>>>>>>>>> relationship is valid.
>>>>>>>> And what I'd like to see is the 'rsid' value used to represent
>>>>>>>> the RS rather than some unique endpoint (even if wildcards are
>>>>>>>> allowed)
>>>>>>>=20
>>>>>>> Long term, I think this would be better. Do we have a way to =
issue
>>>>>>> RSID values in the works?
>>>>>> No, but that is what this email thread is contemplating:) Just as
>>>>>> the AS iss value is selfdefined by the AS, the rsid should be
>>>>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS =
metadata
>>>>>> is a mirror of how the AS 'iss' claim is defined for the AS in =
it's
>>>>>> metadata.
>>>>>>>=20
>>>>>>> That said, I would have thought this is more ownerous than
>>>>>>> checking *.example.com matches the given =
URL
>>>>>>> by the client.
>>>>>> My problem with the URL level checking is that a RS may
>>>>>> legitimately have endpoints on multiple domains. An RS may move
>>>>>> endpoints from one domain to another (say when moving from =
version
>>>>>> 1 to version 2 of an API). Using the rsid for audience =
restriction
>>>>>> and as an indirect mechanism for specifying actual endpoints, the
>>>>>> RS has a much looser coupling with the AS.
>>>>>>=20
>>>>>> AS we move into "federated authorization" meaning that an RS
>>>>>> outsources it's API authorization to one or more AS's, this will
>>>>>> become more important.
>>>>>>>>=20
>>>>>>>> Another step that may be required is for the RS to return it's
>>>>>>>> 'rsid' in the realm field of the WWW-Authenticate response
>>>>>>>> header. This allows a client to discover metadata about the RS
>>>>>>>> and it's endpoints. It also allows the client to determine if =
the
>>>>>>>> 'rsid' returned by the RS matches the 'rsid' it is expecting.
>>>>>>>=20
>>>>>>> Agreed. This might work. But should the check be when the client
>>>>>>> asks for the configuration metadata or when the client asks for
>>>>>>> tokens?  I think it only needs to happen at config time.
>>>>>> What I see here is that the desire is to audience protect tokens.
>>>>>> To do that, the audience need to be specified everytime a token =
is
>>>>>> requested. I really don't the AS to have to manage the complex
>>>>>> state of which audiences have previously been issued to
>>>>>> refresh_tokens and then reconstruct the correct audience for a
>>>>>> requested downscoped access_token. It's much simpler, since the
>>>>>> client knows which RS it's going to send the token to, to provide
>>>>>> that when requesting tokens.
>>>>>>=20
>>>>>> The complication comes when exchanging the code for the tokens, =
it
>>>>>> needs to specify all possible audiences (rsid's) it might send =
the
>>>>>> token to based on the requested scopes. There will be a fair =
amount
>>>>>> of complex logic at the AS to ensure the correct behavior. I do
>>>>>> worry about this complexity.
>>>>>>>>>=20
>>>>>>>>> We are of course assuming that a hacker needs to use the real =
AS
>>>>>>>>> authorize endpoint to succeed in obtaining an access token(it
>>>>>>>>> can't be mitm'd). Once the grant is obtained by the client, =
the
>>>>>>>>> threat comes when the client uses the grant at a mitm'd token
>>>>>>>>> endpoint OR an access token at a mitm'd resource endpoint.
>>>>>>>>>=20
>>>>>>>>> So the AS and its config set becomes the trust anchor. Binding
>>>>>>>>> allows us to extend trust to the RS discovery giving some
>>>>>>>>> assurance that a client has a correct set of endpoints =
including
>>>>>>>>> resource.
>>>>>>>> Are you recommending that the AS metadata provide a list of the
>>>>>>>> 'rsid' supported by the AS?
>>>>>>> No.  I think that is a bad idea.  Better to use an identity =
oracle
>>>>>>> function and say, give me the config for rsid=3Dxyz
>>>>>> Good :)
>>>>>>>=20
>>>>>>> That also allows a common AS discovery endpoint to actually do
>>>>>>> discovery for multiple AS systems.  E.g. to configure a client =
to
>>>>>>> a specific AS service designated by the customer paying for the
>>>>>>> resource service.
>>>>>>>=20
>>>>>>> IOW. by providing a resource query, the meta-data config =
discovery
>>>>>>> actually looks more like discovery.  :-)
>>>>>>>>>=20
>>>>>>>>> John's solution requires translating aud to res url and =
changes
>>>>>>>>> to core oauth. He seems to imply there is a need for ongoing
>>>>>>>>> validation of resource. I'm not yet convinced that is really
>>>>>>>>> needed.  Maybe it is needed because the client could be
>>>>>>>>> convinced to follow a link embedded in a resource that is
>>>>>>>>> somehow not part of the defined audience?
>>>>>>>>>=20
>>>>>>>>> Thanks
>>>>>>>>>=20
>>>>>>>>> Phil
>>>>>>>>>=20
>>>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher  =
wrote:
>>>>>>>>>=20
>>>>>>>>>> So, in thinking about all this AS restricting tokens to RS =
and
>>>>>>>>>> "discovery" of RS endpoints, etc. I wondered why we don't =
just
>>>>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>>>>=20
>>>>>>>>>> For an AS we require an 'iss' claim to use as an identifier =
of
>>>>>>>>>> the AS. We could do the same with RS metadata retrieving the
>>>>>>>>>> metadata from a .well-known location and including a claim of
>>>>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>>>>=20
>>>>>>>>>> This 'rsid' identifier could then be used for registration =
with
>>>>>>>>>> the AS and presentation by the client when requesting tokens.
>>>>>>>>>>=20
>>>>>>>>>> This provides a separation between an identifier for a =
resource
>>>>>>>>>> and the specific endpoints the token will be sent to. A =
client
>>>>>>>>>> could "discover" the necessary endpoint on a periodic basis =
and
>>>>>>>>>> use a single identifier with the AS for any of the endpoints =
or
>>>>>>>>>> scopes supported by the RS. If desired the RS could expose =
the
>>>>>>>>>> supported scopes in the RS metadata file.
>>>>>>>>>>=20
>>>>>>>>>> Thoughts?
>>>>>>>>>>=20
>>>>>>>>>> Thanks,
>>>>>>>>>> George
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> =
https://www.ietf.org/mailman/=
listinfo/oauth
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>=20
>>> --
>>> Chief Architect
>>> Identity Services Engineering     Work:george.fletcher@teamaol.com
>>> AOL Inc.                          AIM:  gffletch
>>> Mobile: +1-703-462-3494           =
Twitter:http://twitter.com/gffletch
>>> Office: +1-703-265-2544           =
Photos:http://georgefletcher.photography
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> --=20
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com | Ping Identity
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Mar 17 10:23:56 2016
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 C321B12D9F6 for ; Thu, 17 Mar 2016 10:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level: 
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, 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=mx.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 BOlRdpswz3Hk for ; Thu, 17 Mar 2016 10:23:52 -0700 (PDT)
Received: from omr-m015e.mx.aol.com (omr-m015e.mx.aol.com [204.29.186.15]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5E212DC47 for ; Thu, 17 Mar 2016 10:17:47 -0700 (PDT)
Received: from mtaout-aan01.mx.aol.com (mtaout-aan01.mx.aol.com [172.27.19.77]) by omr-m015e.mx.aol.com (Outbound Mail Relay) with ESMTP id 8523F380009C; Thu, 17 Mar 2016 13:17:46 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aan01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 043233800008C; Thu, 17 Mar 2016 13:17:46 -0400 (EDT)
To: Phil Hunt , John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com> <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <56EAC287.30601@aol.com> <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com> <448DED6D-9DA6-4DA4-A107-A0E56F5060EF@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAE6B8.7050702@aol.com>
Date: Thu, 17 Mar 2016 13:17:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <448DED6D-9DA6-4DA4-A107-A0E56F5060EF@oracle.com>
Content-Type: multipart/alternative; boundary="------------030603050500070404030101"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458235066; bh=OtJXgeNhhY1wAMNcrN6+KdIbDZFBtXfz02jbcgNzrQA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=8a4MPtiO7tXGBRkpojetvShrIaQxKnf5vrgy51aJNhkdORj2BUMiiPkRUwkf7QQpe Dl44XxcInJUTLWfdy/s4ZX3yxxYQajoaOrZCfSgIL+nyGTrPHGi49eWtA8tc+51+TT 8r/HHa5MoJgCBTkiMD0wimvicIFBSoBaNMQT/CYg=
x-aol-sid: 3039ac1b134d56eae6ba068e
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:23:55 -0000

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

 From my perspective we are not trying to solve a mix-up case or any 
other attack. We are trying to solve for audience restricted tokens in 
OAuth2 without PoP. In working to solve that case, we also want to close 
any possible attacks but that is not the primary goal. I, personally, 
don't want a bunch of one-off solutions to identified attacks if we can 
design an cohesive solution that provides value and mitigates known attacks.

Thanks,
George

On 3/17/16 12:27 PM, Phil Hunt wrote:
>
> I think in the mis-configuration case, it is different form the 
> redirect issues.
>
> What we are concerned about is an attackers ability to convince the 
> client to set up a connection via an attackers proxy which can even 
> have a valid TLS enabled.  The client won’t know it has done something 
> wrong. In fact it will confirm it has correctly connected to the 
> attackers proxy.
>
> I don’t believe we have to have exact-match to work here.  We need 
> preferable an exact host match.
>
> I agree there can be a redirect issue pop up once we allow domain 
> matching.  What we could ask the client to do is reconfirm discovery 
> when it receives a redirect from a resource.  I’m not a fan of this 
> because it depends on the client doing something that seems optional 
> (even when it isn’t).  BUT….this might be the out for SP’s like 
> George’s case where they don’t know the exact URL’s clients will be using.
>
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Mar 17, 2016, at 8:48 AM, John Bradley > > wrote:
>>
>> The problem is similar to the one with redirect_uri,  if you allow 
>> user hosted content on the domain they will be able to get the token 
>> if it is sent as a query parameter, and might be able to if it is 
>> sent as a header.
>>
>> Unfortunately many OAuth clients are badly behaved and make use of 
>> the query parameter not considering the security issues.
>>
>> Anything other than the AS or the client doing an exact URI match is 
>> going to leave some hole.
>>
>> This is why we are working on POP that is the correct way to solve 
>> this for AS.
>>
>> I think anything other than the client giving the AS the whole URI 
>> and the AS including that as a audience/destination and letting the 
>> RS figure out if it is correct is largely hopeless, as it will be to 
>> fragile or the client won’t do it.
>>
>> In the case of Phil’s proposal the discovery happens once at client 
>> setup so the AS has no idea if the client checked  before issuing the 
>> token.
>>
>> I honestly think there are two viable options:
>> 1 PoP tokens
>> 2 Including the destination URI / RS URI (pick name) in the token in 
>> full and letting the RS decide if it has been man in the middled.
>>
>> Everything else will be an endless game of wack-a-mole that increases 
>> complexity but gets little real security.
>>
>> John B.
>>
>>
>>> On Mar 17, 2016, at 11:43 AM, George Fletcher >> > wrote:
>>>
>>> If one of the APIs has an open-redirect problem, won't that cause 
>>> the token to leak to the attacker? That's why we went to exact match 
>>> in OpenID Connect. Does it not apply in this case?
>>>
>>> Thanks,
>>> George
>>>
>>> On 3/17/16 2:42 AM, Nat Sakimura wrote:
>>>> IMHO, list of URIs that represent the partial paths under the same 
>>>> authority would not be too onerous.
>>>> e.g., if you have
>>>> https://example.com/apis/v1/userinfo
>>>> https://example.com/apis/v2/userinfo
>>>> https://example.org/some/api/endpoint
>>>> etc., then the AS may provide
>>>> https://example.com/apis/
>>>> https://example.org/
>>>> or something like that in the audiences.
>>>> A completely new domain should not be trusted blindly.
>>>> The resource should at least make sure to provide the domain as 
>>>> being under the same authority.
>>>> Bearer Token is a Password. It should not be shared among different 
>>>> authorities.
>>>> Best,
>>>> Nat
>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*George 
>>>> Fletcher
>>>> *Sent:*Wednesday, March 16, 2016 3:15 AM
>>>> *To:*John Bradley; Brian 
>>>> Campbell
>>>> *Cc:*
>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for 
>>>> draft-hunt-oauth-bound-config-00.txt
>>>>
>>>> (..snip..)
>>>>
>>>> I'm not sure passing the full endpoint to the AS will help with my 
>>>> concerns... The AS could potentially do a webfinger on the resource 
>>>> URI and determine if it's an RS that it supports... though that 
>>>> requires all RS's to support webfinger. What I really want to avoid 
>>>> is the AS having this list of URIs to RS that is almost assuredly 
>>>> to get out of sync.
>>>>
>>>> (..snip..)
>>>>
>>>> --
>>>> PLEASE READ :This e-mail is confidential and intended for the
>>>> named recipient only. If you are not an intended recipient,
>>>> please notify the sender  and delete this e-mail.
>>>
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth


--------------030603050500070404030101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    From my perspective we are
      not trying to solve a mix-up case or any other attack. We are
      trying to solve for audience restricted tokens in OAuth2 without
      PoP. In working to solve that case, we also want to close any
      possible attacks but that is not the primary goal. I, personally,
      don't want a bunch of one-off solutions to identified attacks if
      we can design an cohesive solution that provides value and
      mitigates known attacks.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/17/16 12:27 PM, Phil Hunt wrote:
    
    
    
    
    
      
      

    
      
    
      I think in the mis-configuration case, it is different form the
      redirect issues.
      

    
      
    
      
    What we are concerned about is an attackers ability
        to convince the client to set up a connection via an attackers
        proxy which can even have a valid TLS enabled.  The client won’t
        know it has done something wrong. In fact it will confirm it has
        correctly connected to the attackers proxy.
    
      

    
      
    
      
    I don’t believe we have to have exact-match to work
        here.  We need preferable an exact host match. 
    
      

    
      
    
      
    I agree there can be a redirect issue pop up once we
        allow domain matching.  What we could ask the client to do is
        reconfirm discovery when it receives a redirect from a resource.
         I’m not a fan of this because it depends on the client doing
        something that seems optional (even when it isn’t).  BUT….this
        might be the out for SP’s like George’s case where they don’t
        know the exact URL’s clients will be using.
    
      

    
      
    
      

    
        
        
    
        
    
          
    
            
    On Mar 17, 2016, at 8:48 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
    
            
    
            
    
              
              
    The
                problem is similar to the one with redirect_uri,  if you
                allow user hosted content on the domain they will be
                able to get the token if it is sent as a query
                parameter, and might be able to if it is sent as a
                header.  
                

    
                
    
                
    Unfortunately many OAuth clients are badly
                  behaved and make use of the query parameter not
                  considering the security issues.
    
                

    
                
    
                
    Anything other than the AS or the client
                  doing an exact URI match is going to leave some hole.
    
                

    
                
    
                
    This is why we are working on POP that is
                  the correct way to solve this for AS.
    
                

    
                
    
                
    I think anything other than the client
                  giving the AS the whole URI and the AS including that
                  as a audience/destination and letting the RS figure
                  out if it is correct is largely hopeless, as it will
                  be to fragile or the client won’t do it.  
    
                

    
                
    
                
    In the case of Phil’s proposal the
                  discovery happens once at client setup so the AS has
                  no idea if the client checked  before issuing the
                  token.
    
                

    
                
    
                
    I honestly think there are two viable
                  options:
    
                
    1 PoP tokens
    
                
    2 Including the destination URI / RS URI
                  (pick name) in the token in full and letting the RS
                  decide if it has been man in the middled.
    
                

    
                
    
                
    Everything else will be an endless game of
                  wack-a-mole that increases complexity but gets little
                  real security.
    
                

    
                
    
                
    John B.
    
                

    
                
    
                

    
                  
    
                    
    
                      
    On Mar 17, 2016, at 11:43 AM, George
                        Fletcher <gffletch@aol.com>
                        wrote:
    
                      
    
                      
    If
                          one of the APIs has an open-redirect problem,
                          won't that cause the token to leak to the
                          attacker? That's why we went to exact match in
                          OpenID Connect. Does it not apply in this
                          case?
    
                          
    
                          Thanks,
    
                          George
    
                        
    
                        
    On
                          3/17/16 2:42 AM, Nat Sakimura wrote:
    
                        
    
                        
    
                          
    
                            
                            
     
    
                            
    e.g.,
                                if you have 
    
                            
     
    
                            
                            
                            
                            
     
    
                            
    etc.,
                                then the AS may provide 
    
                            
     
    
                            
                            
                            
     
    
                            
    or
                                something like that in the audiences. 
    
                            
     
    
                            
    A
                                completely new domain should not be
                                trusted blindly. 
    
                            
    The
                                resource should at least make sure to
                                provide the domain as being under the
                                same authority. 
    
                            
     
    
                            
    Bearer
                                Token is a Password. It should not be
                                shared among different authorities. 
    
                            
     
    
                            
    Best, 
    
                            
     
    
                            
    Nat
    
                            
     
    
                            
    
                              
    
                                
    From: OAuth
                                    [mailto:oauth-bounces@ietf.org] On Behalf Of George
                                    Fletcher
    
                                    Sent: Wednesday,
                                    March 16, 2016 3:15 AM
    
                                    To: John
                                    Bradley <ve7jtb@ve7jtb.com>;
                                    Brian Campbell <bcampbell@pingidentity.com>
    
                                    Cc: <oauth@ietf.org> <oauth@ietf.org>
    
                                    Subject: Re:
                                    [OAUTH-WG] New Version Notification
                                    for
                                    draft-hunt-oauth-bound-config-00.txt
    
                              
    
                            
    
                            
     
    
                            
    (..snip..) 
    
                            
    I'm not sure passing the
                                full endpoint to the AS will help with
                                my concerns... The AS could potentially
                                do a webfinger on the resource URI and
                                determine if it's an RS that it
                                supports... though that requires all
                                RS's to support webfinger. What I really
                                want to avoid is the AS having this list
                                of URIs to RS that is almost assuredly
                                to get out of sync.
    
                                
    
                              
    
                            
    (..snip..)
    
                            
    --
    
                            
    PLEASE READ :This
                                e-mail is confidential and intended for
                                the
    
                            
    named recipient
                                only. If you are not an intended
                                recipient,
    
                            
    please notify the
                                sender  and delete this e-mail.
    
                            
     
    
                          
    
                        
    
                        
    
                        
    
                      
    
                    
    
                  
    
                  
    
                
    
              
    
              _______________________________________________
    
              OAuth mailing list
    
              OAuth@ietf.org
    
              https://www.ietf.org/mailman/listinfo/oauth
    
            
    
          
    
        
    
      
    
    
    
    
    
  


--------------030603050500070404030101--


From nobody Thu Mar 17 10:29:04 2016
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 E5CE612D666 for ; Thu, 17 Mar 2016 10:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level: 
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, 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=mx.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 ww8ApngPYxOa for ; Thu, 17 Mar 2016 10:29:00 -0700 (PDT)
Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD9F12DDB0 for ; Thu, 17 Mar 2016 10:21:25 -0700 (PDT)
Received: from mtaout-mba01.mx.aol.com (mtaout-mba01.mx.aol.com [172.26.133.109]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id 2B5A138002ED; Thu, 17 Mar 2016 13:21:23 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mba01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2A846380000A8; Thu, 17 Mar 2016 13:21:22 -0400 (EDT)
To: Phil Hunt , Nat Sakimura 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAE791.5020906@aol.com>
Date: Thu, 17 Mar 2016 13:21:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>
Content-Type: multipart/alternative; boundary="------------070607020501020000020506"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458235283; bh=bCBCCYh2dGkpBaMtuotiVmwAIQ+HF8SV0j9wN4nJ0Ls=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=MVqnGWopGPBOm/pesvGQcq1wOEoLLRzoGa1a3zDdwrRJJR81PQ/9xt0O9WXNOYxpN FJ4h1mnMc1qtBFpVaM1QbRD4OJhVqat9S6ui68Y1M8SSx4FLPLF2l9XJhRDop9M1Kr RzhsNSXkr6HuFQ+zgO5AuRfWBjYbkn3O0DmmB+X4=
x-aol-sid: 3039ac1a856d56eae792326d
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:29:03 -0000

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

I'm not personally convinced that it's possible to boil it down to 
"domain checking". That said, we probably should start a new thread with 
use cases:)

On 3/17/16 12:34 PM, Phil Hunt wrote:
> +1 for Nat's last few emails (avoiding generating too much traffic :-).
>
> Re: below, this is where I was thinking of masking/filter in bound 
> config.  The main thing that needs to be checked at
> configuration time is whether the client has a valid set of server 
> host names to prevent a malicious proxy.
>
> So all the examples you mention below do boil down to 
> https://example.org or https://example.com
>
> It’s not that the AS needs to return them. It simply needs to match 
> them. If one of them matches, then the oauth config can be returned.
>
> I do agree re-directs (of the ESPN scenario) can become an issue if a 
> discovery system matches on *.example.com .  It 
> presumes there are no open redirect servers in the example.com 
>  domain.  As I mention in another email, we should 
> discuss what happens when any oauth connection is redirected.  Should 
> the client re-validate the configuration?
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Mar 16, 2016, at 11:42 PM, Nat Sakimura > > wrote:
>>
>> IMHO, list of URIs that represent the partial paths under the same 
>> authority would not be too onerous.
>> e.g., if you have
>> https://example.com/apis/v1/userinfo
>> https://example.com/apis/v2/userinfo
>> https://example.org/some/api/endpoint
>> etc., then the AS may provide
>> https://example.com/apis/
>> https://example.org/
>> or something like that in the audiences.
>> A completely new domain should not be trusted blindly.
>> The resource should at least make sure to provide the domain as being 
>> under the same authority.
>> Bearer Token is a Password. It should not be shared among different 
>> authorities.
>> Best,
>> Nat
>> *From:*OAuth [mailto:oauth-bounces@ietf.org]*On Behalf Of*George Fletcher
>> *Sent:*Wednesday, March 16, 2016 3:15 AM
>> *To:*John Bradley >; 
>> Brian Campbell > >
>> *Cc:*> > >
>> *Subject:*Re: [OAUTH-WG] New Version Notification for 
>> draft-hunt-oauth-bound-config-00.txt
>>
>> (..snip..)
>>
>> I'm not sure passing the full endpoint to the AS will help with my 
>> concerns... The AS could potentially do a webfinger on the resource 
>> URI and determine if it's an RS that it supports... though that 
>> requires all RS's to support webfinger. What I really want to avoid 
>> is the AS having this list of URIs to RS that is almost assuredly to 
>> get out of sync.
>>
>> (..snip..)
>>
>> --
>> PLEASE READ :This e-mail is confidential and intended for the
>> named recipient only. If you are not an intended recipient,
>> please notify the sender  and delete this e-mail.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth


--------------070607020501020000020506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I'm not personally convinced
      that it's possible to boil it down to "domain checking". That
      said, we probably should start a new thread with use cases:)
    
    
    
    
    On 3/17/16 12:34 PM, Phil Hunt wrote:
    
    
    
    
    
      
      +1 for Nat's last few emails (avoiding generating too much traffic
      :-).
      

    
      
    
      
    Re: below, this is where I was thinking of
        masking/filter in bound config.  The main thing that needs to be
        checked at 
    
      
    configuration time is whether the client has a valid
        set of server host names to prevent a malicious proxy.
    
      

    
      
    
      
    So all the examples you mention below do boil down
        to https://example.org or https://example.com
    
      

    
      
    
      
    It’s not that the AS needs to return them. It simply
        needs to match them. If one of them matches, then the oauth
        config can be returned.
    
      

    
      
    
      
    I do agree re-directs (of the ESPN scenario) can
        become an issue if a discovery system matches on *.example.com.
         It presumes there are no open redirect servers in the example.com
        domain.  As I mention in another email, we should discuss what
        happens when any oauth connection is redirected.  Should the
        client re-validate the configuration?
    
      

    
        
        
    
        
    
          
    
            
    On Mar 16, 2016, at 11:42 PM, Nat Sakimura
              <n-sakimura@nri.co.jp>
              wrote:
    
            
    
            
    
              
    
                
                
     
    
                
    e.g., if you have 
    
                
     
    
                
                
                
                
     
    
                
    etc., then the AS may provide 
    
                
     
    
                
                
                
     
    
                
    or something like that in the
                    audiences. 
    
                
     
    
                
    A completely new domain should not be
                    trusted blindly. 
    
                
    The resource should at least make sure
                    to provide the domain as being under the same
                    authority. 
    
                
     
    
                
    Bearer Token is a Password. It should
                    not be shared among different authorities. 
    
                
     
    
                
    Best, 
    
                
     
    
                
    Nat
    
                
     
    
                
    
                  
    
                    
    From: OAuth
                        [mailto:oauth-bounces@ietf.org] On Behalf Of George
                        Fletcher
    
                        Sent: Wednesday,
                        March 16, 2016 3:15 AM
    
                        To: John
                        Bradley <ve7jtb@ve7jtb.com>;
                        Brian Campbell <bcampbell@pingidentity.com>
    
                        Cc: <oauth@ietf.org>
                        <oauth@ietf.org>
    
                        Subject: Re:
                        [OAUTH-WG] New Version Notification for
                        draft-hunt-oauth-bound-config-00.txt
    
                  
    
                
    
                
     
    
                
    (..snip..) 
    
                
    I'm not sure passing the full endpoint
                    to the AS will help with my concerns... The AS could
                    potentially do a webfinger on the resource URI and
                    determine if it's an RS that it supports... though
                    that requires all RS's to support webfinger. What I
                    really want to avoid is the AS having this list of
                    URIs to RS that is almost assuredly to get out of
                    sync.
    
                    
    
                  
    
                
    (..snip..)
    
                
    --
    
                
    PLEASE
                    READ :This e-mail is confidential and intended for
                    the
    
                
    named
                    recipient only. If you are not an intended
                    recipient,
    
                
    please
                    notify the sender  and delete this e-mail.
    
                
     
    
              
    
              _______________________________________________
    
              OAuth mailing list
    
              OAuth@ietf.org
    
              https://www.ietf.org/mailman/listinfo/oauth
    
            
    
          
    
        
    
      
    
    
    
    
    
  


--------------070607020501020000020506--


From nobody Thu Mar 17 10:34:33 2016
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 1256112DD0F for ; Thu, 17 Mar 2016 10:34:25 -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=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 i8dCLjZXsylc for ; Thu, 17 Mar 2016 10:34:21 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 4ADE312DD48 for ; Thu, 17 Mar 2016 10:25:36 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id l68so3736598wml.1 for ; Thu, 17 Mar 2016 10:25:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QmKWkw5a1ZDBBQWdAH95UpD/93bXGFwwgihlRdQVNVA=; b=QKZk9DFujq2iOZ694lYaeP8oiA1N648Ee1ai2Iy3mlV4giwDRfy9YrjxJb3EZ812fD ikwRgPxeRzkI2I95ErhLXHBy4papxNT2wL/72NrtMLXZdT2Mo/bZf5h+PateCwiDkbOY A7nL98lqdxmEfZQJZy2Hx01E5IPL2zjMI9HTw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QmKWkw5a1ZDBBQWdAH95UpD/93bXGFwwgihlRdQVNVA=; b=jM11OIVvPHpl6CUNRRY2JIisZnxk65PY8gk6CYoXqu1wSwojLmeZmE/C0orb1CkVXP m5RJuA9EtIBvBUfzNkPS6bZyvYYIGww5AW8hqFghtAYWf69i1arK7QKyF8/avMBaAeAY dd328+pY+HL13UR/q+lD09Am21VLV8OMBJCWWd3JnDg5z/N2Y3YHSIzt9wDA3qihRC4z ASSHsnSlW7jnGSNxbOIc5vbfI4hSFFE1mIMCeezn4GjFGWHsfZ4lyIpD1mnX0HB57nSg MtMZ1qCoOxhe/iJ9sEEU8XfxaGBGu6lZBt/oWyvSQAZNPnmORbwLJHJnJnx9Yb12Vvph vZmw==
X-Gm-Message-State: AD7BkJIuU+ueoANPijmdmVo6YnigmSkGv9phEXydUoPLHexlQt2+NCvXG4ta61Dexw5/bnjz
X-Received: by 10.28.23.75 with SMTP id 72mr38462181wmx.50.1458235534727; Thu, 17 Mar 2016 10:25:34 -0700 (PDT)
Received: from [192.168.12.137] ([81.144.134.66]) by smtp.gmail.com with ESMTPSA id v2sm9069335wmd.24.2016.03.17.10.25.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 10:25:33 -0700 (PDT)
To: Justin Richer 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com> <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com> <56EAE401.6090608@pingidentity.com> 
From: Hans Zandbelt 
Message-ID: <56EAE880.9020307@pingidentity.com>
Date: Thu, 17 Mar 2016 17:25:20 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:34:25 -0000

a good AS (at first) may become compromised and attack another AS; 
whilst I agree it is less likely and less easy in static configs (hence 
my point about the dynamic scenario) the root cause is not related to 
configuration: it is a runtime attack (well at least one of the 
permutations is) on perfectly valid configurations

Hans.

On 3/17/16 5:16 PM, Justin Richer wrote:
> But it’s less likely (or less easy?) to have a malicious combination of endpoints in a static configuration. What this all boils down to is managing a set of endpoints as a “thing” that represents an AS (and some would argue associated RS). You can create that set manually or dynamically and fall prey to this attack, but it’s much more likely in the dynamic sense. That’s why this attack was propagated against OIDC first, where dynamic discovery of server information is almost expected by client libraries, and clients are designed to be used across domains.
>
>   — Justin
>
>> On Mar 17, 2016, at 1:06 PM, Hans Zandbelt  wrote:
>>
>> I'm sorry to keep pushing on this but the attack is not opened up by discovery, having two fixed ASes is already a threat: multiple ASes in general leaves the client exposed. Discovery just increases the attack surface.
>>
>> Hans.
>>
>> On 3/17/16 4:16 PM, Phil Hunt wrote:
>>> George,
>>>
>>> For the attacks we looked at in Darmstadt, we discussed that in order
>>> for the attack to succeed (at least as envisioned), the attacker needs
>>> to have the client invoke the real authorize endpoint in order for the
>>> user to be successful in issuing the grant.
>>>
>>> Assuming that it is the case, the attacker can use a proxied token
>>> endpoint or a proxied resource endpoint.  A client that doesn’t know
>>> what the real endpoint should be could be confused depending on how
>>> discovery occurs.
>>>
>>> Keep in mind that the token endpoint and the resource communications
>>> happens in the back channel. The user is never going to see the URL that
>>> has been invoked.  So….we need to make sure the set of endpoints are
>>> bound together or  confirmed.
>>>
>>> Note: This hasn’t been a big issue to date because current apps tend to
>>> work with fixed or singleton infrastructure.
>>>
>>> One we expand OAuth out to scenarios where there are multiple service
>>> providers with different relationships with OAuth AS’s, we move into
>>> this dynamic category that opens the threat.
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com 
>>> phil.hunt@oracle.com 
>>>
>>>
>>>
>>>
>>>
>>>> On Mar 17, 2016, at 7:36 AM, George Fletcher >>> > wrote:
>>>>
>>>>
>>>>
>>>> On 3/16/16 6:37 PM, John Bradley wrote:
>>>>> I agree with Phil that the client can’t trust any abstract identifier
>>>>> that it might get from a bad RS unless it is were a URI that the
>>>>> client or AS could deference to get a list of the concrete URI for
>>>>> the RS.
>>>> I guess I'm confused on this front as we are asking the client to
>>>> "trust" the AS identifier that is being returned by the AS as well as
>>>> the value the client gets from discovery if it uses that method to
>>>> obtain the AS endpoints.
>>>>
>>>> I don't understand why the same philosophy can't be used for Resource
>>>> Service identifier and endpoints.
>>>>>
>>>>> That seems like a lot of work that clients are unlikely to do.
>>>> If I can discover the RS endpoints once and cache them, that doesn't
>>>> seem that difficult. This only applies to clients that have some
>>>> support for dynamically accepting RS's and their endpoints.
>>>>
>>>> For clients that only support a single AS we are saying they can get
>>>> the AS identifier out-of-band and use that. We can easily do the same
>>>> thing for an RS identifier. They can either get it out-of-band (i.e.
>>>> hardcoded) or they can get them dynamically (not likely initially but
>>>> we shouldn't preclude it).
>>>>>
>>>>> A AS might do it if it wanted to look up the identifier for a given
>>>>> resource.
>>>>>
>>>>> Something like do get on resource get back Abstract identifier
>>>>> (probably well known location, as recently pointed out in another
>>>>> thread you can’t allow it to point to user content.)
>>>> Yes, you could do it this way, though the client still needs to get
>>>> those endpoints and if it's doing it dynamically, it will likely use
>>>> the same method to discover the endpoints:)
>>>>>
>>>>> The AS gets the file and maps the uri to a abstract identifier for
>>>>> audience.
>>>>>
>>>>> I guess that would be one way that you could map AS URI to a abstract
>>>>> identifier, but I wouldn’t want to count on clients doing it.
>>>> This will work fine, if the client has hardcoded endpoints.
>>>>
>>>> My main concern is that I don't want the AS to have to manage a map of
>>>> endpoint URLs for each RS it's supporting.
>>>>
>>>> Think of an RS that supports multiple AS's. If the RS adds a new
>>>> endpoint, that endpoint can't go live until each AS receives the
>>>> endpoint and adds it to it's map. That is a deployment nightmare. The
>>>> mapping of RS to current endpoints has to dynamic even if it's done by
>>>> the AS rather than the client.
>>>>
>>>> Wildcard'ing the endpoint URLs or only using domains, I don't think
>>>> will work as we've proven that open redirect holes break this
>>>> thinking. It needs to be an exact match.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt >>>>> > wrote:
>>>>>>
>>>>>> George,
>>>>>>
>>>>>> Thanks. It would be good to get a draft that sketches out the
>>>>>> overall picture of this for BA — even if in very rough form given
>>>>>> the deadline is monday.  Or, maybe just a PPT walkthru.
>>>>>>
>>>>>> Interested to see what comes out.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher
>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>
>>>>>>> Inline...
>>>>>>>
>>>>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher
>>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>>>>> George
>>>>>>>>>>
>>>>>>>>>> Very good question...
>>>>>>>>>>
>>>>>>>>>> I considered that the RS metadata discovery could be fake.
>>>>>>>>> Same way that the 'iss' claim must "match" the url used to
>>>>>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>>>>>> -- I think that should suffice to ensuring the 'rsid' identifier
>>>>>>>>> can't be spoofed by another site
>>>>>>>>
>>>>>>>> So the attacker makes iss and url match for the resource
>>>>>>>> discovery. Yet the AS service provider doesn’t know where the
>>>>>>>> client is using the tokens.  How would the client or the AS detect
>>>>>>>> that the wrong iss was given?
>>>>>>> Because if the attacker makes the rsid and the url match, then the
>>>>>>> client will submit an rsid that isn't "registered" with the AS and
>>>>>>> the AS won't issue the token. This assumes the client is not
>>>>>>> talking to an evil AS (as there are other mitigations for that case).
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So the final step in configuration validation is to bind the
>>>>>>>>>> relationship between as and rs discovery together to confirm the
>>>>>>>>>> relationship is valid.
>>>>>>>>> And what I'd like to see is the 'rsid' value used to represent
>>>>>>>>> the RS rather than some unique endpoint (even if wildcards are
>>>>>>>>> allowed)
>>>>>>>>
>>>>>>>> Long term, I think this would be better. Do we have a way to issue
>>>>>>>> RSID values in the works?
>>>>>>> No, but that is what this email thread is contemplating:) Just as
>>>>>>> the AS iss value is selfdefined by the AS, the rsid should be
>>>>>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
>>>>>>> is a mirror of how the AS 'iss' claim is defined for the AS in it's
>>>>>>> metadata.
>>>>>>>>
>>>>>>>> That said, I would have thought this is more ownerous than
>>>>>>>> checking *.example.com matches the given URL
>>>>>>>> by the client.
>>>>>>> My problem with the URL level checking is that a RS may
>>>>>>> legitimately have endpoints on multiple domains. An RS may move
>>>>>>> endpoints from one domain to another (say when moving from version
>>>>>>> 1 to version 2 of an API). Using the rsid for audience restriction
>>>>>>> and as an indirect mechanism for specifying actual endpoints, the
>>>>>>> RS has a much looser coupling with the AS.
>>>>>>>
>>>>>>> AS we move into "federated authorization" meaning that an RS
>>>>>>> outsources it's API authorization to one or more AS's, this will
>>>>>>> become more important.
>>>>>>>>>
>>>>>>>>> Another step that may be required is for the RS to return it's
>>>>>>>>> 'rsid' in the realm field of the WWW-Authenticate response
>>>>>>>>> header. This allows a client to discover metadata about the RS
>>>>>>>>> and it's endpoints. It also allows the client to determine if the
>>>>>>>>> 'rsid' returned by the RS matches the 'rsid' it is expecting.
>>>>>>>>
>>>>>>>> Agreed. This might work. But should the check be when the client
>>>>>>>> asks for the configuration metadata or when the client asks for
>>>>>>>> tokens?  I think it only needs to happen at config time.
>>>>>>> What I see here is that the desire is to audience protect tokens.
>>>>>>> To do that, the audience need to be specified everytime a token is
>>>>>>> requested. I really don't the AS to have to manage the complex
>>>>>>> state of which audiences have previously been issued to
>>>>>>> refresh_tokens and then reconstruct the correct audience for a
>>>>>>> requested downscoped access_token. It's much simpler, since the
>>>>>>> client knows which RS it's going to send the token to, to provide
>>>>>>> that when requesting tokens.
>>>>>>>
>>>>>>> The complication comes when exchanging the code for the tokens, it
>>>>>>> needs to specify all possible audiences (rsid's) it might send the
>>>>>>> token to based on the requested scopes. There will be a fair amount
>>>>>>> of complex logic at the AS to ensure the correct behavior. I do
>>>>>>> worry about this complexity.
>>>>>>>>>>
>>>>>>>>>> We are of course assuming that a hacker needs to use the real AS
>>>>>>>>>> authorize endpoint to succeed in obtaining an access token(it
>>>>>>>>>> can't be mitm'd). Once the grant is obtained by the client, the
>>>>>>>>>> threat comes when the client uses the grant at a mitm'd token
>>>>>>>>>> endpoint OR an access token at a mitm'd resource endpoint.
>>>>>>>>>>
>>>>>>>>>> So the AS and its config set becomes the trust anchor. Binding
>>>>>>>>>> allows us to extend trust to the RS discovery giving some
>>>>>>>>>> assurance that a client has a correct set of endpoints including
>>>>>>>>>> resource.
>>>>>>>>> Are you recommending that the AS metadata provide a list of the
>>>>>>>>> 'rsid' supported by the AS?
>>>>>>>> No.  I think that is a bad idea.  Better to use an identity oracle
>>>>>>>> function and say, give me the config for rsid=xyz
>>>>>>> Good :)
>>>>>>>>
>>>>>>>> That also allows a common AS discovery endpoint to actually do
>>>>>>>> discovery for multiple AS systems.  E.g. to configure a client to
>>>>>>>> a specific AS service designated by the customer paying for the
>>>>>>>> resource service.
>>>>>>>>
>>>>>>>> IOW. by providing a resource query, the meta-data config discovery
>>>>>>>> actually looks more like discovery.  :-)
>>>>>>>>>>
>>>>>>>>>> John's solution requires translating aud to res url and changes
>>>>>>>>>> to core oauth. He seems to imply there is a need for ongoing
>>>>>>>>>> validation of resource. I'm not yet convinced that is really
>>>>>>>>>> needed.  Maybe it is needed because the client could be
>>>>>>>>>> convinced to follow a link embedded in a resource that is
>>>>>>>>>> somehow not part of the defined audience?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher  wrote:
>>>>>>>>>>
>>>>>>>>>>> So, in thinking about all this AS restricting tokens to RS and
>>>>>>>>>>> "discovery" of RS endpoints, etc. I wondered why we don't just
>>>>>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>>>>>
>>>>>>>>>>> For an AS we require an 'iss' claim to use as an identifier of
>>>>>>>>>>> the AS. We could do the same with RS metadata retrieving the
>>>>>>>>>>> metadata from a .well-known location and including a claim of
>>>>>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>>>>>
>>>>>>>>>>> This 'rsid' identifier could then be used for registration with
>>>>>>>>>>> the AS and presentation by the client when requesting tokens.
>>>>>>>>>>>
>>>>>>>>>>> This provides a separation between an identifier for a resource
>>>>>>>>>>> and the specific endpoints the token will be sent to. A client
>>>>>>>>>>> could "discover" the necessary endpoint on a periodic basis and
>>>>>>>>>>> use a single identifier with the AS for any of the endpoints or
>>>>>>>>>>> scopes supported by the RS. If desired the RS could expose the
>>>>>>>>>>> supported scopes in the RS metadata file.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> George
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>
>>>>
>>>> --
>>>> Chief Architect
>>>> Identity Services Engineering     Work:george.fletcher@teamaol.com
>>>> AOL Inc.                          AIM:  gffletch
>>>> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
>>>> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> --
>> Hans Zandbelt              | Sr. Technical Architect
>> hzandbelt@pingidentity.com | Ping Identity
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Thu Mar 17 10:39:17 2016
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 4265712D9CB for ; Thu, 17 Mar 2016 10:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.81
X-Spam-Level: 
X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mx.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 qGWU70p13vyT for ; Thu, 17 Mar 2016 10:39:11 -0700 (PDT)
Received: from omr-a015e.mx.aol.com (omr-a015e.mx.aol.com [204.29.186.63]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D620012DCB5 for ; Thu, 17 Mar 2016 10:31:43 -0700 (PDT)
Received: from mtaout-aao01.mx.aol.com (mtaout-aao01.mx.aol.com [172.27.21.13]) by omr-a015e.mx.aol.com (Outbound Mail Relay) with ESMTP id 24A3738000BA; Thu, 17 Mar 2016 13:31:43 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aao01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 6293A38000096; Thu, 17 Mar 2016 13:31:42 -0400 (EDT)
To: Hans Zandbelt , Justin Richer 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com> <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com> <56EAE401.6090608@pingidentity.com>  <56EAE880.9020307@pingidentity.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAE9FE.9040707@aol.com>
Date: Thu, 17 Mar 2016 13:31:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <56EAE880.9020307@pingidentity.com>
Content-Type: multipart/alternative; boundary="------------050301060608090506010903"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458235903; bh=CkgOHAQYcEBpz0WfeCEpnEzb0ps//NIkCUDWGLYKZAk=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=wDOx1JiUPmbDGyfnco0e5uVg1O6+D0eiKVssH74HvqSFdy9gRA/3mtzW7XVyfYpW2 sac1hWAfCdmv1ZfZexD0bQzWO/HyJ4b6uLpKgWQ2xSI4DmsUx+0zkp394Qz+wWVOyz ogX5r+1Xp2lqkjlPQFr5/WMTDh1ESn02QqDlngJI=
x-aol-sid: 3039ac1b150d56eae9fe1979
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:39:15 -0000

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

Isn't the solution to that attack defined? I was not including that 
attack in the thinking around audience restricted tokens and AS / RS 
endpoint "discovery". I think that regardless of this current discussion 
the requirement for the AS to return issuer and client_id needs to stay 
as does the binding of state to code.

I looked at the current email thread to be addressing an additional 
problem and that is how to help the client NOT send a token to an evil 
RS. From my understanding this hasn't been addressed. If I missed that 
discussion, feel free to point me to the thread.

Thanks,
George

On 3/17/16 1:25 PM, Hans Zandbelt wrote:
> a good AS (at first) may become compromised and attack another AS; 
> whilst I agree it is less likely and less easy in static configs 
> (hence my point about the dynamic scenario) the root cause is not 
> related to configuration: it is a runtime attack (well at least one of 
> the permutations is) on perfectly valid configurations
>
> Hans.
>
> On 3/17/16 5:16 PM, Justin Richer wrote:
>> But it’s less likely (or less easy?) to have a malicious combination 
>> of endpoints in a static configuration. What this all boils down to 
>> is managing a set of endpoints as a “thing” that represents an AS 
>> (and some would argue associated RS). You can create that set 
>> manually or dynamically and fall prey to this attack, but it’s much 
>> more likely in the dynamic sense. That’s why this attack was 
>> propagated against OIDC first, where dynamic discovery of server 
>> information is almost expected by client libraries, and clients are 
>> designed to be used across domains.
>>
>>   — Justin
>>
>>> On Mar 17, 2016, at 1:06 PM, Hans Zandbelt 
>>>  wrote:
>>>
>>> I'm sorry to keep pushing on this but the attack is not opened up by 
>>> discovery, having two fixed ASes is already a threat: multiple ASes 
>>> in general leaves the client exposed. Discovery just increases the 
>>> attack surface.
>>>
>>> Hans.
>>>
>>> On 3/17/16 4:16 PM, Phil Hunt wrote:
>>>> George,
>>>>
>>>> For the attacks we looked at in Darmstadt, we discussed that in order
>>>> for the attack to succeed (at least as envisioned), the attacker needs
>>>> to have the client invoke the real authorize endpoint in order for the
>>>> user to be successful in issuing the grant.
>>>>
>>>> Assuming that it is the case, the attacker can use a proxied token
>>>> endpoint or a proxied resource endpoint.  A client that doesn’t know
>>>> what the real endpoint should be could be confused depending on how
>>>> discovery occurs.
>>>>
>>>> Keep in mind that the token endpoint and the resource communications
>>>> happens in the back channel. The user is never going to see the URL 
>>>> that
>>>> has been invoked.  So….we need to make sure the set of endpoints are
>>>> bound together or  confirmed.
>>>>
>>>> Note: This hasn’t been a big issue to date because current apps 
>>>> tend to
>>>> work with fixed or singleton infrastructure.
>>>>
>>>> One we expand OAuth out to scenarios where there are multiple service
>>>> providers with different relationships with OAuth AS’s, we move into
>>>> this dynamic category that opens the threat.
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com 
>>>> phil.hunt@oracle.com 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Mar 17, 2016, at 7:36 AM, George Fletcher >>>> > wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 3/16/16 6:37 PM, John Bradley wrote:
>>>>>> I agree with Phil that the client can’t trust any abstract 
>>>>>> identifier
>>>>>> that it might get from a bad RS unless it is were a URI that the
>>>>>> client or AS could deference to get a list of the concrete URI for
>>>>>> the RS.
>>>>> I guess I'm confused on this front as we are asking the client to
>>>>> "trust" the AS identifier that is being returned by the AS as well as
>>>>> the value the client gets from discovery if it uses that method to
>>>>> obtain the AS endpoints.
>>>>>
>>>>> I don't understand why the same philosophy can't be used for Resource
>>>>> Service identifier and endpoints.
>>>>>>
>>>>>> That seems like a lot of work that clients are unlikely to do.
>>>>> If I can discover the RS endpoints once and cache them, that doesn't
>>>>> seem that difficult. This only applies to clients that have some
>>>>> support for dynamically accepting RS's and their endpoints.
>>>>>
>>>>> For clients that only support a single AS we are saying they can get
>>>>> the AS identifier out-of-band and use that. We can easily do the same
>>>>> thing for an RS identifier. They can either get it out-of-band (i.e.
>>>>> hardcoded) or they can get them dynamically (not likely initially but
>>>>> we shouldn't preclude it).
>>>>>>
>>>>>> A AS might do it if it wanted to look up the identifier for a given
>>>>>> resource.
>>>>>>
>>>>>> Something like do get on resource get back Abstract identifier
>>>>>> (probably well known location, as recently pointed out in another
>>>>>> thread you can’t allow it to point to user content.)
>>>>> Yes, you could do it this way, though the client still needs to get
>>>>> those endpoints and if it's doing it dynamically, it will likely use
>>>>> the same method to discover the endpoints:)
>>>>>>
>>>>>> The AS gets the file and maps the uri to a abstract identifier for
>>>>>> audience.
>>>>>>
>>>>>> I guess that would be one way that you could map AS URI to a 
>>>>>> abstract
>>>>>> identifier, but I wouldn’t want to count on clients doing it.
>>>>> This will work fine, if the client has hardcoded endpoints.
>>>>>
>>>>> My main concern is that I don't want the AS to have to manage a 
>>>>> map of
>>>>> endpoint URLs for each RS it's supporting.
>>>>>
>>>>> Think of an RS that supports multiple AS's. If the RS adds a new
>>>>> endpoint, that endpoint can't go live until each AS receives the
>>>>> endpoint and adds it to it's map. That is a deployment nightmare. The
>>>>> mapping of RS to current endpoints has to dynamic even if it's 
>>>>> done by
>>>>> the AS rather than the client.
>>>>>
>>>>> Wildcard'ing the endpoint URLs or only using domains, I don't think
>>>>> will work as we've proven that open redirect holes break this
>>>>> thinking. It needs to be an exact match.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt >>>>>> > wrote:
>>>>>>>
>>>>>>> George,
>>>>>>>
>>>>>>> Thanks. It would be good to get a draft that sketches out the
>>>>>>> overall picture of this for BA — even if in very rough form given
>>>>>>> the deadline is monday.  Or, maybe just a PPT walkthru.
>>>>>>>
>>>>>>> Interested to see what comes out.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com
>>>>>>> phil.hunt@oracle.com 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher
>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>
>>>>>>>> Inline...
>>>>>>>>
>>>>>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher
>>>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>>>>>> George
>>>>>>>>>>>
>>>>>>>>>>> Very good question...
>>>>>>>>>>>
>>>>>>>>>>> I considered that the RS metadata discovery could be fake.
>>>>>>>>>> Same way that the 'iss' claim must "match" the url used to
>>>>>>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>>>>>>> -- I think that should suffice to ensuring the 'rsid' identifier
>>>>>>>>>> can't be spoofed by another site
>>>>>>>>>
>>>>>>>>> So the attacker makes iss and url match for the resource
>>>>>>>>> discovery. Yet the AS service provider doesn’t know where the
>>>>>>>>> client is using the tokens.  How would the client or the AS 
>>>>>>>>> detect
>>>>>>>>> that the wrong iss was given?
>>>>>>>> Because if the attacker makes the rsid and the url match, then the
>>>>>>>> client will submit an rsid that isn't "registered" with the AS and
>>>>>>>> the AS won't issue the token. This assumes the client is not
>>>>>>>> talking to an evil AS (as there are other mitigations for that 
>>>>>>>> case).
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So the final step in configuration validation is to bind the
>>>>>>>>>>> relationship between as and rs discovery together to confirm 
>>>>>>>>>>> the
>>>>>>>>>>> relationship is valid.
>>>>>>>>>> And what I'd like to see is the 'rsid' value used to represent
>>>>>>>>>> the RS rather than some unique endpoint (even if wildcards are
>>>>>>>>>> allowed)
>>>>>>>>>
>>>>>>>>> Long term, I think this would be better. Do we have a way to 
>>>>>>>>> issue
>>>>>>>>> RSID values in the works?
>>>>>>>> No, but that is what this email thread is contemplating:) Just as
>>>>>>>> the AS iss value is selfdefined by the AS, the rsid should be
>>>>>>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
>>>>>>>> is a mirror of how the AS 'iss' claim is defined for the AS in 
>>>>>>>> it's
>>>>>>>> metadata.
>>>>>>>>>
>>>>>>>>> That said, I would have thought this is more ownerous than
>>>>>>>>> checking *.example.com matches the given URL
>>>>>>>>> by the client.
>>>>>>>> My problem with the URL level checking is that a RS may
>>>>>>>> legitimately have endpoints on multiple domains. An RS may move
>>>>>>>> endpoints from one domain to another (say when moving from version
>>>>>>>> 1 to version 2 of an API). Using the rsid for audience restriction
>>>>>>>> and as an indirect mechanism for specifying actual endpoints, the
>>>>>>>> RS has a much looser coupling with the AS.
>>>>>>>>
>>>>>>>> AS we move into "federated authorization" meaning that an RS
>>>>>>>> outsources it's API authorization to one or more AS's, this will
>>>>>>>> become more important.
>>>>>>>>>>
>>>>>>>>>> Another step that may be required is for the RS to return it's
>>>>>>>>>> 'rsid' in the realm field of the WWW-Authenticate response
>>>>>>>>>> header. This allows a client to discover metadata about the RS
>>>>>>>>>> and it's endpoints. It also allows the client to determine if 
>>>>>>>>>> the
>>>>>>>>>> 'rsid' returned by the RS matches the 'rsid' it is expecting.
>>>>>>>>>
>>>>>>>>> Agreed. This might work. But should the check be when the client
>>>>>>>>> asks for the configuration metadata or when the client asks for
>>>>>>>>> tokens?  I think it only needs to happen at config time.
>>>>>>>> What I see here is that the desire is to audience protect tokens.
>>>>>>>> To do that, the audience need to be specified everytime a token is
>>>>>>>> requested. I really don't the AS to have to manage the complex
>>>>>>>> state of which audiences have previously been issued to
>>>>>>>> refresh_tokens and then reconstruct the correct audience for a
>>>>>>>> requested downscoped access_token. It's much simpler, since the
>>>>>>>> client knows which RS it's going to send the token to, to provide
>>>>>>>> that when requesting tokens.
>>>>>>>>
>>>>>>>> The complication comes when exchanging the code for the tokens, it
>>>>>>>> needs to specify all possible audiences (rsid's) it might send the
>>>>>>>> token to based on the requested scopes. There will be a fair 
>>>>>>>> amount
>>>>>>>> of complex logic at the AS to ensure the correct behavior. I do
>>>>>>>> worry about this complexity.
>>>>>>>>>>>
>>>>>>>>>>> We are of course assuming that a hacker needs to use the 
>>>>>>>>>>> real AS
>>>>>>>>>>> authorize endpoint to succeed in obtaining an access token(it
>>>>>>>>>>> can't be mitm'd). Once the grant is obtained by the client, the
>>>>>>>>>>> threat comes when the client uses the grant at a mitm'd token
>>>>>>>>>>> endpoint OR an access token at a mitm'd resource endpoint.
>>>>>>>>>>>
>>>>>>>>>>> So the AS and its config set becomes the trust anchor. Binding
>>>>>>>>>>> allows us to extend trust to the RS discovery giving some
>>>>>>>>>>> assurance that a client has a correct set of endpoints 
>>>>>>>>>>> including
>>>>>>>>>>> resource.
>>>>>>>>>> Are you recommending that the AS metadata provide a list of the
>>>>>>>>>> 'rsid' supported by the AS?
>>>>>>>>> No.  I think that is a bad idea.  Better to use an identity 
>>>>>>>>> oracle
>>>>>>>>> function and say, give me the config for rsid=xyz
>>>>>>>> Good :)
>>>>>>>>>
>>>>>>>>> That also allows a common AS discovery endpoint to actually do
>>>>>>>>> discovery for multiple AS systems.  E.g. to configure a client to
>>>>>>>>> a specific AS service designated by the customer paying for the
>>>>>>>>> resource service.
>>>>>>>>>
>>>>>>>>> IOW. by providing a resource query, the meta-data config 
>>>>>>>>> discovery
>>>>>>>>> actually looks more like discovery.  :-)
>>>>>>>>>>>
>>>>>>>>>>> John's solution requires translating aud to res url and changes
>>>>>>>>>>> to core oauth. He seems to imply there is a need for ongoing
>>>>>>>>>>> validation of resource. I'm not yet convinced that is really
>>>>>>>>>>> needed.  Maybe it is needed because the client could be
>>>>>>>>>>> convinced to follow a link embedded in a resource that is
>>>>>>>>>>> somehow not part of the defined audience?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher 
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> So, in thinking about all this AS restricting tokens to RS and
>>>>>>>>>>>> "discovery" of RS endpoints, etc. I wondered why we don't just
>>>>>>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>>>>>>
>>>>>>>>>>>> For an AS we require an 'iss' claim to use as an identifier of
>>>>>>>>>>>> the AS. We could do the same with RS metadata retrieving the
>>>>>>>>>>>> metadata from a .well-known location and including a claim of
>>>>>>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>>>>>>
>>>>>>>>>>>> This 'rsid' identifier could then be used for registration 
>>>>>>>>>>>> with
>>>>>>>>>>>> the AS and presentation by the client when requesting tokens.
>>>>>>>>>>>>
>>>>>>>>>>>> This provides a separation between an identifier for a 
>>>>>>>>>>>> resource
>>>>>>>>>>>> and the specific endpoints the token will be sent to. A client
>>>>>>>>>>>> could "discover" the necessary endpoint on a periodic basis 
>>>>>>>>>>>> and
>>>>>>>>>>>> use a single identifier with the AS for any of the 
>>>>>>>>>>>> endpoints or
>>>>>>>>>>>> scopes supported by the RS. If desired the RS could expose the
>>>>>>>>>>>> supported scopes in the RS metadata file.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> George
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> -- 
>>> Hans Zandbelt              | Sr. Technical Architect
>>> hzandbelt@pingidentity.com | Ping Identity
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>


--------------050301060608090506010903
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Isn't the solution to that
      attack defined? I was not including that attack in the thinking
      around audience restricted tokens and AS / RS endpoint "discovery".
      I think that regardless of this current discussion the requirement
      for the AS to return issuer and client_id needs to stay as does
      the binding of state to code.
    
      
    
      I looked at the current email thread to be addressing an
      additional problem and that is how to help the client NOT send a
      token to an evil RS. From my understanding this hasn't been
      addressed. If I missed that discussion, feel free to point me to
      the thread.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/17/16 1:25 PM, Hans Zandbelt
      wrote:
    
    
    
    
    a
      good AS (at first) may become compromised and attack another AS;
      whilst I agree it is less likely and less easy in static configs
      (hence my point about the dynamic scenario) the root cause is not
      related to configuration: it is a runtime attack (well at least
      one of the permutations is) on perfectly valid configurations
      
    
      
    
      Hans.
      
    
      
    
      On 3/17/16 5:16 PM, Justin Richer wrote:
      
    
      
    But it’s less likely (or less easy?) to
        have a malicious combination of endpoints in a static
        configuration. What this all boils down to is managing a set of
        endpoints as a “thing” that represents an AS (and some would
        argue associated RS). You can create that set manually or
        dynamically and fall prey to this attack, but it’s much more
        likely in the dynamic sense. That’s why this attack was
        propagated against OIDC first, where dynamic discovery of server
        information is almost expected by client libraries, and clients
        are designed to be used across domains.
        
    
        
    
          — Justin
        
    
        
    
        
    On Mar 17, 2016, at 1:06 PM, Hans
          Zandbelt <hzandbelt@pingidentity.com> wrote:
          
    
          
    
          I'm sorry to keep pushing on this but the attack is not opened
          up by discovery, having two fixed ASes is already a threat:
          multiple ASes in general leaves the client exposed. Discovery
          just increases the attack surface.
          
    
          
    
          Hans.
          
    
          
    
          On 3/17/16 4:16 PM, Phil Hunt wrote:
          
    
          
    George,
            
    
            
    
            For the attacks we looked at in Darmstadt, we discussed that
            in order
            
    
            for the attack to succeed (at least as envisioned), the
            attacker needs
            
    
            to have the client invoke the real authorize endpoint in
            order for the
            
    
            user to be successful in issuing the grant.
            
    
            
    
            Assuming that it is the case, the attacker can use a proxied
            token
            
    
            endpoint or a proxied resource endpoint.  A client that
            doesn’t know
            
    
            what the real endpoint should be could be confused depending
            on how
            
    
            discovery occurs.
            
    
            
    
            Keep in mind that the token endpoint and the resource
            communications
            
    
            happens in the back channel. The user is never going to see
            the URL that
            
    
            has been invoked.  So….we need to make sure the set of
            endpoints are
            
    
            bound together or  confirmed.
            
    
            
    
            Note: This hasn’t been a big issue to date because current
            apps tend to
            
    
            work with fixed or singleton infrastructure.
            
    
            
    
            One we expand OAuth out to scenarios where there are
            multiple service
            
    
            providers with different relationships with OAuth AS’s, we
            move into
            
    
            this dynamic category that opens the threat.
            
    
            
    
            Phil
            
    
            
    
            @independentid
            
    
            www.independentid.com <http://www.independentid.com>
            
    
            phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
            
    
            
    
            
    
            
    
            
    
            
    
            
    On Mar 17, 2016, at 7:36 AM, George
              Fletcher <gffletch@aol.com
              
    
              <mailto:gffletch@aol.com>> wrote:
              
    
              
    
              
    
              
    
              On 3/16/16 6:37 PM, John Bradley wrote:
              
    
              
    I agree with Phil that the client
                can’t trust any abstract identifier
                
    
                that it might get from a bad RS unless it is were a URI
                that the
                
    
                client or AS could deference to get a list of the
                concrete URI for
                
    
                the RS.
                
    
              
    
              I guess I'm confused on this front as we are asking the
              client to
              
    
              "trust" the AS identifier that is being returned by the AS
              as well as
              
    
              the value the client gets from discovery if it uses that
              method to
              
    
              obtain the AS endpoints.
              
    
              
    
              I don't understand why the same philosophy can't be used
              for Resource
              
    
              Service identifier and endpoints.
              
    
              
    
                
    
                That seems like a lot of work that clients are unlikely
                to do.
                
    
              
    
              If I can discover the RS endpoints once and cache them,
              that doesn't
              
    
              seem that difficult. This only applies to clients that
              have some
              
    
              support for dynamically accepting RS's and their
              endpoints.
              
    
              
    
              For clients that only support a single AS we are saying
              they can get
              
    
              the AS identifier out-of-band and use that. We can easily
              do the same
              
    
              thing for an RS identifier. They can either get it
              out-of-band (i.e.
              
    
              hardcoded) or they can get them dynamically (not likely
              initially but
              
    
              we shouldn't preclude it).
              
    
              
    
                
    
                A AS might do it if it wanted to look up the identifier
                for a given
                
    
                resource.
                
    
                
    
                Something like do get on resource get back Abstract
                identifier
                
    
                (probably well known location, as recently pointed out
                in another
                
    
                thread you can’t allow it to point to user content.)
                
    
              
    
              Yes, you could do it this way, though the client still
              needs to get
              
    
              those endpoints and if it's doing it dynamically, it will
              likely use
              
    
              the same method to discover the endpoints:)
              
    
              
    
                
    
                The AS gets the file and maps the uri to a abstract
                identifier for
                
    
                audience.
                
    
                
    
                I guess that would be one way that you could map AS URI
                to a abstract
                
    
                identifier, but I wouldn’t want to count on clients
                doing it.
                
    
              
    
              This will work fine, if the client has hardcoded
              endpoints.
              
    
              
    
              My main concern is that I don't want the AS to have to
              manage a map of
              
    
              endpoint URLs for each RS it's supporting.
              
    
              
    
              Think of an RS that supports multiple AS's. If the RS adds
              a new
              
    
              endpoint, that endpoint can't go live until each AS
              receives the
              
    
              endpoint and adds it to it's map. That is a deployment
              nightmare. The
              
    
              mapping of RS to current endpoints has to dynamic even if
              it's done by
              
    
              the AS rather than the client.
              
    
              
    
              Wildcard'ing the endpoint URLs or only using domains, I
              don't think
              
    
              will work as we've proven that open redirect holes break
              this
              
    
              thinking. It needs to be an exact match.
              
    
              
    
                
    
                John B.
                
    
                
    
                
    
                
    
                
    
                
    
                
    On Mar 16, 2016, at 3:46 PM,
                  Phil Hunt <phil.hunt@oracle.com
                  
    
                  <mailto:phil.hunt@oracle.com>> wrote:
                  
    
                  
    
                  George,
                  
    
                  
    
                  Thanks. It would be good to get a draft that sketches
                  out the
                  
    
                  overall picture of this for BA — even if in very rough
                  form given
                  
    
                  the deadline is monday.  Or, maybe just a PPT
                  walkthru.
                  
    
                  
    
                  Interested to see what comes out.
                  
    
                  
    
                  Phil
                  
    
                  
    
                  @independentid
                  
    
<http://www.independentid.com/>www.independentid.com
                  
    
                  phil.hunt@oracle.com
                  <mailto:phil.hunt@oracle.com>
                  
    
                  
    
                  
    
                  
    
                  
    
                  
    
                  
    On Mar 16, 2016, at 11:29 AM,
                    George Fletcher
                    
    
                    <<mailto:gffletch@aol.com>gffletch@aol.com>
                    wrote:
                    
    
                    
    
                    Inline...
                    
    
                    
    
                    On 3/16/16 2:16 PM, Phil Hunt wrote:
                    
    
                    
    
                      
    
                      Phil
                      
    
                      
    
                      @independentid
                      
    
<http://www.independentid.com/>www.independentid.com
                      
    
                      phil.hunt@oracle.com
                      <mailto:phil.hunt@oracle.com>
                      
    
                      
    
                      
    
                      
    
                      
    
                      
    
                      
    On Mar 16, 2016, at 10:59
                        AM, George Fletcher
                        
    
                        <<mailto:gffletch@aol.com>gffletch@aol.com>
                        wrote:
                        
    
                        
    
                        
    
                        
    
                        On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
                        
    
                        
    George
                          
    
                          
    
                          Very good question...
                          
    
                          
    
                          I considered that the RS metadata discovery
                          could be fake.
                          
    
                        
    
                        Same way that the 'iss' claim must "match" the
                        url used to
                        
    
                        retrieve the metadata would apply to the 'rsid'
                        claim
                        
    
                        -- I think that should suffice to ensuring the
                        'rsid' identifier
                        
    
                        can't be spoofed by another site
                        
    
                      
    
                      
    
                      So the attacker makes iss and url match for the
                      resource
                      
    
                      discovery. Yet the AS service provider doesn’t
                      know where the
                      
    
                      client is using the tokens.  How would the client
                      or the AS detect
                      
    
                      that the wrong iss was given?
                      
    
                    
    
                    Because if the attacker makes the rsid and the url
                    match, then the
                    
    
                    client will submit an rsid that isn't "registered"
                    with the AS and
                    
    
                    the AS won't issue the token. This assumes the
                    client is not
                    
    
                    talking to an evil AS (as there are other
                    mitigations for that case).
                    
    
                    
    
                      
    
                      
    
                        
    
                          
    
                          So the final step in configuration validation
                          is to bind the
                          
    
                          relationship between as and rs discovery
                          together to confirm the
                          
    
                          relationship is valid.
                          
    
                        
    
                        And what I'd like to see is the 'rsid' value
                        used to represent
                        
    
                        the RS rather than some unique endpoint (even if
                        wildcards are
                        
    
                        allowed)
                        
    
                      
    
                      
    
                      Long term, I think this would be better. Do we
                      have a way to issue
                      
    
                      RSID values in the works?
                      
    
                    
    
                    No, but that is what this email thread is
                    contemplating:) Just as
                    
    
                    the AS iss value is selfdefined by the AS, the rsid
                    should be
                    
    
                    selfdefined by the RS. Requiring a 'rsid' claim in
                    the RS metadata
                    
    
                    is a mirror of how the AS 'iss' claim is defined for
                    the AS in it's
                    
    
                    metadata.
                    
    
                    
    
                      
    
                      That said, I would have thought this is more
                      ownerous than
                      
    
                      checking *.example.com
                      <http://example.com/>matches the given URL
                      
    
                      by the client.
                      
    
                    
    
                    My problem with the URL level checking is that a RS
                    may
                    
    
                    legitimately have endpoints on multiple domains. An
                    RS may move
                    
    
                    endpoints from one domain to another (say when
                    moving from version
                    
    
                    1 to version 2 of an API). Using the rsid for
                    audience restriction
                    
    
                    and as an indirect mechanism for specifying actual
                    endpoints, the
                    
    
                    RS has a much looser coupling with the AS.
                    
    
                    
    
                    AS we move into "federated authorization" meaning
                    that an RS
                    
    
                    outsources it's API authorization to one or more
                    AS's, this will
                    
    
                    become more important.
                    
    
                    
    
                      
    
                        
    
                        Another step that may be required is for the RS
                        to return it's
                        
    
                        'rsid' in the realm field of the
                        WWW-Authenticate response
                        
    
                        header. This allows a client to discover
                        metadata about the RS
                        
    
                        and it's endpoints. It also allows the client to
                        determine if the
                        
    
                        'rsid' returned by the RS matches the 'rsid' it
                        is expecting.
                        
    
                      
    
                      
    
                      Agreed. This might work. But should the check be
                      when the client
                      
    
                      asks for the configuration metadata or when the
                      client asks for
                      
    
                      tokens?  I think it only needs to happen at config
                      time.
                      
    
                    
    
                    What I see here is that the desire is to audience
                    protect tokens.
                    
    
                    To do that, the audience need to be specified
                    everytime a token is
                    
    
                    requested. I really don't the AS to have to manage
                    the complex
                    
    
                    state of which audiences have previously been issued
                    to
                    
    
                    refresh_tokens and then reconstruct the correct
                    audience for a
                    
    
                    requested downscoped access_token. It's much
                    simpler, since the
                    
    
                    client knows which RS it's going to send the token
                    to, to provide
                    
    
                    that when requesting tokens.
                    
    
                    
    
                    The complication comes when exchanging the code for
                    the tokens, it
                    
    
                    needs to specify all possible audiences (rsid's) it
                    might send the
                    
    
                    token to based on the requested scopes. There will
                    be a fair amount
                    
    
                    of complex logic at the AS to ensure the correct
                    behavior. I do
                    
    
                    worry about this complexity.
                    
    
                    
    
                      
    
                        
    
                          
    
                          We are of course assuming that a hacker needs
                          to use the real AS
                          
    
                          authorize endpoint to succeed in obtaining an
                          access token(it
                          
    
                          can't be mitm'd). Once the grant is obtained
                          by the client, the
                          
    
                          threat comes when the client uses the grant at
                          a mitm'd token
                          
    
                          endpoint OR an access token at a mitm'd
                          resource endpoint.
                          
    
                          
    
                          So the AS and its config set becomes the trust
                          anchor. Binding
                          
    
                          allows us to extend trust to the RS discovery
                          giving some
                          
    
                          assurance that a client has a correct set of
                          endpoints including
                          
    
                          resource.
                          
    
                        
    
                        Are you recommending that the AS metadata
                        provide a list of the
                        
    
                        'rsid' supported by the AS?
                        
    
                      
    
                      No.  I think that is a bad idea.  Better to use an
                      identity oracle
                      
    
                      function and say, give me the config for rsid=xyz
                      
    
                    
    
                    Good :)
                    
    
                    
    
                      
    
                      That also allows a common AS discovery endpoint to
                      actually do
                      
    
                      discovery for multiple AS systems.  E.g. to
                      configure a client to
                      
    
                      a specific AS service designated by the customer
                      paying for the
                      
    
                      resource service.
                      
    
                      
    
                      IOW. by providing a resource query, the meta-data
                      config discovery
                      
    
                      actually looks more like discovery.  :-)
                      
    
                      
    
                        
    
                          
    
                          John's solution requires translating aud to
                          res url and changes
                          
    
                          to core oauth. He seems to imply there is a
                          need for ongoing
                          
    
                          validation of resource. I'm not yet convinced
                          that is really
                          
    
                          needed.  Maybe it is needed because the client
                          could be
                          
    
                          convinced to follow a link embedded in a
                          resource that is
                          
    
                          somehow not part of the defined audience?
                          
    
                          
    
                          Thanks
                          
    
                          
    
                          Phil
                          
    
                          
    
                          On Mar 16, 2016, at 08:57, George Fletcher
                          <gffletch@aol.com> wrote:
                          
    
                          
    
                          
    So, in thinking about
                            all this AS restricting tokens to RS and
                            
    
                            "discovery" of RS endpoints, etc. I wondered
                            why we don't just
                            
    
                            leverage RS metadata like we have AS
                            metadata.
                            
    
                            
    
                            For an AS we require an 'iss' claim to use
                            as an identifier of
                            
    
                            the AS. We could do the same with RS
                            metadata retrieving the
                            
    
                            metadata from a .well-known location and
                            including a claim of
                            
    
                            'rsid' to use as an identifier of the
                            Resource Server.
                            
    
                            
    
                            This 'rsid' identifier could then be used
                            for registration with
                            
    
                            the AS and presentation by the client when
                            requesting tokens.
                            
    
                            
    
                            This provides a separation between an
                            identifier for a resource
                            
    
                            and the specific endpoints the token will be
                            sent to. A client
                            
    
                            could "discover" the necessary endpoint on a
                            periodic basis and
                            
    
                            use a single identifier with the AS for any
                            of the endpoints or
                            
    
                            scopes supported by the RS. If desired the
                            RS could expose the
                            
    
                            supported scopes in the RS metadata file.
                            
    
                            
    
                            Thoughts?
                            
    
                            
    
                            Thanks,
                            
    
                            George
                            
    
_______________________________________________
                            
    
                            OAuth mailing list
                            
    
                            <mailto:OAuth@ietf.org>OAuth@ietf.org
                            
    
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
                            
    
                          
    
                        
    
                      
    
                    
    
                    
    
                  
    
                  
    
                  _______________________________________________
                  
    
                  OAuth mailing list
                  
    
                  OAuth@ietf.org <mailto:OAuth@ietf.org>
                  
    
                  https://www.ietf.org/mailman/listinfo/oauth
                  
    
                
    
                
    
              
    
              
    
            
    
            
    
            
    
            _______________________________________________
            
    
            OAuth mailing list
            
    
            OAuth@ietf.org
            
    
            https://www.ietf.org/mailman/listinfo/oauth
            
    
            
    
          
    
          
    
          --
          
    
          Hans Zandbelt              | Sr. Technical Architect
          
    
          hzandbelt@pingidentity.com | Ping Identity
          
    
          
    
          _______________________________________________
          
    
          OAuth mailing list
          
    
          OAuth@ietf.org
          
    
          https://www.ietf.org/mailman/listinfo/oauth
          
    
        
    
        
    
      
    
    
    
    
    
  


--------------050301060608090506010903--


From nobody Thu Mar 17 10:43:54 2016
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 10ADC12D573 for ; Thu, 17 Mar 2016 10:43:53 -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=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 BJ6JxTb5Kj8k for ; Thu, 17 Mar 2016 10:43:49 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 926CB12DA21 for ; Thu, 17 Mar 2016 10:37:18 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id l124so3548447wmf.1 for ; Thu, 17 Mar 2016 10:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=fYDNJnV745xziLljXyLKkjKSd52BSAOaa8xPDBzj6mk=; b=eyb/5eJ0SiUrkV0Lj4Mvr1biiObiKuGWzP9lmrBkCCQUDTBQqF5dM+jkv3WVWOVurV ttPTCCKRPY8QGmwvTmJ7DdMKjLiknCwX9FNiNzIKMH5q2pcnZI8V0U2b32jE3KncxkNZ 06d8/nYCy4Iekzt6RURH8ShIsqcAHeE2rst2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fYDNJnV745xziLljXyLKkjKSd52BSAOaa8xPDBzj6mk=; b=fTM5170L0JfhchKeOmLfL3FBQXdWaAkRfLIZd8n59g85kjaIa3joYXJpV5eHoph2Cr fV67AmBO4Qe8KVnAlSXlTp8jzAgwE9g4+6G0NNbxbFXyrDgGlj7+LQ/PBK7zkdTsHFmM Oxu5QwRKEDdqZPWANlBlcn0UJAghuvUEreckNTrTLpqpDbGUfa4b4ScHrrK6GWbnO3gG dZDupkLDbeDaayt+63dQxkZT9FLQBsY8hZGr29b0JaPhcEle+a3Ag+o5DLi+B9nIPhBm l81tTb0rdOhjW5zS6DkT+uwG69AM4YnXh5OyvhSx3CpYhPNygatSKwzKfVAx2PPUHJra ehww==
X-Gm-Message-State: AD7BkJJNo+683xv4BWyGC0JDqxnGgYP7KoyWiHVbfocSP0kejAZ39Et6Pqw4EJM3wPgsD1Yu
X-Received: by 10.194.59.233 with SMTP id c9mr10842083wjr.88.1458236237064; Thu, 17 Mar 2016 10:37:17 -0700 (PDT)
Received: from [192.168.12.137] ([81.144.134.66]) by smtp.gmail.com with ESMTPSA id l135sm9120464wmb.13.2016.03.17.10.37.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 10:37:16 -0700 (PDT)
To: George Fletcher , Justin Richer 
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com> <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com> <56EAE401.6090608@pingidentity.com>  <56EAE880.9020307@pingidentity.com> <56EAE9FE.9040707@aol.com>
From: Hans Zandbelt 
Message-ID: <56EAEB3B.7070006@pingidentity.com>
Date: Thu, 17 Mar 2016 17:36:59 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56EAE9FE.9040707@aol.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:43:53 -0000

agreed, I'm not suggesting that the client-to-evil-RS problem is 
addressed, I was objecting to the statement that Phil made about static 
configurations not being a problem; I don't think agreement was reached 
on a client-to-evil-AS solution either

Hans.

On 3/17/16 5:31 PM, George Fletcher wrote:
> Isn't the solution to that attack defined? I was not including that
> attack in the thinking around audience restricted tokens and AS / RS
> endpoint "discovery". I think that regardless of this current discussion
> the requirement for the AS to return issuer and client_id needs to stay
> as does the binding of state to code.
>
> I looked at the current email thread to be addressing an additional
> problem and that is how to help the client NOT send a token to an evil
> RS. From my understanding this hasn't been addressed. If I missed that
> discussion, feel free to point me to the thread.
>
> Thanks,
> George
>
> On 3/17/16 1:25 PM, Hans Zandbelt wrote:
>> a good AS (at first) may become compromised and attack another AS;
>> whilst I agree it is less likely and less easy in static configs
>> (hence my point about the dynamic scenario) the root cause is not
>> related to configuration: it is a runtime attack (well at least one of
>> the permutations is) on perfectly valid configurations
>>
>> Hans.
>>
>> On 3/17/16 5:16 PM, Justin Richer wrote:
>>> But it’s less likely (or less easy?) to have a malicious combination
>>> of endpoints in a static configuration. What this all boils down to
>>> is managing a set of endpoints as a “thing” that represents an AS
>>> (and some would argue associated RS). You can create that set
>>> manually or dynamically and fall prey to this attack, but it’s much
>>> more likely in the dynamic sense. That’s why this attack was
>>> propagated against OIDC first, where dynamic discovery of server
>>> information is almost expected by client libraries, and clients are
>>> designed to be used across domains.
>>>
>>>   — Justin
>>>
>>>> On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
>>>>  wrote:
>>>>
>>>> I'm sorry to keep pushing on this but the attack is not opened up by
>>>> discovery, having two fixed ASes is already a threat: multiple ASes
>>>> in general leaves the client exposed. Discovery just increases the
>>>> attack surface.
>>>>
>>>> Hans.
>>>>
>>>> On 3/17/16 4:16 PM, Phil Hunt wrote:
>>>>> George,
>>>>>
>>>>> For the attacks we looked at in Darmstadt, we discussed that in order
>>>>> for the attack to succeed (at least as envisioned), the attacker needs
>>>>> to have the client invoke the real authorize endpoint in order for the
>>>>> user to be successful in issuing the grant.
>>>>>
>>>>> Assuming that it is the case, the attacker can use a proxied token
>>>>> endpoint or a proxied resource endpoint.  A client that doesn’t know
>>>>> what the real endpoint should be could be confused depending on how
>>>>> discovery occurs.
>>>>>
>>>>> Keep in mind that the token endpoint and the resource communications
>>>>> happens in the back channel. The user is never going to see the URL
>>>>> that
>>>>> has been invoked.  So….we need to make sure the set of endpoints are
>>>>> bound together or  confirmed.
>>>>>
>>>>> Note: This hasn’t been a big issue to date because current apps
>>>>> tend to
>>>>> work with fixed or singleton infrastructure.
>>>>>
>>>>> One we expand OAuth out to scenarios where there are multiple service
>>>>> providers with different relationships with OAuth AS’s, we move into
>>>>> this dynamic category that opens the threat.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com 
>>>>> phil.hunt@oracle.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Mar 17, 2016, at 7:36 AM, George Fletcher >>>>> > wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/16/16 6:37 PM, John Bradley wrote:
>>>>>>> I agree with Phil that the client can’t trust any abstract
>>>>>>> identifier
>>>>>>> that it might get from a bad RS unless it is were a URI that the
>>>>>>> client or AS could deference to get a list of the concrete URI for
>>>>>>> the RS.
>>>>>> I guess I'm confused on this front as we are asking the client to
>>>>>> "trust" the AS identifier that is being returned by the AS as well as
>>>>>> the value the client gets from discovery if it uses that method to
>>>>>> obtain the AS endpoints.
>>>>>>
>>>>>> I don't understand why the same philosophy can't be used for Resource
>>>>>> Service identifier and endpoints.
>>>>>>>
>>>>>>> That seems like a lot of work that clients are unlikely to do.
>>>>>> If I can discover the RS endpoints once and cache them, that doesn't
>>>>>> seem that difficult. This only applies to clients that have some
>>>>>> support for dynamically accepting RS's and their endpoints.
>>>>>>
>>>>>> For clients that only support a single AS we are saying they can get
>>>>>> the AS identifier out-of-band and use that. We can easily do the same
>>>>>> thing for an RS identifier. They can either get it out-of-band (i.e.
>>>>>> hardcoded) or they can get them dynamically (not likely initially but
>>>>>> we shouldn't preclude it).
>>>>>>>
>>>>>>> A AS might do it if it wanted to look up the identifier for a given
>>>>>>> resource.
>>>>>>>
>>>>>>> Something like do get on resource get back Abstract identifier
>>>>>>> (probably well known location, as recently pointed out in another
>>>>>>> thread you can’t allow it to point to user content.)
>>>>>> Yes, you could do it this way, though the client still needs to get
>>>>>> those endpoints and if it's doing it dynamically, it will likely use
>>>>>> the same method to discover the endpoints:)
>>>>>>>
>>>>>>> The AS gets the file and maps the uri to a abstract identifier for
>>>>>>> audience.
>>>>>>>
>>>>>>> I guess that would be one way that you could map AS URI to a
>>>>>>> abstract
>>>>>>> identifier, but I wouldn’t want to count on clients doing it.
>>>>>> This will work fine, if the client has hardcoded endpoints.
>>>>>>
>>>>>> My main concern is that I don't want the AS to have to manage a
>>>>>> map of
>>>>>> endpoint URLs for each RS it's supporting.
>>>>>>
>>>>>> Think of an RS that supports multiple AS's. If the RS adds a new
>>>>>> endpoint, that endpoint can't go live until each AS receives the
>>>>>> endpoint and adds it to it's map. That is a deployment nightmare. The
>>>>>> mapping of RS to current endpoints has to dynamic even if it's
>>>>>> done by
>>>>>> the AS rather than the client.
>>>>>>
>>>>>> Wildcard'ing the endpoint URLs or only using domains, I don't think
>>>>>> will work as we've proven that open redirect holes break this
>>>>>> thinking. It needs to be an exact match.
>>>>>>>
>>>>>>> John B.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> George,
>>>>>>>>
>>>>>>>> Thanks. It would be good to get a draft that sketches out the
>>>>>>>> overall picture of this for BA — even if in very rough form given
>>>>>>>> the deadline is monday.  Or, maybe just a PPT walkthru.
>>>>>>>>
>>>>>>>> Interested to see what comes out.
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher
>>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>>
>>>>>>>>> Inline...
>>>>>>>>>
>>>>>>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>> @independentid
>>>>>>>>>> www.independentid.com
>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher
>>>>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>>>>>>> George
>>>>>>>>>>>>
>>>>>>>>>>>> Very good question...
>>>>>>>>>>>>
>>>>>>>>>>>> I considered that the RS metadata discovery could be fake.
>>>>>>>>>>> Same way that the 'iss' claim must "match" the url used to
>>>>>>>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>>>>>>>> -- I think that should suffice to ensuring the 'rsid' identifier
>>>>>>>>>>> can't be spoofed by another site
>>>>>>>>>>
>>>>>>>>>> So the attacker makes iss and url match for the resource
>>>>>>>>>> discovery. Yet the AS service provider doesn’t know where the
>>>>>>>>>> client is using the tokens.  How would the client or the AS
>>>>>>>>>> detect
>>>>>>>>>> that the wrong iss was given?
>>>>>>>>> Because if the attacker makes the rsid and the url match, then the
>>>>>>>>> client will submit an rsid that isn't "registered" with the AS and
>>>>>>>>> the AS won't issue the token. This assumes the client is not
>>>>>>>>> talking to an evil AS (as there are other mitigations for that
>>>>>>>>> case).
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So the final step in configuration validation is to bind the
>>>>>>>>>>>> relationship between as and rs discovery together to confirm
>>>>>>>>>>>> the
>>>>>>>>>>>> relationship is valid.
>>>>>>>>>>> And what I'd like to see is the 'rsid' value used to represent
>>>>>>>>>>> the RS rather than some unique endpoint (even if wildcards are
>>>>>>>>>>> allowed)
>>>>>>>>>>
>>>>>>>>>> Long term, I think this would be better. Do we have a way to
>>>>>>>>>> issue
>>>>>>>>>> RSID values in the works?
>>>>>>>>> No, but that is what this email thread is contemplating:) Just as
>>>>>>>>> the AS iss value is selfdefined by the AS, the rsid should be
>>>>>>>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
>>>>>>>>> is a mirror of how the AS 'iss' claim is defined for the AS in
>>>>>>>>> it's
>>>>>>>>> metadata.
>>>>>>>>>>
>>>>>>>>>> That said, I would have thought this is more ownerous than
>>>>>>>>>> checking *.example.com matches the given URL
>>>>>>>>>> by the client.
>>>>>>>>> My problem with the URL level checking is that a RS may
>>>>>>>>> legitimately have endpoints on multiple domains. An RS may move
>>>>>>>>> endpoints from one domain to another (say when moving from version
>>>>>>>>> 1 to version 2 of an API). Using the rsid for audience restriction
>>>>>>>>> and as an indirect mechanism for specifying actual endpoints, the
>>>>>>>>> RS has a much looser coupling with the AS.
>>>>>>>>>
>>>>>>>>> AS we move into "federated authorization" meaning that an RS
>>>>>>>>> outsources it's API authorization to one or more AS's, this will
>>>>>>>>> become more important.
>>>>>>>>>>>
>>>>>>>>>>> Another step that may be required is for the RS to return it's
>>>>>>>>>>> 'rsid' in the realm field of the WWW-Authenticate response
>>>>>>>>>>> header. This allows a client to discover metadata about the RS
>>>>>>>>>>> and it's endpoints. It also allows the client to determine if
>>>>>>>>>>> the
>>>>>>>>>>> 'rsid' returned by the RS matches the 'rsid' it is expecting.
>>>>>>>>>>
>>>>>>>>>> Agreed. This might work. But should the check be when the client
>>>>>>>>>> asks for the configuration metadata or when the client asks for
>>>>>>>>>> tokens?  I think it only needs to happen at config time.
>>>>>>>>> What I see here is that the desire is to audience protect tokens.
>>>>>>>>> To do that, the audience need to be specified everytime a token is
>>>>>>>>> requested. I really don't the AS to have to manage the complex
>>>>>>>>> state of which audiences have previously been issued to
>>>>>>>>> refresh_tokens and then reconstruct the correct audience for a
>>>>>>>>> requested downscoped access_token. It's much simpler, since the
>>>>>>>>> client knows which RS it's going to send the token to, to provide
>>>>>>>>> that when requesting tokens.
>>>>>>>>>
>>>>>>>>> The complication comes when exchanging the code for the tokens, it
>>>>>>>>> needs to specify all possible audiences (rsid's) it might send the
>>>>>>>>> token to based on the requested scopes. There will be a fair
>>>>>>>>> amount
>>>>>>>>> of complex logic at the AS to ensure the correct behavior. I do
>>>>>>>>> worry about this complexity.
>>>>>>>>>>>>
>>>>>>>>>>>> We are of course assuming that a hacker needs to use the
>>>>>>>>>>>> real AS
>>>>>>>>>>>> authorize endpoint to succeed in obtaining an access token(it
>>>>>>>>>>>> can't be mitm'd). Once the grant is obtained by the client, the
>>>>>>>>>>>> threat comes when the client uses the grant at a mitm'd token
>>>>>>>>>>>> endpoint OR an access token at a mitm'd resource endpoint.
>>>>>>>>>>>>
>>>>>>>>>>>> So the AS and its config set becomes the trust anchor. Binding
>>>>>>>>>>>> allows us to extend trust to the RS discovery giving some
>>>>>>>>>>>> assurance that a client has a correct set of endpoints
>>>>>>>>>>>> including
>>>>>>>>>>>> resource.
>>>>>>>>>>> Are you recommending that the AS metadata provide a list of the
>>>>>>>>>>> 'rsid' supported by the AS?
>>>>>>>>>> No.  I think that is a bad idea.  Better to use an identity
>>>>>>>>>> oracle
>>>>>>>>>> function and say, give me the config for rsid=xyz
>>>>>>>>> Good :)
>>>>>>>>>>
>>>>>>>>>> That also allows a common AS discovery endpoint to actually do
>>>>>>>>>> discovery for multiple AS systems.  E.g. to configure a client to
>>>>>>>>>> a specific AS service designated by the customer paying for the
>>>>>>>>>> resource service.
>>>>>>>>>>
>>>>>>>>>> IOW. by providing a resource query, the meta-data config
>>>>>>>>>> discovery
>>>>>>>>>> actually looks more like discovery.  :-)
>>>>>>>>>>>>
>>>>>>>>>>>> John's solution requires translating aud to res url and changes
>>>>>>>>>>>> to core oauth. He seems to imply there is a need for ongoing
>>>>>>>>>>>> validation of resource. I'm not yet convinced that is really
>>>>>>>>>>>> needed.  Maybe it is needed because the client could be
>>>>>>>>>>>> convinced to follow a link embedded in a resource that is
>>>>>>>>>>>> somehow not part of the defined audience?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Phil
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> So, in thinking about all this AS restricting tokens to RS and
>>>>>>>>>>>>> "discovery" of RS endpoints, etc. I wondered why we don't just
>>>>>>>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For an AS we require an 'iss' claim to use as an identifier of
>>>>>>>>>>>>> the AS. We could do the same with RS metadata retrieving the
>>>>>>>>>>>>> metadata from a .well-known location and including a claim of
>>>>>>>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This 'rsid' identifier could then be used for registration
>>>>>>>>>>>>> with
>>>>>>>>>>>>> the AS and presentation by the client when requesting tokens.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This provides a separation between an identifier for a
>>>>>>>>>>>>> resource
>>>>>>>>>>>>> and the specific endpoints the token will be sent to. A client
>>>>>>>>>>>>> could "discover" the necessary endpoint on a periodic basis
>>>>>>>>>>>>> and
>>>>>>>>>>>>> use a single identifier with the AS for any of the
>>>>>>>>>>>>> endpoints or
>>>>>>>>>>>>> scopes supported by the RS. If desired the RS could expose the
>>>>>>>>>>>>> supported scopes in the RS metadata file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> George
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>> --
>>>> Hans Zandbelt              | Sr. Technical Architect
>>>> hzandbelt@pingidentity.com | Ping Identity
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Thu Mar 17 10:44:17 2016
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 4B6EB12D573 for ; Thu, 17 Mar 2016 10:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 kmC8RBmHzg_t for ; Thu, 17 Mar 2016 10:43:53 -0700 (PDT)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183D712DA16 for ; Thu, 17 Mar 2016 10:37:26 -0700 (PDT)
Received: from mtaout-aao01.mx.aol.com (mtaout-aao01.mx.aol.com [172.27.21.13]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 634903800046 for ; Thu, 17 Mar 2016 13:37:25 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aao01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BAD6F38000083 for ; Thu, 17 Mar 2016 13:37:24 -0400 (EDT)
To: "oauth@ietf.org" 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAEB54.8010208@aol.com>
Date: Thu, 17 Mar 2016 13:37:24 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458236245; bh=L22Vhs4wepMPatF7hn2HFeJ+KH36Ieu2a7p3lYTba+Y=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=dJOnxM5vrKimBL5qD4K/gn5PAh3/Uf5i+LIA/AlSodlAyR/njDhxknPCHV/bREE7g pbpGvHHZSetbcgYepKoKmQWqqsE1NBkcBUyP3i/95D6qcD4JE+MTnOsLAoCf3cp/lj 1BLQS6sITM4UiEAz96kB1J3+Qb+x6tfmxgNkKCIQ=
x-aol-sid: 3039ac1b150d56eaeb541f49
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:43:54 -0000

Goals:

1. Help the client not send a token to the "wrong" endpoint
    a. wrong AS /token endpoint
    b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended 
for that RS

Other high-level goals?

Use cases:

1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports 
the jabber API)
4. Client that dynamically supports new AS

Feel free to add to the list :)


From nobody Thu Mar 17 10:49:11 2016
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 8D4A412DA46 for ; Thu, 17 Mar 2016 10:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 1ryWOhl5RCfG for ; Thu, 17 Mar 2016 10:49:00 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 9EA0412DC74 for ; Thu, 17 Mar 2016 10:45:17 -0700 (PDT)
Received: by mail-qg0-x22f.google.com with SMTP id a36so46728900qge.0 for ; Thu, 17 Mar 2016 10:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5OK2P5rKQhcCrXZUV3FV+5ps6UAJTwAU4MATE6+GL/E=; b=ZBvxq8ffdSg42QoqO4OMRO+1EqxDIMWcn2cKOFeg358iWcGHfhqXZ+hQjHBV3zI6bX kPKmT7rTjpgeInOR2Ch96MNgQDZ4v0NDyG3IzqL39oMekfu7xZljmZ51m4+ggwEtx3Y5 rhLS3aDwaoKo2Qjalwp4VJpHLaKxBobRf70Twy6gAl+XrcxTC0l/iizZjoJoqlVJVfKe 9d4FCgKX/uKCWHmLo0oF06La6neXR2Yk6ZSqQNedSZCJ2ZkQEnlDJTcG7XgJIj9OODQm ePPJZZ3pd9je1RCSOSq004UmQ/mG2UJWS28ufZL2lWrTlygt2MmpFQtuhen/OULfggCn qmMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5OK2P5rKQhcCrXZUV3FV+5ps6UAJTwAU4MATE6+GL/E=; b=f6ylw9+4L2VjAmhte3akf0m4avg1KFfyAZ0T9u2xQo50ArPuWUqqKl+LFgGmt6AVaH 0FgiaBVS10uOnneUfoaBV2i0uWpQKPge/lk85gtC71No3Vo4aD0RmMywcNq73aciUDd5 GlDl6R4OdYKiP453nQJr5FcyoTrjxeCRsXCo+S4JII0Vto9jJJDVW6Q4O+N42mH3Gg70 K5xI4KtCyuI4zpa6PsvDL0RuN2YkBqSCFYaHmtLHK1cABtfGCZpkYKD4pwWjzchVo48R 3NiV5R7dqbWQkyt6tu9Er19OcU7MRERk6iF+9qrNAi3FWujYIYoZ8yWnnGA9smITHNt7 8RVg==
X-Gm-Message-State: AD7BkJKJKWbdUZSnBZivSpBVvaKB4kPampdWWKb6fKe0B4RiabZvWNFjUMHmGBlD6JVKcA==
X-Received: by 10.140.177.17 with SMTP id x17mr17164036qhx.39.1458236716640; Thu, 17 Mar 2016 10:45:16 -0700 (PDT)
Received: from [192.168.1.33] ([191.115.15.25]) by smtp.gmail.com with ESMTPSA id f66sm4251333qkb.5.2016.03.17.10.45.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Mar 2016 10:45:15 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_5A0453CE-2F6C-4945-B3E2-69836808C3F6"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>
Date: Thu, 17 Mar 2016 14:45:11 -0300
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:49:08 -0000

--Apple-Mail=_5A0453CE-2F6C-4945-B3E2-69836808C3F6
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FC0C1DE5-69B5-4455-BF7D-3ED2045739CD"


--Apple-Mail=_FC0C1DE5-69B5-4455-BF7D-3ED2045739CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It is not just redirects that are a threat.  Any user hosted content =
could potentially extract an access token from a query parameter.

John B.
> On Mar 17, 2016, at 1:34 PM, Phil Hunt  wrote:
>=20
> +1 for Nat's last few emails (avoiding generating too much traffic =
:-).
>=20
> Re: below, this is where I was thinking of masking/filter in bound =
config.  The main thing that needs to be checked at=20
> configuration time is whether the client has a valid set of server =
host names to prevent a malicious proxy.
>=20
> So all the examples you mention below do boil down to =
https://example.org  or https://example.com =

>=20
> It=E2=80=99s not that the AS needs to return them. It simply needs to =
match them. If one of them matches, then the oauth config can be =
returned.
>=20
> I do agree re-directs (of the ESPN scenario) can become an issue if a =
discovery system matches on *.example.com .  It =
presumes there are no open redirect servers in the example.com =
 domain.  As I mention in another email, we should =
discuss what happens when any oauth connection is redirected.  Should =
the client re-validate the configuration?
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 16, 2016, at 11:42 PM, Nat Sakimura > wrote:
>>=20
>> IMHO, list of URIs that represent the partial paths under the same =
authority would not be too onerous.=C2=A0 <>
>> =20
>> e.g., if you have=20
>> =20
>> https://example.com/apis/v1/userinfo =

>> https://example.com/apis/v2/userinfo =

>> https://example.org/some/api/endpoint =

>> =20
>> etc., then the AS may provide=20
>> =20
>> https://example.com/apis/ 
>> https://example.org/ 
>> =20
>> or something like that in the audiences.=20
>> =20
>> A completely new domain should not be trusted blindly.=20
>> The resource should at least make sure to provide the domain as being =
under the same authority.=20
>> =20
>> Bearer Token is a Password. It should not be shared among different =
authorities.=20
>> =20
>> Best,=20
>> =20
>> Nat
>> =20
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
>> Sent: Wednesday, March 16, 2016 3:15 AM
>> To: John Bradley >; =
Brian Campbell >
>> Cc: > >
>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>> =20
>> (..snip..)=20
>>=20
>> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.
>>=20
>>=20
>> (..snip..)
>>=20
>> --
>> PLEASE READ :This e-mail is confidential and intended for the
>> named recipient only. If you are not an intended recipient,
>> please notify the sender  and delete this e-mail.
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>=20


--Apple-Mail=_FC0C1DE5-69B5-4455-BF7D-3ED2045739CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It is not just redirects that are a threat.  Any user =
hosted content could potentially extract an access token from a query =
parameter.

    John =
B.
    On Mar 17, 2016, at 1:34 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    +1 for Nat's =
last few emails (avoiding generating too much traffic :-).

    Re: below, this is where =
I was thinking of masking/filter in bound config.  The main thing =
that needs to be checked at 
    configuration =
time is whether the client has a valid set of server host names to =
prevent a malicious proxy.

    So all the examples you mention below do boil down to https://example.org or https://example.com

    It=E2=80=99s not that =
the AS needs to return them. It simply needs to match them. If one of =
them matches, then the oauth config can be returned.

    I do agree re-directs =
(of the ESPN scenario) can become an issue if a discovery system matches =
on *.example.com. =
 It presumes there are no open redirect servers in the example.com domain.  As =
I mention in another email, we should discuss what happens when any =
oauth connection is redirected.  Should the client re-validate the =
configuration?

    




    

    

    On Mar 16, 2016, at 11:42 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:

    IMHO, list of URIs that represent the partial =
paths under the same authority would not be too onerous. 
     
    e.g., if you have 
     
    https://example.com/apis/v1/userinfo
    https://example.com/apis/v2/userinfo
    https://example.org/some/api/endpoint
     
    etc., then the =
AS may provide 
     
    https://example.com/apis/
    https://example.org/
     
    or something like that in the =
audiences. 
     
    A completely new =
domain should not be trusted blindly. 
    The resource should at least make sure to provide =
the domain as being under the same authority. 
     
    Bearer Token is =
a Password. It should not be shared among different authorities. 
     
    Best, 
     
    Nat
     
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of George =
Fletcher
    Sent: Wednesday, March 16, 2016 =
3:15 AM
    To: John Bradley <ve7jtb@ve7jtb.com>; Brian =
Campbell <bcampbell@pingidentity.com>
    Cc: <oauth@ietf.org> <oauth@ietf.org>
    Subject: Re: [OAUTH-WG] New Version =
Notification for draft-hunt-oauth-bound-config-00.txt
     
    (..snip..) 
    I'm not sure =
passing the full endpoint to the AS will help with my concerns... The AS =
could potentially do a webfinger on the resource URI and determine if =
it's an RS that it supports... though that requires all RS's to support =
webfinger. What I really want to avoid is the AS having this list of =
URIs to RS that is almost assuredly to get out of sync.

    (..snip..)
    --
    PLEASE READ :This e-mail is confidential and intended for =
the
    named recipient only. If you are not an intended =
recipient,
    please notify the sender  and delete this e-mail.
     
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    =

--Apple-Mail=_FC0C1DE5-69B5-4455-BF7D-3ED2045739CD--

--Apple-Mail=_5A0453CE-2F6C-4945-B3E2-69836808C3F6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTcxNzQ1MTFaMCMGCSqGSIb3DQEJBDEWBBRAlLDZuAr5Z71nAnNfMaGt
vJ2yfjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBMYGw/ByymztG7srbr/LRWxt/Ex0VRaNyuXEPWxa0BxxVqkn9Mrd2b
j04m1P3JBCsT0bGrRDN7hoa+r0aJWRYrjJW55IikCkQ3vzEyupqNDbjssBdMWLlwSz8FzuLQprzS
PcYkUrgk6F70xCrYlWD8gwQtF8VEzOlaztPXLcBO3aiJx0xXwzIF7C30+EoYOoA9B1mG7A+YBfMX
xCa+xz/kWySPS4tWulmP3QZ7kptr0qBT23mECuhuen4e8Z171Mr0CtgPcJB1w9LKiDrQknIuNvZL
zbV1jnzeJzLJ6gB37TBw8zwjBVtHOC+69UKdcIMUmM/wDOfXxamURyLCNb4cAAAAAAAA
--Apple-Mail=_5A0453CE-2F6C-4945-B3E2-69836808C3F6--


From nobody Thu Mar 17 10:54:06 2016
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 BED9612D5BB for ; Thu, 17 Mar 2016 10:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 Es3BRR-nW3Y2 for ; Thu, 17 Mar 2016 10:53:54 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 1AFB912DA63 for ; Thu, 17 Mar 2016 10:52:46 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2HHqfhO023048 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2016 17:52:41 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2HHqeuI000810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2016 17:52:41 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2HHqdIj001883; Thu, 17 Mar 2016 17:52:40 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Mar 2016 10:52:39 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_6E7EE145-E473-4DD1-B1C8-430661F5CA93"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <56EAEB3B.7070006@pingidentity.com>
Date: Thu, 17 Mar 2016 10:52:37 -0700
Message-Id: <0C1C90F8-B019-48E1-BCFD-FA3469EFCF6F@oracle.com>
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com> <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com> <56EAE401.6090608@pingidentity.com>  <56EAE880.9020307@pingidentity.com> <56EAE9FE.9040707@aol.com> <56EAEB3B.7070006@pingidentity.com>
To: Hans Zandbelt 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 17:54:03 -0000

--Apple-Mail=_6E7EE145-E473-4DD1-B1C8-430661F5CA93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Static deployments are a problem for mix-up. Agreed.

I=92m objecting to the notion that we don=92t have to worry about =
discovery threats and that we need to do mix-up first.

Rushing ahead with partial discovery so we can address mix-up seems like =
a *huge* mistake.

Mix-up depends on a bad insider to a large degree.

=46rom my perspective, there are many publishers of software (both open =
source and proprietary) that have their software deployed in 10s of =
thousands of environments in many different scenarios using millions of =
clients. There is a huge discovery problem coming and a correspondingly =
huge threat as we moving away from center-of-universe scenarios like we =
had with Facebook.

=46rom my perspective, bad configuration is a much larger threat.  But =
maybe that=92s just me.

Given that there is significant overlap in the solutions we should talk =
about mitigations for each and work to produce a set of documents that =
addresses all the threats together.

That is why some of us object to WGLC at this time.  We would be =
publishing drafts that would require revision in a few months!

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 17, 2016, at 10:36 AM, Hans Zandbelt =
 wrote:
>=20
> agreed, I'm not suggesting that the client-to-evil-RS problem is =
addressed, I was objecting to the statement that Phil made about static =
configurations not being a problem; I don't think agreement was reached =
on a client-to-evil-AS solution either
>=20
> Hans.
>=20
> On 3/17/16 5:31 PM, George Fletcher wrote:
>> Isn't the solution to that attack defined? I was not including that
>> attack in the thinking around audience restricted tokens and AS / RS
>> endpoint "discovery". I think that regardless of this current =
discussion
>> the requirement for the AS to return issuer and client_id needs to =
stay
>> as does the binding of state to code.
>>=20
>> I looked at the current email thread to be addressing an additional
>> problem and that is how to help the client NOT send a token to an =
evil
>> RS. =46rom my understanding this hasn't been addressed. If I missed =
that
>> discussion, feel free to point me to the thread.
>>=20
>> Thanks,
>> George
>>=20
>> On 3/17/16 1:25 PM, Hans Zandbelt wrote:
>>> a good AS (at first) may become compromised and attack another AS;
>>> whilst I agree it is less likely and less easy in static configs
>>> (hence my point about the dynamic scenario) the root cause is not
>>> related to configuration: it is a runtime attack (well at least one =
of
>>> the permutations is) on perfectly valid configurations
>>>=20
>>> Hans.
>>>=20
>>> On 3/17/16 5:16 PM, Justin Richer wrote:
>>>> But it=92s less likely (or less easy?) to have a malicious =
combination
>>>> of endpoints in a static configuration. What this all boils down to
>>>> is managing a set of endpoints as a =93thing=94 that represents an =
AS
>>>> (and some would argue associated RS). You can create that set
>>>> manually or dynamically and fall prey to this attack, but it=92s =
much
>>>> more likely in the dynamic sense. That=92s why this attack was
>>>> propagated against OIDC first, where dynamic discovery of server
>>>> information is almost expected by client libraries, and clients are
>>>> designed to be used across domains.
>>>>=20
>>>>  =97 Justin
>>>>=20
>>>>> On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
>>>>>  wrote:
>>>>>=20
>>>>> I'm sorry to keep pushing on this but the attack is not opened up =
by
>>>>> discovery, having two fixed ASes is already a threat: multiple =
ASes
>>>>> in general leaves the client exposed. Discovery just increases the
>>>>> attack surface.
>>>>>=20
>>>>> Hans.
>>>>>=20
>>>>> On 3/17/16 4:16 PM, Phil Hunt wrote:
>>>>>> George,
>>>>>>=20
>>>>>> For the attacks we looked at in Darmstadt, we discussed that in =
order
>>>>>> for the attack to succeed (at least as envisioned), the attacker =
needs
>>>>>> to have the client invoke the real authorize endpoint in order =
for the
>>>>>> user to be successful in issuing the grant.
>>>>>>=20
>>>>>> Assuming that it is the case, the attacker can use a proxied =
token
>>>>>> endpoint or a proxied resource endpoint.  A client that doesn=92t =
know
>>>>>> what the real endpoint should be could be confused depending on =
how
>>>>>> discovery occurs.
>>>>>>=20
>>>>>> Keep in mind that the token endpoint and the resource =
communications
>>>>>> happens in the back channel. The user is never going to see the =
URL
>>>>>> that
>>>>>> has been invoked.  So=85.we need to make sure the set of =
endpoints are
>>>>>> bound together or  confirmed.
>>>>>>=20
>>>>>> Note: This hasn=92t been a big issue to date because current apps
>>>>>> tend to
>>>>>> work with fixed or singleton infrastructure.
>>>>>>=20
>>>>>> One we expand OAuth out to scenarios where there are multiple =
service
>>>>>> providers with different relationships with OAuth AS=92s, we move =
into
>>>>>> this dynamic category that opens the threat.
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com 
>>>>>> phil.hunt@oracle.com 
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Mar 17, 2016, at 7:36 AM, George Fletcher >>>>>> > wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 3/16/16 6:37 PM, John Bradley wrote:
>>>>>>>> I agree with Phil that the client can=92t trust any abstract
>>>>>>>> identifier
>>>>>>>> that it might get from a bad RS unless it is were a URI that =
the
>>>>>>>> client or AS could deference to get a list of the concrete URI =
for
>>>>>>>> the RS.
>>>>>>> I guess I'm confused on this front as we are asking the client =
to
>>>>>>> "trust" the AS identifier that is being returned by the AS as =
well as
>>>>>>> the value the client gets from discovery if it uses that method =
to
>>>>>>> obtain the AS endpoints.
>>>>>>>=20
>>>>>>> I don't understand why the same philosophy can't be used for =
Resource
>>>>>>> Service identifier and endpoints.
>>>>>>>>=20
>>>>>>>> That seems like a lot of work that clients are unlikely to do.
>>>>>>> If I can discover the RS endpoints once and cache them, that =
doesn't
>>>>>>> seem that difficult. This only applies to clients that have some
>>>>>>> support for dynamically accepting RS's and their endpoints.
>>>>>>>=20
>>>>>>> For clients that only support a single AS we are saying they can =
get
>>>>>>> the AS identifier out-of-band and use that. We can easily do the =
same
>>>>>>> thing for an RS identifier. They can either get it out-of-band =
(i.e.
>>>>>>> hardcoded) or they can get them dynamically (not likely =
initially but
>>>>>>> we shouldn't preclude it).
>>>>>>>>=20
>>>>>>>> A AS might do it if it wanted to look up the identifier for a =
given
>>>>>>>> resource.
>>>>>>>>=20
>>>>>>>> Something like do get on resource get back Abstract identifier
>>>>>>>> (probably well known location, as recently pointed out in =
another
>>>>>>>> thread you can=92t allow it to point to user content.)
>>>>>>> Yes, you could do it this way, though the client still needs to =
get
>>>>>>> those endpoints and if it's doing it dynamically, it will likely =
use
>>>>>>> the same method to discover the endpoints:)
>>>>>>>>=20
>>>>>>>> The AS gets the file and maps the uri to a abstract identifier =
for
>>>>>>>> audience.
>>>>>>>>=20
>>>>>>>> I guess that would be one way that you could map AS URI to a
>>>>>>>> abstract
>>>>>>>> identifier, but I wouldn=92t want to count on clients doing it.
>>>>>>> This will work fine, if the client has hardcoded endpoints.
>>>>>>>=20
>>>>>>> My main concern is that I don't want the AS to have to manage a
>>>>>>> map of
>>>>>>> endpoint URLs for each RS it's supporting.
>>>>>>>=20
>>>>>>> Think of an RS that supports multiple AS's. If the RS adds a new
>>>>>>> endpoint, that endpoint can't go live until each AS receives the
>>>>>>> endpoint and adds it to it's map. That is a deployment =
nightmare. The
>>>>>>> mapping of RS to current endpoints has to dynamic even if it's
>>>>>>> done by
>>>>>>> the AS rather than the client.
>>>>>>>=20
>>>>>>> Wildcard'ing the endpoint URLs or only using domains, I don't =
think
>>>>>>> will work as we've proven that open redirect holes break this
>>>>>>> thinking. It needs to be an exact match.
>>>>>>>>=20
>>>>>>>> John B.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt >>>>>>>> > wrote:
>>>>>>>>>=20
>>>>>>>>> George,
>>>>>>>>>=20
>>>>>>>>> Thanks. It would be good to get a draft that sketches out the
>>>>>>>>> overall picture of this for BA =97 even if in very rough form =
given
>>>>>>>>> the deadline is monday.  Or, maybe just a PPT walkthru.
>>>>>>>>>=20
>>>>>>>>> Interested to see what comes out.
>>>>>>>>>=20
>>>>>>>>> Phil
>>>>>>>>>=20
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher
>>>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>>>=20
>>>>>>>>>> Inline...
>>>>>>>>>>=20
>>>>>>>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>>>>>>>=20
>>>>>>>>>>> Phil
>>>>>>>>>>>=20
>>>>>>>>>>> @independentid
>>>>>>>>>>> www.independentid.com
>>>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher
>>>>>>>>>>>> <gffletch@aol.com> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>>>>>>>> George
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Very good question...
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I considered that the RS metadata discovery could be fake.
>>>>>>>>>>>> Same way that the 'iss' claim must "match" the url used to
>>>>>>>>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>>>>>>>>> -- I think that should suffice to ensuring the 'rsid' =
identifier
>>>>>>>>>>>> can't be spoofed by another site
>>>>>>>>>>>=20
>>>>>>>>>>> So the attacker makes iss and url match for the resource
>>>>>>>>>>> discovery. Yet the AS service provider doesn=92t know where =
the
>>>>>>>>>>> client is using the tokens.  How would the client or the AS
>>>>>>>>>>> detect
>>>>>>>>>>> that the wrong iss was given?
>>>>>>>>>> Because if the attacker makes the rsid and the url match, =
then the
>>>>>>>>>> client will submit an rsid that isn't "registered" with the =
AS and
>>>>>>>>>> the AS won't issue the token. This assumes the client is not
>>>>>>>>>> talking to an evil AS (as there are other mitigations for =
that
>>>>>>>>>> case).
>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> So the final step in configuration validation is to bind =
the
>>>>>>>>>>>>> relationship between as and rs discovery together to =
confirm
>>>>>>>>>>>>> the
>>>>>>>>>>>>> relationship is valid.
>>>>>>>>>>>> And what I'd like to see is the 'rsid' value used to =
represent
>>>>>>>>>>>> the RS rather than some unique endpoint (even if wildcards =
are
>>>>>>>>>>>> allowed)
>>>>>>>>>>>=20
>>>>>>>>>>> Long term, I think this would be better. Do we have a way to
>>>>>>>>>>> issue
>>>>>>>>>>> RSID values in the works?
>>>>>>>>>> No, but that is what this email thread is contemplating:) =
Just as
>>>>>>>>>> the AS iss value is selfdefined by the AS, the rsid should be
>>>>>>>>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS =
metadata
>>>>>>>>>> is a mirror of how the AS 'iss' claim is defined for the AS =
in
>>>>>>>>>> it's
>>>>>>>>>> metadata.
>>>>>>>>>>>=20
>>>>>>>>>>> That said, I would have thought this is more ownerous than
>>>>>>>>>>> checking *.example.com matches the =
given URL
>>>>>>>>>>> by the client.
>>>>>>>>>> My problem with the URL level checking is that a RS may
>>>>>>>>>> legitimately have endpoints on multiple domains. An RS may =
move
>>>>>>>>>> endpoints from one domain to another (say when moving from =
version
>>>>>>>>>> 1 to version 2 of an API). Using the rsid for audience =
restriction
>>>>>>>>>> and as an indirect mechanism for specifying actual endpoints, =
the
>>>>>>>>>> RS has a much looser coupling with the AS.
>>>>>>>>>>=20
>>>>>>>>>> AS we move into "federated authorization" meaning that an RS
>>>>>>>>>> outsources it's API authorization to one or more AS's, this =
will
>>>>>>>>>> become more important.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Another step that may be required is for the RS to return =
it's
>>>>>>>>>>>> 'rsid' in the realm field of the WWW-Authenticate response
>>>>>>>>>>>> header. This allows a client to discover metadata about the =
RS
>>>>>>>>>>>> and it's endpoints. It also allows the client to determine =
if
>>>>>>>>>>>> the
>>>>>>>>>>>> 'rsid' returned by the RS matches the 'rsid' it is =
expecting.
>>>>>>>>>>>=20
>>>>>>>>>>> Agreed. This might work. But should the check be when the =
client
>>>>>>>>>>> asks for the configuration metadata or when the client asks =
for
>>>>>>>>>>> tokens?  I think it only needs to happen at config time.
>>>>>>>>>> What I see here is that the desire is to audience protect =
tokens.
>>>>>>>>>> To do that, the audience need to be specified everytime a =
token is
>>>>>>>>>> requested. I really don't the AS to have to manage the =
complex
>>>>>>>>>> state of which audiences have previously been issued to
>>>>>>>>>> refresh_tokens and then reconstruct the correct audience for =
a
>>>>>>>>>> requested downscoped access_token. It's much simpler, since =
the
>>>>>>>>>> client knows which RS it's going to send the token to, to =
provide
>>>>>>>>>> that when requesting tokens.
>>>>>>>>>>=20
>>>>>>>>>> The complication comes when exchanging the code for the =
tokens, it
>>>>>>>>>> needs to specify all possible audiences (rsid's) it might =
send the
>>>>>>>>>> token to based on the requested scopes. There will be a fair
>>>>>>>>>> amount
>>>>>>>>>> of complex logic at the AS to ensure the correct behavior. I =
do
>>>>>>>>>> worry about this complexity.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> We are of course assuming that a hacker needs to use the
>>>>>>>>>>>>> real AS
>>>>>>>>>>>>> authorize endpoint to succeed in obtaining an access =
token(it
>>>>>>>>>>>>> can't be mitm'd). Once the grant is obtained by the =
client, the
>>>>>>>>>>>>> threat comes when the client uses the grant at a mitm'd =
token
>>>>>>>>>>>>> endpoint OR an access token at a mitm'd resource endpoint.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> So the AS and its config set becomes the trust anchor. =
Binding
>>>>>>>>>>>>> allows us to extend trust to the RS discovery giving some
>>>>>>>>>>>>> assurance that a client has a correct set of endpoints
>>>>>>>>>>>>> including
>>>>>>>>>>>>> resource.
>>>>>>>>>>>> Are you recommending that the AS metadata provide a list of =
the
>>>>>>>>>>>> 'rsid' supported by the AS?
>>>>>>>>>>> No.  I think that is a bad idea.  Better to use an identity
>>>>>>>>>>> oracle
>>>>>>>>>>> function and say, give me the config for rsid=3Dxyz
>>>>>>>>>> Good :)
>>>>>>>>>>>=20
>>>>>>>>>>> That also allows a common AS discovery endpoint to actually =
do
>>>>>>>>>>> discovery for multiple AS systems.  E.g. to configure a =
client to
>>>>>>>>>>> a specific AS service designated by the customer paying for =
the
>>>>>>>>>>> resource service.
>>>>>>>>>>>=20
>>>>>>>>>>> IOW. by providing a resource query, the meta-data config
>>>>>>>>>>> discovery
>>>>>>>>>>> actually looks more like discovery.  :-)
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> John's solution requires translating aud to res url and =
changes
>>>>>>>>>>>>> to core oauth. He seems to imply there is a need for =
ongoing
>>>>>>>>>>>>> validation of resource. I'm not yet convinced that is =
really
>>>>>>>>>>>>> needed.  Maybe it is needed because the client could be
>>>>>>>>>>>>> convinced to follow a link embedded in a resource that is
>>>>>>>>>>>>> somehow not part of the defined audience?
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> So, in thinking about all this AS restricting tokens to =
RS and
>>>>>>>>>>>>>> "discovery" of RS endpoints, etc. I wondered why we don't =
just
>>>>>>>>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> For an AS we require an 'iss' claim to use as an =
identifier of
>>>>>>>>>>>>>> the AS. We could do the same with RS metadata retrieving =
the
>>>>>>>>>>>>>> metadata from a .well-known location and including a =
claim of
>>>>>>>>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> This 'rsid' identifier could then be used for =
registration
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> the AS and presentation by the client when requesting =
tokens.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> This provides a separation between an identifier for a
>>>>>>>>>>>>>> resource
>>>>>>>>>>>>>> and the specific endpoints the token will be sent to. A =
client
>>>>>>>>>>>>>> could "discover" the necessary endpoint on a periodic =
basis
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> use a single identifier with the AS for any of the
>>>>>>>>>>>>>> endpoints or
>>>>>>>>>>>>>> scopes supported by the RS. If desired the RS could =
expose the
>>>>>>>>>>>>>> supported scopes in the RS metadata file.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> George
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>>> =
https://www.ietf.org/mailman/=
listinfo/oauth
>>>>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>=20
>>>>> --
>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>> hzandbelt@pingidentity.com | Ping Identity
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>=20
>=20
> --=20
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com | Ping Identity


--Apple-Mail=_6E7EE145-E473-4DD1-B1C8-430661F5CA93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Static deployments are a problem for mix-up. Agreed.

    I=92m objecting to the =
notion that we don=92t have to worry about discovery threats and that we =
need to do mix-up first.

    Rushing ahead with partial discovery so we can address mix-up =
seems like a *huge* mistake.

    Mix-up depends on a bad insider to a =
large degree.

    =46rom my perspective, there are many publishers of software =
(both open source and proprietary) that have their software deployed in =
10s of thousands of environments in many different scenarios using =
millions of clients. There is a huge discovery problem coming and a =
correspondingly huge threat as we moving away from center-of-universe =
scenarios like we had with Facebook.

    =46rom my perspective, bad =
configuration is a much larger threat.  But maybe that=92s just =
me.

    Given that =
there is significant overlap in the solutions we should talk about =
mitigations for each and work to produce a set of documents that =
addresses all the threats together.

    That is why some of us object to WGLC =
at this time.  We would be publishing drafts that would require =
revision in a few months!

    


    

    

    On Mar 17, 2016, at 10:36 AM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

    agreed, I'm not suggesting that the client-to-evil-RS problem =
is addressed, I was objecting to the statement that Phil made about =
static configurations not being a problem; I don't think agreement was =
reached on a client-to-evil-AS solution either

    Hans.

    On 3/17/16 5:31 PM, George =
Fletcher wrote:
    Isn't =
the solution to that attack defined? I was not including that
    attack in the thinking around audience restricted tokens and =
AS / RS
    endpoint "discovery". I think that regardless of =
this current discussion
    the requirement for the AS to =
return issuer and client_id needs to stay
    as does the =
binding of state to code.

    I looked at the =
current email thread to be addressing an additional
    problem =
and that is how to help the client NOT send a token to an evil
    RS. =46rom my understanding this hasn't been addressed. If I =
missed that
    discussion, feel free to point me to the =
thread.

    Thanks,
    George

    On 3/17/16 1:25 PM, Hans Zandbelt wrote:
    a good AS (at first) may =
become compromised and attack another AS;
    whilst I agree =
it is less likely and less easy in static configs
    (hence =
my point about the dynamic scenario) the root cause is not
    related to configuration: it is a runtime attack (well at =
least one of
    the permutations is) on perfectly valid =
configurations

    Hans.

    On 3/17/16 5:16 PM, Justin Richer wrote:
    But it=92s less likely =
(or less easy?) to have a malicious combination
    of =
endpoints in a static configuration. What this all boils down to
    is managing a set of endpoints as a =93thing=94 that =
represents an AS
    (and some would argue associated RS). You =
can create that set
    manually or dynamically and fall prey =
to this attack, but it=92s much
    more likely in the dynamic =
sense. That=92s why this attack was
    propagated against =
OIDC first, where dynamic discovery of server
    information =
is almost expected by client libraries, and clients are
    designed to be used across domains.

      =97 Justin

    On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
    <hzandbelt@pingidentity.com> wrote:

    I'm sorry to keep pushing on this but the attack is not =
opened up by
    discovery, having two fixed ASes is already a =
threat: multiple ASes
    in general leaves the client =
exposed. Discovery just increases the
    attack surface.

    Hans.

    On 3/17/16 =
4:16 PM, Phil Hunt wrote:
    George,

    For the attacks we =
looked at in Darmstadt, we discussed that in order
    for the =
attack to succeed (at least as envisioned), the attacker needs
    to have the client invoke the real authorize endpoint in =
order for the
    user to be successful in issuing the =
grant.

    Assuming that it is the case, the =
attacker can use a proxied token
    endpoint or a proxied =
resource endpoint.  A client that doesn=92t know
    what =
the real endpoint should be could be confused depending on how
    discovery occurs.

    Keep in mind =
that the token endpoint and the resource communications
    happens in the back channel. The user is never going to see =
the URL
    that
    has been invoked.  So=85.we =
need to make sure the set of endpoints are
    bound together =
or  confirmed.

    Note: This hasn=92t =
been a big issue to date because current apps
    tend to
    work with fixed or singleton infrastructure.

    One we expand OAuth out to scenarios where there are multiple =
service
    providers with different relationships with OAuth =
AS=92s, we move into
    this dynamic category that opens the =
threat.

    Phil

    @independentid
    www.independentid.com=
 <http://www.independentid.com>
    phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>





    On Mar 17, 2016, at 7:36 =
AM, George Fletcher <gffletch@aol.com
    <mailto:gffletch@aol.com>> wrote:



    On 3/16/16 6:37 PM, John =
Bradley wrote:
    I =
agree with Phil that the client can=92t trust any abstract
    identifier
    that it might get from a bad RS =
unless it is were a URI that the
    client or AS could =
deference to get a list of the concrete URI for
    the RS.
    I guess I'm confused on this front as we are =
asking the client to
    "trust" the AS identifier that is =
being returned by the AS as well as
    the value the client =
gets from discovery if it uses that method to
    obtain the =
AS endpoints.

    I don't understand why the =
same philosophy can't be used for Resource
    Service =
identifier and endpoints.

    That seems like a lot of work that clients are =
unlikely to do.
    If I can discover the RS =
endpoints once and cache them, that doesn't
    seem that =
difficult. This only applies to clients that have some
    support for dynamically accepting RS's and their =
endpoints.

    For clients that only support a =
single AS we are saying they can get
    the AS identifier =
out-of-band and use that. We can easily do the same
    thing =
for an RS identifier. They can either get it out-of-band (i.e.
    hardcoded) or they can get them dynamically (not likely =
initially but
    we shouldn't preclude it).

    A AS =
might do it if it wanted to look up the identifier for a given
    resource.

    Something like do get =
on resource get back Abstract identifier
    (probably well =
known location, as recently pointed out in another
    thread =
you can=92t allow it to point to user content.)
    Yes, you could do it this way, though the client =
still needs to get
    those endpoints and if it's doing it =
dynamically, it will likely use
    the same method to =
discover the endpoints:)

    The AS gets the file and maps the uri to a =
abstract identifier for
    audience.

    I guess that would be one way that you could map AS URI to =
a
    abstract
    identifier, but I wouldn=92t want =
to count on clients doing it.
    This will work =
fine, if the client has hardcoded endpoints.

    My main concern is that I don't want the AS to have to manage =
a
    map of
    endpoint URLs for each RS it's =
supporting.

    Think of an RS that supports =
multiple AS's. If the RS adds a new
    endpoint, that =
endpoint can't go live until each AS receives the
    endpoint =
and adds it to it's map. That is a deployment nightmare. The
    mapping of RS to current endpoints has to dynamic even if =
it's
    done by
    the AS rather than the =
client.

    Wildcard'ing the endpoint URLs or =
only using domains, I don't think
    will work as we've =
proven that open redirect holes break this
    thinking. It =
needs to be an exact match.

    John B.





    On Mar 16, 2016, at 3:46 PM, Phil Hunt <phil.hunt@oracle.com
    <mailto:phil.hunt@oracle.com>> wrote:

    George,

    Thanks. =
It would be good to get a draft that sketches out the
    overall picture of this for BA =97 even if in very rough form =
given
    the deadline is monday.  Or, maybe just a PPT =
walkthru.

    Interested to see what comes =
out.

    Phil

    @independentid
    <http://www.independentid.com/>www.independentid.com
    phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>





    On Mar 16, 2016, at =
11:29 AM, George Fletcher
    <<mailto:gffletch@aol.com>gffletch@aol.com> =
wrote:

    Inline...

    On 3/16/16 2:16 PM, Phil Hunt wrote:

    Phil

    @independentid
    <http://www.independentid.com/>www.independentid.com
    phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>





    On Mar 16, 2016, at =
10:59 AM, George Fletcher
    <<mailto:gffletch@aol.com>gffletch@aol.com> =
wrote:



    On =
3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
    George

    Very good =
question...

    I considered that the RS =
metadata discovery could be fake.
    Same way =
that the 'iss' claim must "match" the url used to
    retrieve =
the metadata would apply to the 'rsid' claim
    -- I think =
that should suffice to ensuring the 'rsid' identifier
    can't =
be spoofed by another site

    So =
the attacker makes iss and url match for the resource
    discovery. Yet the AS service provider doesn=92t know where =
the
    client is using the tokens.  How would the client =
or the AS
    detect
    that the wrong iss was =
given?
    Because if the attacker makes the rsid =
and the url match, then the
    client will submit an rsid =
that isn't "registered" with the AS and
    the AS won't issue =
the token. This assumes the client is not
    talking to an =
evil AS (as there are other mitigations for that
    case).


    So the final step in configuration validation is to bind =
the
    relationship between as and rs discovery together to =
confirm
    the
    relationship is valid.
    And what I'd like to see is the 'rsid' value =
used to represent
    the RS rather than some unique endpoint =
(even if wildcards are
    allowed)

    Long term, I think this would be =
better. Do we have a way to
    issue
    RSID =
values in the works?
    No, but that is what =
this email thread is contemplating:) Just as
    the AS iss =
value is selfdefined by the AS, the rsid should be
    selfdefined by the RS. Requiring a 'rsid' claim in the RS =
metadata
    is a mirror of how the AS 'iss' claim is defined =
for the AS in
    it's
    metadata.

    That =
said, I would have thought this is more ownerous than
    checking *.example.com <http://example.com/>matches the given URL
    by the client.
    My problem with the =
URL level checking is that a RS may
    legitimately have =
endpoints on multiple domains. An RS may move
    endpoints =
from one domain to another (say when moving from version
    1 =
to version 2 of an API). Using the rsid for audience restriction
    and as an indirect mechanism for specifying actual endpoints, =
the
    RS has a much looser coupling with the AS.

    AS we move into "federated authorization" =
meaning that an RS
    outsources it's API authorization to =
one or more AS's, this will
    become more important.

    Another step that may be required is for the =
RS to return it's
    'rsid' in the realm field of the =
WWW-Authenticate response
    header. This allows a client to =
discover metadata about the RS
    and it's endpoints. It also =
allows the client to determine if
    the
    'rsid' =
returned by the RS matches the 'rsid' it is expecting.

    Agreed. This might work. But =
should the check be when the client
    asks for the =
configuration metadata or when the client asks for
    tokens? =
 I think it only needs to happen at config time.
    What I see here is that the desire is to =
audience protect tokens.
    To do that, the audience need to =
be specified everytime a token is
    requested. I really =
don't the AS to have to manage the complex
    state of which =
audiences have previously been issued to
    refresh_tokens =
and then reconstruct the correct audience for a
    requested =
downscoped access_token. It's much simpler, since the
    client=
 knows which RS it's going to send the token to, to provide
    that when requesting tokens.

    The =
complication comes when exchanging the code for the tokens, it
    needs to specify all possible audiences (rsid's) it might =
send the
    token to based on the requested scopes. There =
will be a fair
    amount
    of complex logic at =
the AS to ensure the correct behavior. I do
    worry about =
this complexity.

    We are of course assuming that a hacker needs =
to use the
    real AS
    authorize endpoint to =
succeed in obtaining an access token(it
    can't be mitm'd). =
Once the grant is obtained by the client, the
    threat comes =
when the client uses the grant at a mitm'd token
    endpoint =
OR an access token at a mitm'd resource endpoint.

    So the AS and its config set becomes the trust anchor. =
Binding
    allows us to extend trust to the RS discovery =
giving some
    assurance that a client has a correct set of =
endpoints
    including
    resource.
    Are you recommending that the AS metadata =
provide a list of the
    'rsid' supported by the AS?
    No.  I think that is a bad idea. =
 Better to use an identity
    oracle
    function and say, give me the config for rsid=3Dxyz
    Good :)

    That also allows a common AS discovery =
endpoint to actually do
    discovery for multiple AS systems. =
 E.g. to configure a client to
    a specific AS service =
designated by the customer paying for the
    resource =
service.

    IOW. by providing a resource =
query, the meta-data config
    discovery
    actually=
 looks more like discovery.  :-)

    John's solution requires translating aud to res url and =
changes
    to core oauth. He seems to imply there is a need =
for ongoing
    validation of resource. I'm not yet convinced =
that is really
    needed.  Maybe it is needed because =
the client could be
    convinced to follow a link embedded in =
a resource that is
    somehow not part of the defined =
audience?

    Thanks

    Phil

    On Mar 16, 2016, at 08:57, =
George Fletcher
    <gffletch@aol.com> wrote:

    So, in thinking about =
all this AS restricting tokens to RS and
    "discovery" of RS =
endpoints, etc. I wondered why we don't just
    leverage RS =
metadata like we have AS metadata.

    For an =
AS we require an 'iss' claim to use as an identifier of
    the =
AS. We could do the same with RS metadata retrieving the
    metadata from a .well-known location and including a claim =
of
    'rsid' to use as an identifier of the Resource =
Server.

    This 'rsid' identifier could then =
be used for registration
    with
    the AS and =
presentation by the client when requesting tokens.

    This provides a separation between an identifier for a
    resource
    and the specific endpoints the token =
will be sent to. A client
    could "discover" the necessary =
endpoint on a periodic basis
    and
    use a =
single identifier with the AS for any of the
    endpoints =
or
    scopes supported by the RS. If desired the RS could =
expose the
    supported scopes in the RS metadata file.

    Thoughts?

    Thanks,
    George
    _______________________________________________
    OAuth mailing list
    <mailto:OAuth@ietf.org>OAuth@ietf.org
    <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth



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




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


    --
    Hans Zandbelt =
            &n=
bsp;| Sr. Technical Architect
    hzandbelt@pingidentity.com | Ping Identity

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



    -- 
    Hans Zandbelt =
            &n=
bsp;| Sr. Technical Architect
    hzandbelt@pingidentity.com | Ping Identity

    =

--Apple-Mail=_6E7EE145-E473-4DD1-B1C8-430661F5CA93--


From nobody Thu Mar 17 11:05:21 2016
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 5123A12DA34 for ; Thu, 17 Mar 2016 11:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 hFxV-Gfbp2ta for ; Thu, 17 Mar 2016 11:05:11 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 96F0F12D9D2 for ; Thu, 17 Mar 2016 11:05:05 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id o6so38700964qkc.2 for ; Thu, 17 Mar 2016 11:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=d/jTr1X19fkFu8WW7jYIcUxib/v9pdHSFF79f+vumg4=; b=ZZtdZRN8+oPEIJteZkw0EWZ5N4YBm66QoEVdtntmpzbuhqiWHZoJJolVRxefjzd9wt FHwGr4fniAU8CaO6+dlVctI6AjK5gMQlSdWqetOS02L0xgnptne0Ur2pt9iPjHDiRu2P F78IOxurY4oTdKNaGfhZIMpzWV8GFjSk9Orn3l1BVRs4m0PpSsDfg1K11XBemRVVUU4Y /O4btVc65/DoB3USEfaymEl4srDfWybnLsQACVlfMDXvwi6Wv5K5GipWQMWnSbF+BKSb ed5pht0ACoC9vjO9p0D3rLFol5RibgcsVU0ajN3m5iERdRmrzfZEDDn4fsKKFWa2yL5K 2QXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=d/jTr1X19fkFu8WW7jYIcUxib/v9pdHSFF79f+vumg4=; b=Wryv+VrglJ1N7D7ERDSmaNOycQ+QIjcq1nh3zLRoFjZdY4be5QqDrLvpaog78SwkKN KsNw5S6+plbKBqdevmE4JpJ8R1w1y5Vo7cVS5BePTVI4hhoYxdHyT/OdgewOKhvQX1rS Pyq7mMF2N3D0tObD5BZmWTHcxC8rxSJ2a0tdMmDAyLnt8hMw5cD8hPvR8ksKnT8z7p6x +DgCWjbLHreXsMlGUGnUxiHEg/bGrzSh4q+BPWLutaMUa7PWgMv3FHk+/d8M4d85ul2t L5NsXCPGVWmoEjqPBFGsGFbZZkdJHGiE0JJbZNFAVEBzH8AgVFmXpR3BbklSq20Dsqyv DVTQ==
X-Gm-Message-State: AD7BkJLfJ2RTH+usBm/as1W6yH5b3m+xxSoPRZQPGZCnxNCyrgYLks1M437tWZ5iDIek/w==
X-Received: by 10.55.77.206 with SMTP id a197mr16055861qkb.43.1458237904580; Thu, 17 Mar 2016 11:05:04 -0700 (PDT)
Received: from [192.168.1.33] ([191.115.15.25]) by smtp.gmail.com with ESMTPSA id x6sm4285235qka.16.2016.03.17.11.05.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Mar 2016 11:05:03 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_E94D1EC7-46F5-4CE6-80A0-1815136DCD62"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56EAE6B8.7050702@aol.com>
Date: Thu, 17 Mar 2016 15:05:00 -0300
Message-Id: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com> <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <56EAC287.30601@aol.com> <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com> <448DED6D-9DA6-4DA4-A107-A0E56F5060EF@oracle.com> <56EAE6B8.7050702@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 18:05:19 -0000

--Apple-Mail=_E94D1EC7-46F5-4CE6-80A0-1815136DCD62
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5AF9BE06-2F31-42D5-98EE-5BCD7618559D"


--Apple-Mail=_5AF9BE06-2F31-42D5-98EE-5BCD7618559D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes without pop the mappings become a challenge quickly. =20

We don=E2=80=99t have any sort of API management in OAuth, and that =
makes trying to secure bearer tokens a real challenge if you want a =
single token with multiple audiences.

To have multiple audiences you need to have hight trust in all of the =
endpoints.   If the RS endpoints check the audience then you can have no =
trust in the RS as long as it has only one audience.

I do have a more basic question, and that would be how the client gets =
this bad RS URI.=20

Without nailing that down mitigating it is turning into a circular =
conversation.

John B.
=20


> On Mar 17, 2016, at 2:17 PM, George Fletcher  wrote:
>=20
> =46rom my perspective we are not trying to solve a mix-up case or any =
other attack. We are trying to solve for audience restricted tokens in =
OAuth2 without PoP. In working to solve that case, we also want to close =
any possible attacks but that is not the primary goal. I, personally, =
don't want a bunch of one-off solutions to identified attacks if we can =
design an cohesive solution that provides value and mitigates known =
attacks.
>=20
> Thanks,
> George
>=20
> On 3/17/16 12:27 PM, Phil Hunt wrote:
>>=20
>> I think in the mis-configuration case, it is different form the =
redirect issues.
>>=20
>> What we are concerned about is an attackers ability to convince the =
client to set up a connection via an attackers proxy which can even have =
a valid TLS enabled.  The client won=E2=80=99t know it has done =
something wrong. In fact it will confirm it has correctly connected to =
the attackers proxy.
>>=20
>> I don=E2=80=99t believe we have to have exact-match to work here.  We =
need preferable an exact host match.=20
>>=20
>> I agree there can be a redirect issue pop up once we allow domain =
matching.  What we could ask the client to do is reconfirm discovery =
when it receives a redirect from a resource.  I=E2=80=99m not a fan of =
this because it depends on the client doing something that seems =
optional (even when it isn=E2=80=99t).  BUT=E2=80=A6.this might be the =
out for SP=E2=80=99s like George=E2=80=99s case where they don=E2=80=99t =
know the exact URL=E2=80=99s clients will be using.
>>=20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com =
phil.hunt@oracle.com =

>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 17, 2016, at 8:48 AM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>=20
>>> The problem is similar to the one with redirect_uri,  if you allow =
user hosted content on the domain they will be able to get the token if =
it is sent as a query parameter, and might be able to if it is sent as a =
header. =20
>>>=20
>>> Unfortunately many OAuth clients are badly behaved and make use of =
the query parameter not considering the security issues.
>>>=20
>>> Anything other than the AS or the client doing an exact URI match is =
going to leave some hole.
>>>=20
>>> This is why we are working on POP that is the correct way to solve =
this for AS.
>>>=20
>>> I think anything other than the client giving the AS the whole URI =
and the AS including that as a audience/destination and letting the RS =
figure out if it is correct is largely hopeless, as it will be to =
fragile or the client won=E2=80=99t do it. =20
>>>=20
>>> In the case of Phil=E2=80=99s proposal the discovery happens once at =
client setup so the AS has no idea if the client checked  before issuing =
the token.
>>>=20
>>> I honestly think there are two viable options:
>>> 1 PoP tokens
>>> 2 Including the destination URI / RS URI (pick name) in the token in =
full and letting the RS decide if it has been man in the middled.
>>>=20
>>> Everything else will be an endless game of wack-a-mole that =
increases complexity but gets little real security.
>>>=20
>>> John B.
>>>=20
>>>=20
>>>> On Mar 17, 2016, at 11:43 AM, George Fletcher > wrote:
>>>>=20
>>>> If one of the APIs has an open-redirect problem, won't that cause =
the token to leak to the attacker? That's why we went to exact match in =
OpenID Connect. Does it not apply in this case?
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>> On 3/17/16 2:42 AM, Nat Sakimura wrote:
>>>>> IMHO, list of URIs that represent the partial paths under the same =
authority would not be too onerous.=C2=A0 <>
>>>>> =20
>>>>> e.g., if you have=20
>>>>> =20
>>>>> https://example.com/apis/v1/userinfo =

>>>>> https://example.com/apis/v2/userinfo =

>>>>> https://example.org/some/api/endpoint =

>>>>> =20
>>>>> etc., then the AS may provide=20
>>>>> =20
>>>>> https://example.com/apis/ 
>>>>> https://example.org/ 
>>>>> =20
>>>>> or something like that in the audiences.=20
>>>>> =20
>>>>> A completely new domain should not be trusted blindly.=20
>>>>> The resource should at least make sure to provide the domain as =
being under the same authority.=20
>>>>> =20
>>>>> Bearer Token is a Password. It should not be shared among =
different authorities.=20
>>>>> =20
>>>>> Best,=20
>>>>> =20
>>>>> Nat
>>>>> =20
>>>>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of George Fletcher
>>>>> Sent: Wednesday, March 16, 2016 3:15 AM
>>>>> To: John Bradley   =
; Brian Campbell  =
 =

>>>>> Cc:   =
   =

>>>>> Subject: Re: [OAUTH-WG] New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
>>>>> =20
>>>>> (..snip..)=20
>>>>>=20
>>>>> I'm not sure passing the full endpoint to the AS will help with my =
concerns... The AS could potentially do a webfinger on the resource URI =
and determine if it's an RS that it supports... though that requires all =
RS's to support webfinger. What I really want to avoid is the AS having =
this list of URIs to RS that is almost assuredly to get out of sync.
>>>>>=20
>>>>>=20
>>>>> (..snip..)
>>>>>=20
>>>>> --
>>>>> PLEASE READ :This e-mail is confidential and intended for the
>>>>> named recipient only. If you are not an intended recipient,
>>>>> please notify the sender  and delete this e-mail.
>>>>> =20
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>=20


--Apple-Mail=_5AF9BE06-2F31-42D5-98EE-5BCD7618559D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes without pop the mappings become a challenge quickly. =
 

    We don=E2=80=99=
t have any sort of API management in OAuth, and that makes trying to =
secure bearer tokens a real challenge if you want a single token with =
multiple audiences.

    To have multiple audiences you need to have hight trust in =
all of the endpoints.   If the RS endpoints check the audience then =
you can have no trust in the RS as long as it has only one =
audience.

    I do =
have a more basic question, and that would be how the client gets this =
bad RS URI. 

    Without nailing that down mitigating it is turning into a =
circular conversation.

    John B.
     


    On Mar 17, 2016, at 2:17 PM, =
George Fletcher <gffletch@aol.com> wrote:

    
 =20
    
 =20
  
    
    =46rom my =
perspective we are
      not trying to solve a mix-up case or any other attack. We are
      trying to solve for audience restricted tokens in OAuth2 without
      PoP. In working to solve that case, we also want to close any
      possible attacks but that is not the primary goal. I, personally,
      don't want a bunch of one-off solutions to identified attacks if
      we can design an cohesive solution that provides value and
      mitigates known attacks.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/17/16 12:27 PM, Phil Hunt =
wrote:
    
    
    
    
    
      
      

    
      
    
      I think in the mis-configuration case, it is different form the
      redirect issues.
      

    
      
    
      
    What we are concerned about is an attackers =
ability
        to convince the client to set up a connection via an attackers
        proxy which can even have a valid TLS enabled.  The client =
won=E2=80=99t
        know it has done something wrong. In fact it will confirm it has
        correctly connected to the attackers proxy.
    
      

    
      
    
      
    I don=E2=80=99t believe we have to have =
exact-match to work
        here.  We need preferable an exact host match. 
    
      

    
      
    
      
    I agree there can be a redirect issue pop up once =
we
        allow domain matching.  What we could ask the client to do =
is
        reconfirm discovery when it receives a redirect from a resource.
         I=E2=80=99m not a fan of this because it depends on the =
client doing
        something that seems optional (even when it isn=E2=80=99t). =
 BUT=E2=80=A6.this
        might be the out for SP=E2=80=99s like George=E2=80=99s case =
where they don=E2=80=99t
        know the exact URL=E2=80=99s clients will be using.
    
      

    
      
    
      

    
        
    
          
    
            
    
              
    
                  
    
                    
    
                      
    
                        
    Phil
    
                        

    
                        
    
                        
    @independentid
    
                        
    www.independentid.com
    
                      
    
                    
    
                  
    
                    phil.hunt@oracle.com
    
              

    
              
    
            
    
            
    
          
    
          
    
          
    
        
    
        
    
        
    
          
    
            
    On Mar 17, 2016, at 8:48 AM, John Bradley =
<ve7jtb@ve7jtb.com> wrote:
    
            
    
            
    
              
              
    The
                problem is similar to the one with redirect_uri, =
 if you
                allow user hosted content on the domain they will be
                able to get the token if it is sent as a query
                parameter, and might be able to if it is sent as a
                header.  
                

    
                
    
                
    Unfortunately many OAuth clients are =
badly
                  behaved and make use of the query parameter not
                  considering the security issues.
    
                

    
                
    
                
    Anything other than the AS or the client
                  doing an exact URI match is going to leave some =
hole.
    
                

    
                
    
                
    This is why we are working on POP that =
is
                  the correct way to solve this for AS.
    
                

    
                
    
                
    I think anything other than the client
                  giving the AS the whole URI and the AS including that
                  as a audience/destination and letting the RS figure
                  out if it is correct is largely hopeless, as it will
                  be to fragile or the client won=E2=80=99t do it. =
 
    
                

    
                
    
                
    In the case of Phil=E2=80=99s proposal =
the
                  discovery happens once at client setup so the AS has
                  no idea if the client checked  before issuing the
                  token.
    
                

    
                
    
                
    I honestly think there are two viable
                  options:
    
                
    1 PoP tokens
    
                
    2 Including the destination URI / RS URI
                  (pick name) in the token in full and letting the RS
                  decide if it has been man in the middled.
    
                

    
                
    
                
    Everything else will be an endless game =
of
                  wack-a-mole that increases complexity but gets little
                  real security.
    
                

    
                
    
                
    John B.
    
                

    
                
    
                

    
                  
    
                    
    
                      
    On Mar 17, 2016, at 11:43 AM, =
George
                        Fletcher <gffletch@aol.com>
                        wrote:
    
                      
    
                      
    If
                          one of the APIs has an open-redirect problem,
                          won't that cause the token to leak to the
                          attacker? That's why we went to exact match in
                          OpenID Connect. Does it not apply in this
                          case?
    
                          
    
                          Thanks,
    
                          George
    
                        
    
                        
    On
                          3/17/16 2:42 AM, Nat Sakimura wrote:
    
                        
    
                        
    
                          
    
                            
    IMHO,
                                  list of URIs that represent the
                                  partial paths under the same authority
                                  would not be too onerous. 
    
                            
     
    
                            
    e.g.,
                                if you have 
    
                            
     
    
                            
    https://example.com/apis/v1/userinfo
    
                            
    https://example.com/apis/v2/userinfo
    
                            
    https://example.org/some/api/endpoint
    
                            
     
    
                            
    etc.,
                                then the AS may provide 
    
                            
     
    
                            
    https://example.com/apis/
    
                            
    https://example.org/
    
                            
     
    
                            
    or
                                something like that in the =
audiences. 
    
                            
     
    
                            
    A
                                completely new domain should not be
                                trusted blindly. 
    
                            
    The
                                resource should at least make sure to
                                provide the domain as being under the
                                same authority. 
    
                            
     
    
                            
    Bearer
                                Token is a Password. It should not be
                                shared among different authorities. 
    
                            
     
    
                            
    Best, 
    
                            
     
    
                            
    Nat
    
                            
     
    
                            
    
                              
    
                                
    From: OAuth
                                    [mailto:oauth-bounces@ietf.org] On Behalf =
Of George
                                    Fletcher
    
                                    Sent: Wednesday,
                                    March 16, 2016 3:15 AM
    
                                    To: John
                                    Bradley <ve7jtb@ve7jtb.com>;
                                    Brian Campbell <bcampbell@pingidentity.com&=
gt;
    
                                    Cc: <oauth@ietf.org> <oauth@ietf.org>
    
                                    Subject: Re:
                                    [OAUTH-WG] New Version Notification
                                    for
                                    =
draft-hunt-oauth-bound-config-00.txt
    
                              
    
                            
    
                            
     
    (..snip..) 
    I'm not sure passing the
                                full endpoint to the AS will help with
                                my concerns... The AS could potentially
                                do a webfinger on the resource URI and
                                determine if it's an RS that it
                                supports... though that requires all
                                RS's to support webfinger. What I really
                                want to avoid is the AS having this list
                                of URIs to RS that is almost assuredly
                                to get out of sync.
    
                                
    
                              
    (..snip..)
    
                            
    --
    
                            
    PLEASE READ :This
                                e-mail is confidential and intended for
                                the
    
                            
    named recipient
                                only. If you are not an intended
                                recipient,
    
                            
    please notify the
                                sender  and delete this e-mail.
    
                            
     
    
                          
    
                        
    
                        
    
                        
    
                      
    
                    
    
                  
    
                  
    
                
    
              
    
              _______________________________________________
    
              OAuth mailing list
    
              OAuth@ietf.org
    
              https://www.ietf.org/=
mailman/listinfo/oauth
    
            
    
          
    
        
    
      
    
    
    
    
    
  
    



    =

--Apple-Mail=_5AF9BE06-2F31-42D5-98EE-5BCD7618559D--

--Apple-Mail=_E94D1EC7-46F5-4CE6-80A0-1815136DCD62
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTcxODA1MDBaMCMGCSqGSIb3DQEJBDEWBBR8i+fdmgcI69QsyFlkhXvs
USOzuzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQB5U9AWRO0uiJIsCENMNPW0vZYRD0lZ7GMU35Z7SPQrGRoRJntCB/YW
HvTuGUdNAjo+Mn5Qb0I71NROJtKxSYBr/Fv3sZpopjjqXVCg3bs5gvVyhNP80BUURLAi1o9JGt4f
qLpCUGcB2jRM35qVS7cA8OMQPgllzVTFwIlzzvGgz+90EF1Abyugfb9qK7l/5wa9JCB/NNX8Rahg
9+TB5lxcJCNMxH29iEJbjUN4EBVCRCtsq3D23MJJLtvT2xVucgf37i73CXHMYEO2UGd1W5HsncHt
aU03OAGP7MgVWjyLP8OmZndWm4UGFaiZB2fwxc8imaoALEaBmRi6bfsD6w3KAAAAAAAA
--Apple-Mail=_E94D1EC7-46F5-4CE6-80A0-1815136DCD62--


From nobody Thu Mar 17 11:17:23 2016
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 6A8B812D8CC for ; Thu, 17 Mar 2016 11:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mx.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 bxCK--U40Prg for ; Thu, 17 Mar 2016 11:17:20 -0700 (PDT)
Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4023112D686 for ; Thu, 17 Mar 2016 11:17:20 -0700 (PDT)
Received: from mtaout-aae02.mx.aol.com (mtaout-aae02.mx.aol.com [172.27.1.98]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id F20763800195; Thu, 17 Mar 2016 14:17:18 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aae02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9B1BB38000092; Thu, 17 Mar 2016 14:17:18 -0400 (EDT)
To: John Bradley 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <56EAC287.30601@aol.com> <960A257C-8485-48DB-9353-0E8DB26A0861@ve7jtb.com> <448DED6D-9DA6-4DA4-A107-A0E56F5060EF@oracle.com> <56EAE6B8.7050702@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EAF4AE.7050509@aol.com>
Date: Thu, 17 Mar 2016 14:17:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020602060505040704020704"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458238638; bh=YS3StbeXgbj/KRCUpuUf0CUolXHp1Bj6sQTsNQHdvJs=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=DPn055oNLb8JI7rPltjjVN3TuFlUocTxJx6tofuV264d6jUJklo4GF9Tq+oecB4H0 lHkwXHJ3ooT7iNRAxlz0sdBpNhm4wOnm3G1OG5C/qWLwKycIvI9A32XQCawiwt/H+A gBzEPltP07Pw+Z2a23VRCmRFxS+O/76CT4SUWRjY=
x-aol-sid: 3039ac1b016256eaf4ae671c
X-AOL-IP: 10.172.102.179
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 18:17:21 -0000

This is a multi-part message in MIME format.
--------------020602060505040704020704
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Agreed... so I started a new thread on use cases:) Here is one example.

Assume there is a client that speaks a known OAuth2 protected protocol 
(e.g. PortableContacts, or something like Jabber). A user of the client 
can enter the endpoint of their RS that speaks the protocol and the 
client "discovers" the rest. This is kind of how Thunderbird and other 
mail clients work. I would hope that OAuth2 protected application APIs 
would develop so that this is possible.

Thanks,
George

On 3/17/16 2:05 PM, John Bradley wrote:
> (snip)
>
> I do have a more basic question, and that would be how the client gets 
> this bad RS URI.
>
> Without nailing that down mitigating it is turning into a circular 
> conversation.
>
> John B.
> (snip)


--------------020602060505040704020704
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Agreed... so I started a
      new thread on use cases:) Here is one example.
    
      
    
      Assume there is a client that speaks a known OAuth2 protected
      protocol (e.g. PortableContacts, or something like Jabber). A user
      of the client can enter the endpoint of their RS that speaks the
      protocol and the client "discovers" the rest. This is kind of how
      Thunderbird and other mail clients work. I would hope that OAuth2
      protected application APIs would develop so that this is possible.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/17/16 2:05 PM, John Bradley wrote:
    
    
    
    
    
      
      (snip)
      

    
      
    
      
    I do have a more basic question, and that would be
        how the client gets this bad RS URI. 
    
      

    
      
    
      
    Without nailing that down mitigating it is turning
        into a circular conversation.
    
      

    
      
    
      
    John B.
    
      
     
    
      (snip)
    
    
    
  


--------------020602060505040704020704--


From nobody Thu Mar 17 11:19:53 2016
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 4F87612D686 for ; Thu, 17 Mar 2016 11:19:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 ipmGfBISj9uv for ; Thu, 17 Mar 2016 11:19:48 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 A323312D95F for ; Thu, 17 Mar 2016 11:19:47 -0700 (PDT)
Received: by mail-qg0-x234.google.com with SMTP id w104so79304698qge.1 for ; Thu, 17 Mar 2016 11:19:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=6o29/wzbHtdCBkA9+EeI0xRQf6SSTM9t3eTPnhw7p/E=; b=vqDtjegbTYyAwJcf0cY9PSQDzxINcwL3ftGVaXdmpNamEp4rtA2x8SDkmLVyhtPnnY 1vDXM3wk9jSDn4y7ES5S8M7gITKeIbBiKljQrVIrUv1uSAUzHfFYJY1FMaYLdMJprsip toZ6wYlDAP2lMfXxkJhxjCw3RsGII+5YP08gAWlF14YfWIGsJRvHL+Lp1MyKQgc6kYLj lqjIcZwOL47bkA97apUhUuJwQ7uqAr/wC3UBRa5/Bi/dMxJxYiFWzDnjuwTIJ+lTAtak Eicn4N7NeUZkaAgjNJOdI/1yeom90YAzGkY1H+RN/rJNAQ29HlGQYj351F4/kGcY0Zgq +pEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6o29/wzbHtdCBkA9+EeI0xRQf6SSTM9t3eTPnhw7p/E=; b=HEtB4p3VmCXpNS339HXbhRMBtU/A0BHXKxevVpTwGCI5D2H+9AQ8GT30T1CFNCNDnf tzLD1sECHCFg2S/P19XMxYvDn9sh4kZJynp78W3Uu6KN2gE1xWiLX0Fu2L/gow89k6Pe I4Er4Zp49l1rs0AJYcIBvhC0JrgipJGjOciaLUdC246W29zJCCaAx9Izwqnr5dCmna1j iLCNFSc91oTCVWnp5hY1jmdifymMobm7VmFqSTr06b81GII0y2v0ta/Gl6RkYqILaJkJ Jt6+pW97bMDZujHRBibYCU34GBF5VxVAiHh4iySYvzfxQOyWYasHorS3LJPOeM9BKhyw ubKQ==
X-Gm-Message-State: AD7BkJKD9Khren5HI1Cg5/5e4a4Pr+DAsxZVGsXizkXyPIB9nM3JI3PQSqk3oGKWrN/W0A==
X-Received: by 10.140.239.66 with SMTP id k63mr17414862qhc.11.1458238786515; Thu, 17 Mar 2016 11:19:46 -0700 (PDT)
Received: from [192.168.1.33] ([191.115.15.25]) by smtp.gmail.com with ESMTPSA id b67sm3016947qhd.11.2016.03.17.11.19.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Mar 2016 11:19:45 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_156742AE-B0A2-4C4B-8AEA-2DF731251C06"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <0C1C90F8-B019-48E1-BCFD-FA3469EFCF6F@oracle.com>
Date: Thu, 17 Mar 2016 15:19:41 -0300
Message-Id: <045BD634-2082-4A4B-954C-CF8A1B9147AB@ve7jtb.com>
References: <56E98274.10002@aol.com> <3DD214D0-41A4-4734-8E8C-B166F35712A8@oracle.com> <56E99F01.5020002@aol.com> <2BE0C696-041C-4EB9-9A7F-C0B61E343EB3@oracle.com> <56E9A5F6.2010405@aol.com> <61E386F1-1545-4941-9B46-F0872B1ACA3A@oracle.com> <425376C7-44F7-4787-A125-F32019479796@ve7jtb.com> <56EAC0D2.3090108@aol.com> <20055E88-9E52-47C9-B12E-371AB69E5E50@oracle.com> <56EAE401.6090608@pingidentity.com>  <56EAE880.9020307@pingidentity.com> <56EAE9FE.9040707@aol.com> <56EAEB3B.7070006@pingidentity.com> <0C1C90F8-B019-48E1-BCFD-FA3469EFCF6F@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Resource Service metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 18:19:52 -0000

--Apple-Mail=_156742AE-B0A2-4C4B-8AEA-2DF731251C06
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3AA1A5AA-5816-461A-9178-5FAF1D13FD1B"


--Apple-Mail=_3AA1A5AA-5816-461A-9178-5FAF1D13FD1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I keep saying that the mixup mitigation draft doesn't require discovery. =
 =20

The AS meta-data draft started before the mixup mitigation work and is =
not related, other than that they both use the concept of issuer, as do =
you.

The mixup doesn=92t require discovery but it arguably makes it easier.

John B.



> On Mar 17, 2016, at 2:52 PM, Phil Hunt  wrote:
>=20
> Static deployments are a problem for mix-up. Agreed.
>=20
> I=92m objecting to the notion that we don=92t have to worry about =
discovery threats and that we need to do mix-up first.
>=20
> Rushing ahead with partial discovery so we can address mix-up seems =
like a *huge* mistake.
>=20
> Mix-up depends on a bad insider to a large degree.
>=20
> =46rom my perspective, there are many publishers of software (both =
open source and proprietary) that have their software deployed in 10s of =
thousands of environments in many different scenarios using millions of =
clients. There is a huge discovery problem coming and a correspondingly =
huge threat as we moving away from center-of-universe scenarios like we =
had with Facebook.
>=20
> =46rom my perspective, bad configuration is a much larger threat.  But =
maybe that=92s just me.
>=20
> Given that there is significant overlap in the solutions we should =
talk about mitigations for each and work to produce a set of documents =
that addresses all the threats together.
>=20
> That is why some of us object to WGLC at this time.  We would be =
publishing drafts that would require revision in a few months!
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 17, 2016, at 10:36 AM, Hans Zandbelt =
> wrote:
>>=20
>> agreed, I'm not suggesting that the client-to-evil-RS problem is =
addressed, I was objecting to the statement that Phil made about static =
configurations not being a problem; I don't think agreement was reached =
on a client-to-evil-AS solution either
>>=20
>> Hans.
>>=20
>> On 3/17/16 5:31 PM, George Fletcher wrote:
>>> Isn't the solution to that attack defined? I was not including that
>>> attack in the thinking around audience restricted tokens and AS / RS
>>> endpoint "discovery". I think that regardless of this current =
discussion
>>> the requirement for the AS to return issuer and client_id needs to =
stay
>>> as does the binding of state to code.
>>>=20
>>> I looked at the current email thread to be addressing an additional
>>> problem and that is how to help the client NOT send a token to an =
evil
>>> RS. =46rom my understanding this hasn't been addressed. If I missed =
that
>>> discussion, feel free to point me to the thread.
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 3/17/16 1:25 PM, Hans Zandbelt wrote:
>>>> a good AS (at first) may become compromised and attack another AS;
>>>> whilst I agree it is less likely and less easy in static configs
>>>> (hence my point about the dynamic scenario) the root cause is not
>>>> related to configuration: it is a runtime attack (well at least one =
of
>>>> the permutations is) on perfectly valid configurations
>>>>=20
>>>> Hans.
>>>>=20
>>>> On 3/17/16 5:16 PM, Justin Richer wrote:
>>>>> But it=92s less likely (or less easy?) to have a malicious =
combination
>>>>> of endpoints in a static configuration. What this all boils down =
to
>>>>> is managing a set of endpoints as a =93thing=94 that represents an =
AS
>>>>> (and some would argue associated RS). You can create that set
>>>>> manually or dynamically and fall prey to this attack, but it=92s =
much
>>>>> more likely in the dynamic sense. That=92s why this attack was
>>>>> propagated against OIDC first, where dynamic discovery of server
>>>>> information is almost expected by client libraries, and clients =
are
>>>>> designed to be used across domains.
>>>>>=20
>>>>>  =97 Justin
>>>>>=20
>>>>>> On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
>>>>>> > =
wrote:
>>>>>>=20
>>>>>> I'm sorry to keep pushing on this but the attack is not opened up =
by
>>>>>> discovery, having two fixed ASes is already a threat: multiple =
ASes
>>>>>> in general leaves the client exposed. Discovery just increases =
the
>>>>>> attack surface.
>>>>>>=20
>>>>>> Hans.
>>>>>>=20
>>>>>> On 3/17/16 4:16 PM, Phil Hunt wrote:
>>>>>>> George,
>>>>>>>=20
>>>>>>> For the attacks we looked at in Darmstadt, we discussed that in =
order
>>>>>>> for the attack to succeed (at least as envisioned), the attacker =
needs
>>>>>>> to have the client invoke the real authorize endpoint in order =
for the
>>>>>>> user to be successful in issuing the grant.
>>>>>>>=20
>>>>>>> Assuming that it is the case, the attacker can use a proxied =
token
>>>>>>> endpoint or a proxied resource endpoint.  A client that doesn=92t =
know
>>>>>>> what the real endpoint should be could be confused depending on =
how
>>>>>>> discovery occurs.
>>>>>>>=20
>>>>>>> Keep in mind that the token endpoint and the resource =
communications
>>>>>>> happens in the back channel. The user is never going to see the =
URL
>>>>>>> that
>>>>>>> has been invoked.  So=85.we need to make sure the set of =
endpoints are
>>>>>>> bound together or  confirmed.
>>>>>>>=20
>>>>>>> Note: This hasn=92t been a big issue to date because current =
apps
>>>>>>> tend to
>>>>>>> work with fixed or singleton infrastructure.
>>>>>>>=20
>>>>>>> One we expand OAuth out to scenarios where there are multiple =
service
>>>>>>> providers with different relationships with OAuth AS=92s, we =
move into
>>>>>>> this dynamic category that opens the threat.
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> @independentid
>>>>>>> www.independentid.com  =
>
>>>>>>> phil.hunt@oracle.com  =
>
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Mar 17, 2016, at 7:36 AM, George Fletcher 
>>>>>>>> >> wrote:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 3/16/16 6:37 PM, John Bradley wrote:
>>>>>>>>> I agree with Phil that the client can=92t trust any abstract
>>>>>>>>> identifier
>>>>>>>>> that it might get from a bad RS unless it is were a URI that =
the
>>>>>>>>> client or AS could deference to get a list of the concrete URI =
for
>>>>>>>>> the RS.
>>>>>>>> I guess I'm confused on this front as we are asking the client =
to
>>>>>>>> "trust" the AS identifier that is being returned by the AS as =
well as
>>>>>>>> the value the client gets from discovery if it uses that method =
to
>>>>>>>> obtain the AS endpoints.
>>>>>>>>=20
>>>>>>>> I don't understand why the same philosophy can't be used for =
Resource
>>>>>>>> Service identifier and endpoints.
>>>>>>>>>=20
>>>>>>>>> That seems like a lot of work that clients are unlikely to do.
>>>>>>>> If I can discover the RS endpoints once and cache them, that =
doesn't
>>>>>>>> seem that difficult. This only applies to clients that have =
some
>>>>>>>> support for dynamically accepting RS's and their endpoints.
>>>>>>>>=20
>>>>>>>> For clients that only support a single AS we are saying they =
can get
>>>>>>>> the AS identifier out-of-band and use that. We can easily do =
the same
>>>>>>>> thing for an RS identifier. They can either get it out-of-band =
(i.e.
>>>>>>>> hardcoded) or they can get them dynamically (not likely =
initially but
>>>>>>>> we shouldn't preclude it).
>>>>>>>>>=20
>>>>>>>>> A AS might do it if it wanted to look up the identifier for a =
given
>>>>>>>>> resource.
>>>>>>>>>=20
>>>>>>>>> Something like do get on resource get back Abstract identifier
>>>>>>>>> (probably well known location, as recently pointed out in =
another
>>>>>>>>> thread you can=92t allow it to point to user content.)
>>>>>>>> Yes, you could do it this way, though the client still needs to =
get
>>>>>>>> those endpoints and if it's doing it dynamically, it will =
likely use
>>>>>>>> the same method to discover the endpoints:)
>>>>>>>>>=20
>>>>>>>>> The AS gets the file and maps the uri to a abstract identifier =
for
>>>>>>>>> audience.
>>>>>>>>>=20
>>>>>>>>> I guess that would be one way that you could map AS URI to a
>>>>>>>>> abstract
>>>>>>>>> identifier, but I wouldn=92t want to count on clients doing =
it.
>>>>>>>> This will work fine, if the client has hardcoded endpoints.
>>>>>>>>=20
>>>>>>>> My main concern is that I don't want the AS to have to manage a
>>>>>>>> map of
>>>>>>>> endpoint URLs for each RS it's supporting.
>>>>>>>>=20
>>>>>>>> Think of an RS that supports multiple AS's. If the RS adds a =
new
>>>>>>>> endpoint, that endpoint can't go live until each AS receives =
the
>>>>>>>> endpoint and adds it to it's map. That is a deployment =
nightmare. The
>>>>>>>> mapping of RS to current endpoints has to dynamic even if it's
>>>>>>>> done by
>>>>>>>> the AS rather than the client.
>>>>>>>>=20
>>>>>>>> Wildcard'ing the endpoint URLs or only using domains, I don't =
think
>>>>>>>> will work as we've proven that open redirect holes break this
>>>>>>>> thinking. It needs to be an exact match.
>>>>>>>>>=20
>>>>>>>>> John B.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Mar 16, 2016, at 3:46 PM, Phil Hunt 
>>>>>>>>>> >> =
wrote:
>>>>>>>>>>=20
>>>>>>>>>> George,
>>>>>>>>>>=20
>>>>>>>>>> Thanks. It would be good to get a draft that sketches out the
>>>>>>>>>> overall picture of this for BA =97 even if in very rough form =
given
>>>>>>>>>> the deadline is monday.  Or, maybe just a PPT walkthru.
>>>>>>>>>>=20
>>>>>>>>>> Interested to see what comes out.
>>>>>>>>>>=20
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> @independentid
>>>>>>>>>> >www.independentid.com =

>>>>>>>>>> phil.hunt@oracle.com  =
>
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> On Mar 16, 2016, at 11:29 AM, George Fletcher
>>>>>>>>>>> <>gffletch@aol.com > =
wrote:
>>>>>>>>>>>=20
>>>>>>>>>>> Inline...
>>>>>>>>>>>=20
>>>>>>>>>>> On 3/16/16 2:16 PM, Phil Hunt wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>> Phil
>>>>>>>>>>>>=20
>>>>>>>>>>>> @independentid
>>>>>>>>>>>> >www.independentid.com =

>>>>>>>>>>>> phil.hunt@oracle.com  =
>
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Mar 16, 2016, at 10:59 AM, George Fletcher
>>>>>>>>>>>>> <>gffletch@aol.com > =
wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
>>>>>>>>>>>>>> George
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Very good question...
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I considered that the RS metadata discovery could be =
fake.
>>>>>>>>>>>>> Same way that the 'iss' claim must "match" the url used to
>>>>>>>>>>>>> retrieve the metadata would apply to the 'rsid' claim
>>>>>>>>>>>>> -- I think that should suffice to ensuring the 'rsid' =
identifier
>>>>>>>>>>>>> can't be spoofed by another site
>>>>>>>>>>>>=20
>>>>>>>>>>>> So the attacker makes iss and url match for the resource
>>>>>>>>>>>> discovery. Yet the AS service provider doesn=92t know where =
the
>>>>>>>>>>>> client is using the tokens.  How would the client or the AS
>>>>>>>>>>>> detect
>>>>>>>>>>>> that the wrong iss was given?
>>>>>>>>>>> Because if the attacker makes the rsid and the url match, =
then the
>>>>>>>>>>> client will submit an rsid that isn't "registered" with the =
AS and
>>>>>>>>>>> the AS won't issue the token. This assumes the client is not
>>>>>>>>>>> talking to an evil AS (as there are other mitigations for =
that
>>>>>>>>>>> case).
>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> So the final step in configuration validation is to bind =
the
>>>>>>>>>>>>>> relationship between as and rs discovery together to =
confirm
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> relationship is valid.
>>>>>>>>>>>>> And what I'd like to see is the 'rsid' value used to =
represent
>>>>>>>>>>>>> the RS rather than some unique endpoint (even if wildcards =
are
>>>>>>>>>>>>> allowed)
>>>>>>>>>>>>=20
>>>>>>>>>>>> Long term, I think this would be better. Do we have a way =
to
>>>>>>>>>>>> issue
>>>>>>>>>>>> RSID values in the works?
>>>>>>>>>>> No, but that is what this email thread is contemplating:) =
Just as
>>>>>>>>>>> the AS iss value is selfdefined by the AS, the rsid should =
be
>>>>>>>>>>> selfdefined by the RS. Requiring a 'rsid' claim in the RS =
metadata
>>>>>>>>>>> is a mirror of how the AS 'iss' claim is defined for the AS =
in
>>>>>>>>>>> it's
>>>>>>>>>>> metadata.
>>>>>>>>>>>>=20
>>>>>>>>>>>> That said, I would have thought this is more ownerous than
>>>>>>>>>>>> checking *.example.com  =
>matches the given URL
>>>>>>>>>>>> by the client.
>>>>>>>>>>> My problem with the URL level checking is that a RS may
>>>>>>>>>>> legitimately have endpoints on multiple domains. An RS may =
move
>>>>>>>>>>> endpoints from one domain to another (say when moving from =
version
>>>>>>>>>>> 1 to version 2 of an API). Using the rsid for audience =
restriction
>>>>>>>>>>> and as an indirect mechanism for specifying actual =
endpoints, the
>>>>>>>>>>> RS has a much looser coupling with the AS.
>>>>>>>>>>>=20
>>>>>>>>>>> AS we move into "federated authorization" meaning that an RS
>>>>>>>>>>> outsources it's API authorization to one or more AS's, this =
will
>>>>>>>>>>> become more important.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Another step that may be required is for the RS to return =
it's
>>>>>>>>>>>>> 'rsid' in the realm field of the WWW-Authenticate response
>>>>>>>>>>>>> header. This allows a client to discover metadata about =
the RS
>>>>>>>>>>>>> and it's endpoints. It also allows the client to determine =
if
>>>>>>>>>>>>> the
>>>>>>>>>>>>> 'rsid' returned by the RS matches the 'rsid' it is =
expecting.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Agreed. This might work. But should the check be when the =
client
>>>>>>>>>>>> asks for the configuration metadata or when the client asks =
for
>>>>>>>>>>>> tokens?  I think it only needs to happen at config time.
>>>>>>>>>>> What I see here is that the desire is to audience protect =
tokens.
>>>>>>>>>>> To do that, the audience need to be specified everytime a =
token is
>>>>>>>>>>> requested. I really don't the AS to have to manage the =
complex
>>>>>>>>>>> state of which audiences have previously been issued to
>>>>>>>>>>> refresh_tokens and then reconstruct the correct audience for =
a
>>>>>>>>>>> requested downscoped access_token. It's much simpler, since =
the
>>>>>>>>>>> client knows which RS it's going to send the token to, to =
provide
>>>>>>>>>>> that when requesting tokens.
>>>>>>>>>>>=20
>>>>>>>>>>> The complication comes when exchanging the code for the =
tokens, it
>>>>>>>>>>> needs to specify all possible audiences (rsid's) it might =
send the
>>>>>>>>>>> token to based on the requested scopes. There will be a fair
>>>>>>>>>>> amount
>>>>>>>>>>> of complex logic at the AS to ensure the correct behavior. I =
do
>>>>>>>>>>> worry about this complexity.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> We are of course assuming that a hacker needs to use the
>>>>>>>>>>>>>> real AS
>>>>>>>>>>>>>> authorize endpoint to succeed in obtaining an access =
token(it
>>>>>>>>>>>>>> can't be mitm'd). Once the grant is obtained by the =
client, the
>>>>>>>>>>>>>> threat comes when the client uses the grant at a mitm'd =
token
>>>>>>>>>>>>>> endpoint OR an access token at a mitm'd resource =
endpoint.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> So the AS and its config set becomes the trust anchor. =
Binding
>>>>>>>>>>>>>> allows us to extend trust to the RS discovery giving some
>>>>>>>>>>>>>> assurance that a client has a correct set of endpoints
>>>>>>>>>>>>>> including
>>>>>>>>>>>>>> resource.
>>>>>>>>>>>>> Are you recommending that the AS metadata provide a list =
of the
>>>>>>>>>>>>> 'rsid' supported by the AS?
>>>>>>>>>>>> No.  I think that is a bad idea.  Better to use an identity
>>>>>>>>>>>> oracle
>>>>>>>>>>>> function and say, give me the config for rsid=3Dxyz
>>>>>>>>>>> Good :)
>>>>>>>>>>>>=20
>>>>>>>>>>>> That also allows a common AS discovery endpoint to actually =
do
>>>>>>>>>>>> discovery for multiple AS systems.  E.g. to configure a =
client to
>>>>>>>>>>>> a specific AS service designated by the customer paying for =
the
>>>>>>>>>>>> resource service.
>>>>>>>>>>>>=20
>>>>>>>>>>>> IOW. by providing a resource query, the meta-data config
>>>>>>>>>>>> discovery
>>>>>>>>>>>> actually looks more like discovery.  :-)
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> John's solution requires translating aud to res url and =
changes
>>>>>>>>>>>>>> to core oauth. He seems to imply there is a need for =
ongoing
>>>>>>>>>>>>>> validation of resource. I'm not yet convinced that is =
really
>>>>>>>>>>>>>> needed.  Maybe it is needed because the client could be
>>>>>>>>>>>>>> convinced to follow a link embedded in a resource that is
>>>>>>>>>>>>>> somehow not part of the defined audience?
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On Mar 16, 2016, at 08:57, George Fletcher
>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> So, in thinking about all this AS restricting tokens to =
RS and
>>>>>>>>>>>>>>> "discovery" of RS endpoints, etc. I wondered why we =
don't just
>>>>>>>>>>>>>>> leverage RS metadata like we have AS metadata.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> For an AS we require an 'iss' claim to use as an =
identifier of
>>>>>>>>>>>>>>> the AS. We could do the same with RS metadata retrieving =
the
>>>>>>>>>>>>>>> metadata from a .well-known location and including a =
claim of
>>>>>>>>>>>>>>> 'rsid' to use as an identifier of the Resource Server.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> This 'rsid' identifier could then be used for =
registration
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> the AS and presentation by the client when requesting =
tokens.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> This provides a separation between an identifier for a
>>>>>>>>>>>>>>> resource
>>>>>>>>>>>>>>> and the specific endpoints the token will be sent to. A =
client
>>>>>>>>>>>>>>> could "discover" the necessary endpoint on a periodic =
basis
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> use a single identifier with the AS for any of the
>>>>>>>>>>>>>>> endpoints or
>>>>>>>>>>>>>>> scopes supported by the RS. If desired the RS could =
expose the
>>>>>>>>>>>>>>> supported scopes in the RS metadata file.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> George
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>> >OAuth@ietf.org 
>>>>>>>>>>>>>>> >https://www.ietf.org/mailman=
/listinfo/oauth 
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org  >
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth =

>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>> hzandbelt@pingidentity.com  | =
Ping Identity
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>=20
>>=20
>> --=20
>> Hans Zandbelt              | Sr. Technical Architect
>> hzandbelt@pingidentity.com  | Ping =
Identity
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_3AA1A5AA-5816-461A-9178-5FAF1D13FD1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I keep saying that the mixup mitigation draft doesn't require =
discovery.   

    The AS meta-data draft started before the mixup mitigation =
work and is not related, other than that they both use the concept of =
issuer, as do you.

    The mixup doesn=92t require discovery but it arguably makes =
it easier.

    John =
B.



    On Mar 17, 2016, at 2:52 PM, =
Phil Hunt <phil.hunt@oracle.com> wrote:

    Static deployments are a problem for mix-up. =
Agreed.

    I=92m =
objecting to the notion that we don=92t have to worry about discovery =
threats and that we need to do mix-up first.

    Rushing ahead with partial discovery so =
we can address mix-up seems like a *huge* mistake.

    Mix-up depends on a bad insider to a =
large degree.

    =46rom my =
perspective, there are many publishers of software (both open source and =
proprietary) that have their software deployed in 10s of thousands of =
environments in many different scenarios using millions of clients. =
There is a huge discovery problem coming and a correspondingly huge =
threat as we moving away from center-of-universe scenarios like we had =
with Facebook.

    =46rom my =
perspective, bad configuration is a much larger threat.  But maybe =
that=92s just me.

    Given that =
there is significant overlap in the solutions we should talk about =
mitigations for each and work to produce a set of documents that =
addresses all the threats together.

    That is why some of us object to WGLC =
at this time.  We would be publishing drafts that would require =
revision in a few months!

    Phil

    @independentid
    www.independentid.com
    phil.hunt@oracle.com





    On Mar =
17, 2016, at 10:36 AM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

    agreed, I'm not suggesting that the client-to-evil-RS problem =
is addressed, I was objecting to the statement that Phil made about =
static configurations not being a problem; I don't think agreement was =
reached on a client-to-evil-AS solution either

    Hans.

    On 3/17/16 5:31 PM, George =
Fletcher wrote:
    Isn't =
the solution to that attack defined? I was not including that
    attack in the thinking around audience restricted tokens and =
AS / RS
    endpoint "discovery". I think that regardless of =
this current discussion
    the requirement for the AS to =
return issuer and client_id needs to stay
    as does the =
binding of state to code.

    I looked at the =
current email thread to be addressing an additional
    problem =
and that is how to help the client NOT send a token to an evil
    RS. =46rom my understanding this hasn't been addressed. If I =
missed that
    discussion, feel free to point me to the =
thread.

    Thanks,
    George

    On 3/17/16 1:25 PM, Hans Zandbelt wrote:
    a good AS (at first) may =
become compromised and attack another AS;
    whilst I agree =
it is less likely and less easy in static configs
    (hence =
my point about the dynamic scenario) the root cause is not
    related to configuration: it is a runtime attack (well at =
least one of
    the permutations is) on perfectly valid =
configurations

    Hans.

    On 3/17/16 5:16 PM, Justin Richer wrote:
    But it=92s less likely =
(or less easy?) to have a malicious combination
    of =
endpoints in a static configuration. What this all boils down to
    is managing a set of endpoints as a =93thing=94 that =
represents an AS
    (and some would argue associated RS). You =
can create that set
    manually or dynamically and fall prey =
to this attack, but it=92s much
    more likely in the dynamic =
sense. That=92s why this attack was
    propagated against =
OIDC first, where dynamic discovery of server
    information =
is almost expected by client libraries, and clients are
    designed to be used across domains.

     =97 Justin

    On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
    <hzandbelt@pingidentity.com> wrote:

    I'm sorry to keep pushing on this but the attack is not =
opened up by
    discovery, having two fixed ASes is already a =
threat: multiple ASes
    in general leaves the client =
exposed. Discovery just increases the
    attack surface.

    Hans.

    On 3/17/16 =
4:16 PM, Phil Hunt wrote:
    George,

    For the attacks we =
looked at in Darmstadt, we discussed that in order
    for the =
attack to succeed (at least as envisioned), the attacker needs
    to have the client invoke the real authorize endpoint in =
order for the
    user to be successful in issuing the =
grant.

    Assuming that it is the case, the =
attacker can use a proxied token
    endpoint or a proxied =
resource endpoint.  A client that doesn=92t know
    what =
the real endpoint should be could be confused depending on how
    discovery occurs.

    Keep in mind =
that the token endpoint and the resource communications
    happens in the back channel. The user is never going to see =
the URL
    that
    has been invoked.  So=85.we =
need to make sure the set of endpoints are
    bound together =
or  confirmed.

    Note: This hasn=92t =
been a big issue to date because current apps
    tend to
    work with fixed or singleton infrastructure.

    One we expand OAuth out to scenarios where there are multiple =
service
    providers with different relationships with OAuth =
AS=92s, we move into
    this dynamic category that opens the =
threat.

    Phil

    @independentid
    www.independentid.com <http://www.independentid.com>
    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>





    On Mar 17, 2016, at 7:36 =
AM, George Fletcher <gffletch@aol.com
    <mailto:gffletch@aol.com>> wrote:



    On 3/16/16 6:37 PM, John =
Bradley wrote:
    I =
agree with Phil that the client can=92t trust any abstract
    identifier
    that it might get from a bad RS =
unless it is were a URI that the
    client or AS could =
deference to get a list of the concrete URI for
    the RS.
    I guess I'm confused on this front as we are =
asking the client to
    "trust" the AS identifier that is =
being returned by the AS as well as
    the value the client =
gets from discovery if it uses that method to
    obtain the =
AS endpoints.

    I don't understand why the =
same philosophy can't be used for Resource
    Service =
identifier and endpoints.

    That seems like a lot of work that clients are =
unlikely to do.
    If I can discover the RS =
endpoints once and cache them, that doesn't
    seem that =
difficult. This only applies to clients that have some
    support for dynamically accepting RS's and their =
endpoints.

    For clients that only support a =
single AS we are saying they can get
    the AS identifier =
out-of-band and use that. We can easily do the same
    thing =
for an RS identifier. They can either get it out-of-band (i.e.
    hardcoded) or they can get them dynamically (not likely =
initially but
    we shouldn't preclude it).

    A AS =
might do it if it wanted to look up the identifier for a given
    resource.

    Something like do get =
on resource get back Abstract identifier
    (probably well =
known location, as recently pointed out in another
    thread =
you can=92t allow it to point to user content.)
    Yes, you could do it this way, though the client =
still needs to get
    those endpoints and if it's doing it =
dynamically, it will likely use
    the same method to =
discover the endpoints:)

    The AS gets the file and maps the uri to a =
abstract identifier for
    audience.

    I guess that would be one way that you could map AS URI to =
a
    abstract
    identifier, but I wouldn=92t want =
to count on clients doing it.
    This will work =
fine, if the client has hardcoded endpoints.

    My main concern is that I don't want the AS to have to manage =
a
    map of
    endpoint URLs for each RS it's =
supporting.

    Think of an RS that supports =
multiple AS's. If the RS adds a new
    endpoint, that =
endpoint can't go live until each AS receives the
    endpoint =
and adds it to it's map. That is a deployment nightmare. The
    mapping of RS to current endpoints has to dynamic even if =
it's
    done by
    the AS rather than the =
client.

    Wildcard'ing the endpoint URLs or =
only using domains, I don't think
    will work as we've =
proven that open redirect holes break this
    thinking. It =
needs to be an exact match.

    John B.





    On Mar 16, 2016, at 3:46 PM, Phil Hunt <phil.hunt@oracle.com
    <mailto:phil.hunt@oracle.com>> wrote:

    George,

    Thanks. =
It would be good to get a draft that sketches out the
    overall picture of this for BA =97 even if in very rough form =
given
    the deadline is monday.  Or, maybe just a PPT =
walkthru.

    Interested to see what comes =
out.

    Phil

    @independentid
    <http://www.independentid.com/>www.independentid.com
    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>





    On Mar 16, 2016, at =
11:29 AM, George Fletcher
    <<mailto:gffletch@aol.com>gffletch@aol.com> =
wrote:

    Inline...

    On 3/16/16 2:16 PM, Phil Hunt wrote:

    Phil

    @independentid
    <http://www.independentid.com/>www.independentid.com
    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>





    On Mar 16, 2016, at =
10:59 AM, George Fletcher
    <<mailto:gffletch@aol.com>gffletch@aol.com> =
wrote:



    On =
3/16/16 12:20 PM, Phil Hunt (IDM) wrote:
    George

    Very good =
question...

    I considered that the RS =
metadata discovery could be fake.
    Same way =
that the 'iss' claim must "match" the url used to
    retrieve =
the metadata would apply to the 'rsid' claim
    -- I think =
that should suffice to ensuring the 'rsid' identifier
    can't =
be spoofed by another site

    So =
the attacker makes iss and url match for the resource
    discovery. Yet the AS service provider doesn=92t know where =
the
    client is using the tokens.  How would the client =
or the AS
    detect
    that the wrong iss was =
given?
    Because if the attacker makes the rsid =
and the url match, then the
    client will submit an rsid =
that isn't "registered" with the AS and
    the AS won't issue =
the token. This assumes the client is not
    talking to an =
evil AS (as there are other mitigations for that
    case).


    So the final step in configuration validation is to bind =
the
    relationship between as and rs discovery together to =
confirm
    the
    relationship is valid.
    And what I'd like to see is the 'rsid' value =
used to represent
    the RS rather than some unique endpoint =
(even if wildcards are
    allowed)

    Long term, I think this would be =
better. Do we have a way to
    issue
    RSID =
values in the works?
    No, but that is what =
this email thread is contemplating:) Just as
    the AS iss =
value is selfdefined by the AS, the rsid should be
    selfdefined by the RS. Requiring a 'rsid' claim in the RS =
metadata
    is a mirror of how the AS 'iss' claim is defined =
for the AS in
    it's
    metadata.

    That =
said, I would have thought this is more ownerous than
    checking *.example.com <http://example.com/>matches=
 the given URL
    by the client.
    My =
problem with the URL level checking is that a RS may
    legitimately have endpoints on multiple domains. An RS may =
move
    endpoints from one domain to another (say when moving =
from version
    1 to version 2 of an API). Using the rsid for =
audience restriction
    and as an indirect mechanism for =
specifying actual endpoints, the
    RS has a much looser =
coupling with the AS.

    AS we move into =
"federated authorization" meaning that an RS
    outsources =
it's API authorization to one or more AS's, this will
    become=
 more important.

    Another =
step that may be required is for the RS to return it's
    'rsid' in the realm field of the WWW-Authenticate response
    header. This allows a client to discover metadata about the =
RS
    and it's endpoints. It also allows the client to =
determine if
    the
    'rsid' returned by the RS =
matches the 'rsid' it is expecting.

    Agreed. This might work. But should the check be when the =
client
    asks for the configuration metadata or when the =
client asks for
    tokens?  I think it only needs to =
happen at config time.
    What I see here is =
that the desire is to audience protect tokens.
    To do that, =
the audience need to be specified everytime a token is
    requested. I really don't the AS to have to manage the =
complex
    state of which audiences have previously been =
issued to
    refresh_tokens and then reconstruct the correct =
audience for a
    requested downscoped access_token. It's =
much simpler, since the
    client knows which RS it's going =
to send the token to, to provide
    that when requesting =
tokens.

    The complication comes when =
exchanging the code for the tokens, it
    needs to specify =
all possible audiences (rsid's) it might send the
    token to =
based on the requested scopes. There will be a fair
    amount
    of complex logic at the AS to ensure the =
correct behavior. I do
    worry about this complexity.

    We are of =
course assuming that a hacker needs to use the
    real AS
    authorize endpoint to succeed in obtaining an access =
token(it
    can't be mitm'd). Once the grant is obtained by =
the client, the
    threat comes when the client uses the =
grant at a mitm'd token
    endpoint OR an access token at a =
mitm'd resource endpoint.

    So the AS and its =
config set becomes the trust anchor. Binding
    allows us to =
extend trust to the RS discovery giving some
    assurance =
that a client has a correct set of endpoints
    including
    resource.
    Are you recommending =
that the AS metadata provide a list of the
    'rsid' =
supported by the AS?
    No.  I think that =
is a bad idea.  Better to use an identity
    oracle
    function and say, give me the config for rsid=3Dxyz
    Good :)

    That also allows a common AS discovery =
endpoint to actually do
    discovery for multiple AS systems. =
 E.g. to configure a client to
    a specific AS service =
designated by the customer paying for the
    resource =
service.

    IOW. by providing a resource =
query, the meta-data config
    discovery
    actually=
 looks more like discovery.  :-)

    John's solution requires translating aud to res url and =
changes
    to core oauth. He seems to imply there is a need =
for ongoing
    validation of resource. I'm not yet convinced =
that is really
    needed.  Maybe it is needed because =
the client could be
    convinced to follow a link embedded in =
a resource that is
    somehow not part of the defined =
audience?

    Thanks

    Phil

    On Mar 16, 2016, at 08:57, =
George Fletcher
    <gffletch@aol.com> wrote:

    So, in thinking about =
all this AS restricting tokens to RS and
    "discovery" of RS =
endpoints, etc. I wondered why we don't just
    leverage RS =
metadata like we have AS metadata.

    For an =
AS we require an 'iss' claim to use as an identifier of
    the =
AS. We could do the same with RS metadata retrieving the
    metadata from a .well-known location and including a claim =
of
    'rsid' to use as an identifier of the Resource =
Server.

    This 'rsid' identifier could then =
be used for registration
    with
    the AS and =
presentation by the client when requesting tokens.

    This provides a separation between an identifier for a
    resource
    and the specific endpoints the token =
will be sent to. A client
    could "discover" the necessary =
endpoint on a periodic basis
    and
    use a =
single identifier with the AS for any of the
    endpoints =
or
    scopes supported by the RS. If desired the RS could =
expose the
    supported scopes in the RS metadata file.

    Thoughts?

    Thanks,
    George
    _______________________________________________
    OAuth mailing list
    <mailto:OAuth@ietf.org>OAuth@ietf.org
    <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth



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




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


    --
    Hans Zandbelt =
            &n=
bsp;| Sr. Technical Architect
    hzandbelt@pingidentity.com | Ping Identity

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



    -- 
    Hans =
Zandbelt =
            &n=
bsp;| Sr. Technical Architect
    hzandbelt@pingidentity.com | Ping Identity

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

--Apple-Mail=_3AA1A5AA-5816-461A-9178-5FAF1D13FD1B--

--Apple-Mail=_156742AE-B0A2-4C4B-8AEA-2DF731251C06
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTcxODE5NDJaMCMGCSqGSIb3DQEJBDEWBBQK0tStri8tj/5Y7P8OSSOD
fAWLwjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCbpSk9lj5+oqQn9+2X73VoGhM2z2btv/0r9x/rmpeibkkAaECc3VjC
Wn8Hu4hph5YQ/ImAcLyfUy9H1fB6qK6McpFtRW0q/LGbwH00TiQ6uCJSTvaLPbTLN6tnjuGC7yM+
tA0GNyikxzw7WSFy2OWALhJiNo5kcZY7h3CL7QJO8EdtBq43+bdvaho5FcdycHWFGVY3qFmzv/mN
os/sQnmvKFNgcJc3VAq5rGGwLPuoakKRnRk3KW7x+vIM+oCmFPdc/FOwINtGlG3PFu/bC0rt5pgy
GLY/PgMUC/Tt8nZTpbpEx3nkjwiFdF64Z95rOeMA6baZ7+yKlnQY0ApJYK9BAAAAAAAA
--Apple-Mail=_156742AE-B0A2-4C4B-8AEA-2DF731251C06--


From nobody Thu Mar 17 19:56:23 2016
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 CE3B412DE0B for ; Thu, 17 Mar 2016 19:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 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_LOW=-0.7, 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 (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 X3CPxJvJnBIi for ; Thu, 17 Mar 2016 19:56:19 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 DE8D612DAD1 for ; Thu, 17 Mar 2016 19:56:18 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id o6so43979033qkc.2 for ; Thu, 17 Mar 2016 19:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fXQj3yNcqNys19/TrLD+jbi4rhQV/WBlepBUj0wwh2M=; b=lQZCUIc9aKvYtS/Jrl9yRnEC/d4x0OQp5KjBbqTYxQqOdyKLCR9Ism2Tw13slSyW/T ghWKGpeDuBTyuFM7Lx5cnkjVN8wmGwwtJ97rTUYL1zt39r9XxOcZeE1gnSCckhvXLco8 S1IDReh+122ObSJvXTPcbq6p3/tDZ4K/dV7VtjS+QWtx8MbKS7NzQDPsYhfMXUVJS7ZA YB55cjpYyBRcBMoMGcDwfAiH6341xNfRgFF+qLE4Ezlos0PlrkroNUxY4rBygtnWdb0e FdgbMHYIYCrrlVAxCEgzpIIAgWjbS145JGKaaAxHjcLR2Gynp8K2GnDW/EjveK69mAv2 9EBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fXQj3yNcqNys19/TrLD+jbi4rhQV/WBlepBUj0wwh2M=; b=U38kiMmQ4YGLm80LrsAu0viPHKH1crYRNW3T0bbKqMcb+QGR8HzHK0zWe7j2AH4B8u WtFYuWS7WfRIwzhzEIgy25X3SNgBfQ2tJOn/OFLw3OfXPoQ6hBxzTfzqijL01IYg3ucH D/niXLt2ryoPK7nB7PwSg1b3UTTebDAN2eAKPc7yh7m7xbFPSo2f2WR/1rYACR2oXSm0 HpLRzTH03YX/USXW5QYk1G76UnMKsXsIz1AsCPYam/9f4gmPXVXN7tveZsRa2O6Pa9O+ m++C+iOZSkZqkyr1kQfFMiO0/y8ibQkmgJC6Ps+iFHxeFlMPSjr5xbHQEhXlcWXZ4Lvm ru+g==
X-Gm-Message-State: AD7BkJLyojyjC2Y/kQnle35ao5sltsof/qcFwlTeeyEXkRRHJMQLO0p0TkTITk/VSny/4gfHxjN/Kh2ywnFNEA==
X-Received: by 10.55.71.66 with SMTP id u63mr18734677qka.67.1458269777562; Thu, 17 Mar 2016 19:56:17 -0700 (PDT)
MIME-Version: 1.0
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <1471B213-0953-4705-9096-62F16858D6DC@oracle.com> 
In-Reply-To: 
From: Nat Sakimura 
Date: Fri, 18 Mar 2016 02:56:08 +0000
Message-ID: 
To: John Bradley , Phil Hunt 
Content-Type: multipart/alternative; boundary=001a114a79741445de052e49e44f
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 02:56:22 -0000

--001a114a79741445de052e49e44f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We are talking about resource accesses here, right? There's no query
parameter from the point of view of OAuth: the access token is sent as
Authorize header over TLS, so I am a bit puzzled by your comment...

Nat

2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bradley :

> It is not just redirects that are a threat.  Any user hosted content coul=
d
> potentially extract an access token from a query parameter.
>
> John B.
>
> On Mar 17, 2016, at 1:34 PM, Phil Hunt  wrote:
>
> +1 for Nat's last few emails (avoiding generating too much traffic :-).
>
> Re: below, this is where I was thinking of masking/filter in bound
> config.  The main thing that needs to be checked at
> configuration time is whether the client has a valid set of server host
> names to prevent a malicious proxy.
>
> So all the examples you mention below do boil down to https://example.org
> or https://example.com
>
> It=E2=80=99s not that the AS needs to return them. It simply needs to mat=
ch them.
> If one of them matches, then the oauth config can be returned.
>
> I do agree re-directs (of the ESPN scenario) can become an issue if a
> discovery system matches on *.example.com.  It presumes there are no open
> redirect servers in the example.com domain.  As I mention in another
> email, we should discuss what happens when any oauth connection is
> redirected.  Should the client re-validate the configuration?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Mar 16, 2016, at 11:42 PM, Nat Sakimura  wrote:
>
> IMHO, list of URIs that represent the partial paths under the same
> authority would not be too onerous.
>
> e.g., if you have
>
> https://example.com/apis/v1/userinfo
> https://example.com/apis/v2/userinfo
> https://example.org/some/api/endpoint
>
> etc., then the AS may provide
>
> https://example.com/apis/
> https://example.org/
>
> or something like that in the audiences.
>
> A completely new domain should not be trusted blindly.
> The resource should at least make sure to provide the domain as being
> under the same authority.
>
> Bearer Token is a Password. It should not be shared among different
> authorities.
>
> Best,
>
> Nat
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O=
n
> Behalf Of *George Fletcher
> *Sent:* Wednesday, March 16, 2016 3:15 AM
> *To:* John Bradley ; Brian Campbell <
> bcampbell@pingidentity.com>
> *Cc:*  
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-bound-config-00.txt
>
>
> (..snip..)
>
> I'm not sure passing the full endpoint to the AS will help with my
> concerns... The AS could potentially do a webfinger on the resource URI a=
nd
> determine if it's an RS that it supports... though that requires all RS's
> to support webfinger. What I really want to avoid is the AS having this
> list of URIs to RS that is almost assuredly to get out of sync.
>
> (..snip..)
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender  and delete this e-mail.
>
> _______________________________________________
> 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
>

--001a114a79741445de052e49e44f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    We are talking about resource accesses =
here, right? There's no query parameter from the point of view of OAuth=
: the access token is sent as Authorize header over TLS, so I am a bit puzz=
led by your comment...

    Nat  

    2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bradl=
ey <ve7jtb@ve7jtb.com>:
    <=
/div>
    It =
is not just redirects that are a threat.=C2=A0 Any user hosted content coul=
d potentially extract an access token from a query parameter.

    John B.

    =

    On Mar 17, 2016, at 1:34 PM, Phil Hunt <<=
a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c=
om> wrote:

    +1 for =
Nat's last few emails (avoiding generating too much traffic :-).
    Re: below, this is where I was thinking of masking/filter in b=
ound config.=C2=A0 The main thing that needs to be checked at=C2=A0
    configuration time is whether the client has a valid set of server host =
names to prevent a malicious proxy.

    So all the exa=
mples you mention below do boil down to https://example.org or https://example.com

    It=E2=
=80=99s not that the AS needs to return them. It simply needs to match them=
. If one of them matches, then the oauth config can be returned.
    =

    I do agree re-directs (of the ESPN scenario) can become an i=
ssue if a discovery system matches on *.example.com.=C2=A0 It presumes there are no open redirec=
t servers in the example.=
com domain.=C2=A0 As I mention in another email, we should discuss what=
 happens when any oauth connection is redirected.=C2=A0 Should the client r=
e-validate the configuration?

    

    <=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">




    

    

    On Mar 16, 2016, at 11:42 PM, Nat S=
akimura <n-sak=
imura@nri.co.jp> wrote:

    <=
div style=3D"margin:0mm 0mm 0.0001pt;font-size:12pt;font-family:'\00ff2=
d\00ff33  \00ff30\0030b4\0030b7\0030c3\0030af'">IMHO, list of URIs that rep=
resent the partial paths under the same authority would not be too onerous.=
=C2=A0
    =C2=A0
    e.g., if you have=C2=A0
    =C2=A0
    <=
div style=3D"margin:0mm 0mm 0.0001pt;font-size:12pt;font-family:'\00ff2=
d\00ff33  \00ff30\0030b4\0030b7\0030c3\0030af'">=C2=A0
    etc., then the AS may provide=C2=A0
    =C2=A0
    https=
://example.com/apis/
    =C2=A0
    or something like that in the au=
diences.=C2=A0
    =C2=A0
    A completely new domain should not be trusted blindly.=C2=
=A0
    The resource should at least make sure =
to provide the domain as being under the same authority.=C2=A0=

    =C2=A0
    Bearer Token is a=
 Password. It should not be shared among different authorities.=C2=A0=

    =C2=A0
    Best,=C2=A0
    =C2=A0
    Nat=

    =C2=A0
    From:=
=C2=A0OAuth [mailto:oauth-bounces@=
ietf.org]=C2=A0On Behalf Of=C2=A0Georg=
e Fletcher
    Sent:=C2=A0Wednesday, March 16, 2016 3:15=
 AM
    To:=C2=A0John Bradley <ve7jtb@ve7jtb.com>; Brian Campbell <bcampbell@pingidentity.com>
    Cc:=C2=
=A0<oauth@ietf.org> <oauth@ietf.org>
    Subject:=C2=A0Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-conf=
ig-00.txt
    =C2=A0<=
/div>
    (..snip..)=C2=A0
    I'm not sure passing the full=
 endpoint to the AS will help with my concerns... The AS could potentially =
do a webfinger on the resource URI and determine if it's an RS that it =
supports... though that requires all RS's to support webfinger. What I =
really want to avoid is the AS having this list of URIs to RS that is almos=
t assuredly to get out of sync.

    (..sn=
ip..)
    --
    <=
span lang=3D"EN-US" style=3D"font-size:10pt;font-family:'\00ff2d\00ff33=
  \0030b4\0030b7\0030c3\0030af';color:rgb(31,73,125)">PLEASE READ :This=
 e-mail is confidential and intended for the
    named recipient only. If you are not an in=
tended recipient,
    please notify the sender=C2=A0 and delete this e-mail.<=
/span>
    =C2=A0
    __________________________________=
_____________
    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
    


--001a114a79741445de052e49e44f--


From nobody Fri Mar 18 00:09:54 2016
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 73F1312DB87 for ; Fri, 18 Mar 2016 00:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 iydL274BDKFT for ; Fri, 18 Mar 2016 00:09:50 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 455E712D773 for ; Fri, 18 Mar 2016 00:09:50 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id d82so12267866lfe.3 for ; Fri, 18 Mar 2016 00:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=BW29MbRgezE8E4D25ViWrYsYhI2H5qDzP/1n5y8xdiA=; b=KkS5yT2hclwZjBmBAOvtKaGh54Pcv1QMvtHJyomcEOYSfTjw4jOHpJhSS87mUsQfO+ oJAXOUii0UHxvpMju9gULEBU9Pjv0FRMetqhRRZjFTIFEV9mpWJTdGTAuEDWzb81qg8m Av2QxkS5C3zbj1jrOG0OfINHSfMJZLfh1QPm8GJboG7veS7+S3N/vjgP+uGHEhcKTOFx Tq64B4V9JEzWiY2Gu5GOufNXVrY4urybjEkT5wibXRgqhSPtrfUc4B9fG7B/56QtzN5m 3xw+bITIHUvWZfZIEYj1mZiYV7Ql+J/MpzCZPj4wFLhbJ1PKuk12C475Y1khEo/KzsBP 5XJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BW29MbRgezE8E4D25ViWrYsYhI2H5qDzP/1n5y8xdiA=; b=Zj/jzP/r1GS7xrPhnYKSMjIZNzunEWkvuFQvr58tUcO66OyCOjQnCGJiuj06xCdmcD ytGrVhtwl8C9WzNrRpqq0QglnV3lT1fqYPCdHA0AK0sCTKf4Ym0+JoWdSxUpkC1/MYlq xaoXveS/k4G0NaImYueFW+E7xI03f+4i2couWNJEtx2Bq17qHhaHxcz26bAUrI8uXCvC ClOfdzqnOp1BAWHHAlkldV/rz9zeNW5B7PEP6wJzS7s32gfmPu1p2JcdzIAk3PcL/ra0 DkWG4dbC23csjk+pWLb4MXYZlYnyNA97L7bgpqEZffwQHZk8KbBGrev9sRvxfBhMbm5i QdDg==
X-Gm-Message-State: AD7BkJL3fZsS/rzSPu7FQj99HaYXACNRSBFj5t6s8cNZC3E80k1HvrsZWhWNi4xBPxfm3kX6CMLAzB6mU+neyw==
X-Received: by 10.25.43.20 with SMTP id r20mr5233175lfr.30.1458284988336; Fri, 18 Mar 2016 00:09:48 -0700 (PDT)
MIME-Version: 1.0
References: <56EAEB54.8010208@aol.com>
In-Reply-To: <56EAEB54.8010208@aol.com>
From: Thomas Broyer 
Date: Fri, 18 Mar 2016 07:09:38 +0000
Message-ID: 
To: George Fletcher , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114116bcb61030052e4d6e92
Archived-At: 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 07:09:53 -0000

--001a114116bcb61030052e4d6e92
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Note that goal #2 is already taken care of by introspection (endpoint
varying response depending on authenticated client/RS), so maybe should be
refined here.

Le jeu. 17 mars 2016 18:44, George Fletcher  a =C3=A9crit=
 :

> Goals:
>
> 1. Help the client not send a token to the "wrong" endpoint
>     a. wrong AS /token endpoint
>     b. evil RS endpoint(s)
> 2. Allow good RS to determine if the token being validated was intended
> for that RS
>
> Other high-level goals?
>
> Use cases:
>
> 1. RS that supports multiple AS (we've had this in production since 2011)
> 2. RS rejects token not issued for use at the RS
> 3. Client that dynamically supports new RS (say any client that supports
> the jabber API)
> 4. Client that dynamically supports new AS
>
> Feel free to add to the list :)
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a114116bcb61030052e4d6e92
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Note that goal #2 is already taken care of by introspection =
(endpoint varying response depending on authenticated client/RS), so maybe =
should be refined here.
    

    Le jeu. 17 mars 2016 18:44,=
 George Fletcher <gffletch@aol.com> a =C3=A9crit=C2=A0:
    Goals:

    
1. Help the client not send a token to the "wrong" endpoint
    
=C2=A0 =C2=A0 a. wrong AS /token endpoint
    
=C2=A0 =C2=A0 b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended
    
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since 201=
1)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

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

    

--001a114116bcb61030052e4d6e92--


From nobody Fri Mar 18 02:56:56 2016
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 9288212D7C5 for ; Fri, 18 Mar 2016 02:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 8MKoJI3xoep3 for ; Fri, 18 Mar 2016 02:56:44 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 57C3512D681 for ; Fri, 18 Mar 2016 02:56:44 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id h129so132582184ywb.1 for ; Fri, 18 Mar 2016 02:56:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RG1AOKsk2MkZnGBBw3G0t/RogR5lkKa0EM+ZoblULHw=; b=ebJ4i3bIsgMA+zBR8lWv8hF/4OX5BajYnnppZbxXnhJ2U6Flo+E5BcqbsJ45Ze0O05 TbQP7qi1wsD/pATuQZWzJTPcL4Cr5h1gW1vzZGNQ8Hl2nvMQf41sxyn7xo5MUJzCce1l MWbyqXKs1qHFUa63NauyGgry9kNRtY8jtzRCrtRqM5lQ8pLfgALYIkgoKeMIZxl70Ba3 jLjXvbeqOIa/wjZnkMueRaW+Htv/gNHgv9NWWki7yWL5VC8L5uMNp/TqNSxQtDnd4bxm dHBdM3HuzrfvHLGPo0JhMwOv5L71h3C0mZvWdLMLqfECtOSdin9ohzwrNI3bE0U1AlNz Idbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RG1AOKsk2MkZnGBBw3G0t/RogR5lkKa0EM+ZoblULHw=; b=TPCVn+ggTfhxqKrqLZNVVowAMEiVk/QBjt8ElFe+N8m9fHzZApR3n306jN5BH4r4aM JAlcAxKVy78j7BefotVzx/LBk4uW8krg02+qmJIZv6l0JE2Llm3RVrYkoGM6EG137wa9 UnuTyzoaXyOb3cWDmFI8+CHRsPLE8esOjWECWqs/KbsO4HgH4YZgz5O2AjK6owuRc599 yY/T9JHtSCzzk4g4qGG7gz9BEkaVR+Uh1RoW9MEWllIrJ3TsS/JHw3VLJKLg76xfbaU7 u3jd6EF1J9USqcPg+u7F2LEPYykLHnLjNtg8DKny4R4mCbscy6xXFUk/HiiheUflALPu tBLQ==
X-Gm-Message-State: AD7BkJL2OfNkCb4Kdkyo1PKTDZRnvatVVai6PNV281aauWr/PLsicXxMNvVAJa6n1qmIO0mImw/Jpw2m1HseUA==
MIME-Version: 1.0
X-Received: by 10.37.76.3 with SMTP id z3mr6150877yba.165.1458295003399; Fri, 18 Mar 2016 02:56:43 -0700 (PDT)
Received: by 10.37.214.130 with HTTP; Fri, 18 Mar 2016 02:56:43 -0700 (PDT)
Received: by 10.37.214.130 with HTTP; Fri, 18 Mar 2016 02:56:43 -0700 (PDT)
In-Reply-To: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>  
Date: Fri, 18 Mar 2016 06:56:43 -0300
Message-ID: 
From: John Bradley 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=001a113e6b66a7fa54052e4fc326
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 09:56:54 -0000

--001a113e6b66a7fa54052e4fc326
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

RFC 6750 Sec 2.3.

I wish clients used the header,   the reality is that the majority of
client developers use a query paramater because it is easy.

Form encoding is also allowed.

If the RS has user hosted content the web server may helpfully make the
headder available anyway to the web page.

Query is the worst.  In those cases the token will leak if someone gets at
the HTTP logs.

This is one of the reasons a specific audiance in the token is important to
limit the loss if a RS is compromised.

John B.
On Mar 17, 2016 11:56 PM, "Nat Sakimura"  wrote:

> We are talking about resource accesses here, right? There's no query
> parameter from the point of view of OAuth: the access token is sent as
> Authorize header over TLS, so I am a bit puzzled by your comment...
>
> Nat
>
> 2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bradley :
>
>> It is not just redirects that are a threat.  Any user hosted content
>> could potentially extract an access token from a query parameter.
>>
>> John B.
>>
>> On Mar 17, 2016, at 1:34 PM, Phil Hunt  wrote:
>>
>> +1 for Nat's last few emails (avoiding generating too much traffic :-).
>>
>> Re: below, this is where I was thinking of masking/filter in bound
>> config.  The main thing that needs to be checked at
>> configuration time is whether the client has a valid set of server host
>> names to prevent a malicious proxy.
>>
>> So all the examples you mention below do boil down to https://example.or=
g
>> or https://example.com
>>
>> It=E2=80=99s not that the AS needs to return them. It simply needs to ma=
tch them.
>> If one of them matches, then the oauth config can be returned.
>>
>> I do agree re-directs (of the ESPN scenario) can become an issue if a
>> discovery system matches on *.example.com.  It presumes there are no
>> open redirect servers in the example.com domain.  As I mention in
>> another email, we should discuss what happens when any oauth connection =
is
>> redirected.  Should the client re-validate the configuration?
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>
>>
>>
>>
>>
>> On Mar 16, 2016, at 11:42 PM, Nat Sakimura  wrote:
>>
>> IMHO, list of URIs that represent the partial paths under the same
>> authority would not be too onerous.
>>
>> e.g., if you have
>>
>> https://example.com/apis/v1/userinfo
>> https://example.com/apis/v2/userinfo
>> https://example.org/some/api/endpoint
>>
>> etc., then the AS may provide
>>
>> https://example.com/apis/
>> https://example.org/
>>
>> or something like that in the audiences.
>>
>> A completely new domain should not be trusted blindly.
>> The resource should at least make sure to provide the domain as being
>> under the same authority.
>>
>> Bearer Token is a Password. It should not be shared among different
>> authorities.
>>
>> Best,
>>
>> Nat
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *=
On
>> Behalf Of *George Fletcher
>> *Sent:* Wednesday, March 16, 2016 3:15 AM
>> *To:* John Bradley ; Brian Campbell <
>> bcampbell@pingidentity.com>
>> *Cc:*  
>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-bound-config-00.txt
>>
>>
>> (..snip..)
>>
>> I'm not sure passing the full endpoint to the AS will help with my
>> concerns... The AS could potentially do a webfinger on the resource URI =
and
>> determine if it's an RS that it supports... though that requires all RS'=
s
>> to support webfinger. What I really want to avoid is the AS having this
>> list of URIs to RS that is almost assuredly to get out of sync.
>>
>> (..snip..)
>> --
>> PLEASE READ :This e-mail is confidential and intended for the
>> named recipient only. If you are not an intended recipient,
>> please notify the sender  and delete this e-mail.
>>
>> _______________________________________________
>> 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
>>
>

--001a113e6b66a7fa54052e4fc326
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    RFC 6750 Sec 2.3.=C2=A0 
    

    I wish clients used the header,=C2=A0=C2=A0 the reality is t=
hat the majority of client developers use a query paramater because it is e=
asy.=C2=A0 
    

    Form encoding is also allowed.=C2=A0 
    

    If the RS has user hosted content the web server may helpful=
ly make the headder available anyway to the web page.=C2=A0 
    

    Query is the worst.=C2=A0 In those cases the token will leak=
 if someone gets at the HTTP logs. 
    

    This is one of the reasons a specific audiance in the token =
is important to limit the loss if a RS is compromised.=C2=A0=C2=A0 
    

    John B. 
    

    On Mar 17, 2016 11:56 PM, "Nat Sakimura&quo=
t; <sakimura@gmail.com> wro=
te:
    We are talking about resource accesses here, right? The=
re's no query parameter from the point of view of OAuth: the access tok=
en is sent as Authorize header over TLS, so I am a bit puzzled by your comm=
ent...

    Nat  

    20=
16=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bradley <ve7jtb@ve7jtb.com>:<=
br>
    It is not just redirects that are a threat.=C2=A0 Any user hosted content =
could potentially extract an access token from a query parameter.

    <=
/div>
    John B.

    <=
div>
    On Mar 17, 2016, at 1:34 PM, Phil Hunt &=
lt;phil.hunt@orac=
le.com> wrote:

    +1 =
for Nat's last few emails (avoiding generating too much traffic :-).
    Re: below, this is where I was thinking of masking/filter =
in bound config.=C2=A0 The main thing that needs to be checked at=C2=A0
    configuration time is whether the client has a valid set of server h=
ost names to prevent a malicious proxy.

    So all the=
 examples you mention below do boil down to https://example.org or https://example.com

    It=
=E2=80=99s not that the AS needs to return them. It simply needs to match t=
hem. If one of them matches, then the oauth config can be returned.

    I do agree re-directs (of the ESPN scenario) can become a=
n issue if a discovery system matches on *.example.com.=C2=A0 It presumes there are no open redi=
rect servers in the examp=
le.com domain.=C2=A0 As I mention in another email, we should discuss w=
hat happens when any oauth connection is redirected.=C2=A0 Should the clien=
t re-validate the configuration?

    

    <=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">




    

    

    On Mar 16, 2016, at 11:42 PM, Nat S=
akimura <n-sak=
imura@nri.co.jp> wrote:

    <=
div style=3D"margin:0mm 0mm 0.0001pt;font-size:12pt;font-family:'\00ff2=
d\00ff33  \00ff30\0030b4\0030b7\0030c3\0030af'">IMHO,=
 list of URIs that represent the partial paths under the same authority wou=
ld not be too onerous.=C2=A0
    <=
/u>=C2=A0
    e.g., if you have=C2=A0<=
/u>
    =C2=A0
    =C2=A0
    etc., then the AS may provi=
de=C2=A0
    =C2=A0<=
/div>
    =C2=A0
    or something li=
ke that in the audiences.=C2=A0
    =C2=A0
    A completely new domain should not be trusted bl=
indly.=C2=A0
    The resource should at l=
east make sure to provide the domain as being under the same authority.=C2=A0
    =C2=A0
    <=
div style=3D"margin:0mm 0mm 0.0001pt;font-size:12pt;font-family:'\00ff2=
d\00ff33  \00ff30\0030b4\0030b7\0030c3\0030af'">Be=
arer Token is a Password. It should not be shared among different authoriti=
es.=C2=A0
    =C2=A0=

    Best,=C2=A0
    =C2=A0=

    Nat
    =C2=A0
    <=
div>
    From:=C2=A0OAuth [mailto=
:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0<=
/span>George Fletcher
    Sent:=C2=A0Wednesday, Marc=
h 16, 2016 3:15 AM
    To:=C2=A0John Bradley <ve7jtb@ve7jtb.com>; Brian Campbell <bcampbell@pingidentity.com>
    Cc:=
=C2=A0<oauth@ietf.org>=
 <oauth@ietf.org>
    Subject:=C2=A0    Re: [OAUTH-WG] New Version Notification for draft-hunt-oaut=
h-bound-config-00.txt
    =C2=A0=

    (..snip..)=C2=A0
    I'm not sure pass=
ing the full endpoint to the AS will help with my concerns... The AS could =
potentially do a webfinger on the resource URI and determine if it's an=
 RS that it supports... though that requires all RS's to support webfin=
ger. What I really want to avoid is the AS having this list of URIs to RS t=
hat is almost assuredly to get out of sync.

    (..snip..)
    PLEASE =
READ :This e-mail is confidential and intended for the=

    named recipient only. If you are=
 not an intended recipient,
    please notify the sender=C2=A0 and delete this e-mail.
    =
=C2=A0
    ________________________=
_______________________
    OAuth mailing list<=
br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var=
iant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgrou=
nd-color:rgb(255,255,255)">OAuth@ie=
tf.org
    https://www.ietf.org/mailman/listinfo/oauth


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



--001a113e6b66a7fa54052e4fc326--


From nobody Fri Mar 18 03:08:49 2016
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 5EE6212D700 for ; Fri, 18 Mar 2016 03:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 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_LOW=-0.7, 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 (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 BO9f_TKbnVch for ; Fri, 18 Mar 2016 03:08:42 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 7E40412D6A6 for ; Fri, 18 Mar 2016 03:08:42 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id w104so95349344qge.1 for ; Fri, 18 Mar 2016 03:08:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHXS6M/CxZTZd8BJiVyuhbXT9a+Z1G7USPDPyTys7vc=; b=tef4/rBpWXWjO3eXe2OLyKhaHXTrisizxGwHnRBGnzsOO2oNUW7E+iQVCjSj4C360J 1+AxWmDfL8I9dTtyZLb/JRb2ycut9cZ9AoUmr29T9WkpXYDMtwHOxnhQp2vl+nWojYJ+ XMC6jdKq23Wcm/rx9hrx7zQBFJGmN6kanKEEL/yB2RBKIZchN4qlGSUUCkBUZMlp1lGq IBGt2Rh0uihNjkQmsSesDydvw0T/UYz8iQovLcvSOsWrqEVD35G2Vo4amEB7aqQg1WP+ 03sfIspgFqEb/J3h6tevkz9tRGOfYP6s10pLJjMFXNTaid588ybU9rHq6Yr48szuQT3k 0qFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHXS6M/CxZTZd8BJiVyuhbXT9a+Z1G7USPDPyTys7vc=; b=JE/x/umDQYuAymYPKvolZ1QM1Mz3EADXDwPrtATzWC24w+/yXdm68vWIyfsMVEyJ3a LSUweuOoDm55LB7O3a6UMdhRoDYdRLn8M2lySAjjMJUhJ4/zMZvmjvx0YlvuLr6XXMDt 1ymIOhjVyf8J4I4zRBJzKiLJ4gRa7gz0L0n+CObWxa1TZ5PGDNpSxSMQFHSqSogRCB7q FT3E0OSdbzIUvnHFRF6YRSwp3L5wd9KMC/DiBXMqHd2YJVQhRu7WFuvhhidGoi3mmdCD rXITY2z9CBRKOb2lw5PqWV3Z7w5Z5r68yanhgQp3ckaXyt+6vVzMDXZkfAIrZBvko/m9 T95Q==
X-Gm-Message-State: AD7BkJJGCORvAVSiV/bMRkpQLqcssnucH79znjNnLuiB7XfpXbGQlf3VoiODiwVobMI7kpIrk8NFGR8yR8PCng==
X-Received: by 10.140.225.6 with SMTP id v6mr21984943qhb.0.1458295721438; Fri, 18 Mar 2016 03:08:41 -0700 (PDT)
MIME-Version: 1.0
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>   
In-Reply-To: 
From: Nat Sakimura 
Date: Fri, 18 Mar 2016 10:08:31 +0000
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a1138f428743522052e4fee8e
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 10:08:47 -0000

--001a1138f428743522052e4fee8e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2.3 should be removed from RFC6750. There is no reason to do it now. When
we started the work, there was a lot of feature phones with no capability
to do header, but it has been 6 years now and they have largely
disappeared.

2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 18:56 John Bradley :

> RFC 6750 Sec 2.3.
>
> I wish clients used the header,   the reality is that the majority of
> client developers use a query paramater because it is easy.
>
> Form encoding is also allowed.
>
> If the RS has user hosted content the web server may helpfully make the
> headder available anyway to the web page.
>
> Query is the worst.  In those cases the token will leak if someone gets a=
t
> the HTTP logs.
>
> This is one of the reasons a specific audiance in the token is important
> to limit the loss if a RS is compromised.
>
> John B.
> On Mar 17, 2016 11:56 PM, "Nat Sakimura"  wrote:
>
>> We are talking about resource accesses here, right? There's no query
>> parameter from the point of view of OAuth: the access token is sent as
>> Authorize header over TLS, so I am a bit puzzled by your comment...
>>
>> Nat
>>
>> 2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bradley :
>>
>>> It is not just redirects that are a threat.  Any user hosted content
>>> could potentially extract an access token from a query parameter.
>>>
>>> John B.
>>>
>>> On Mar 17, 2016, at 1:34 PM, Phil Hunt  wrote:
>>>
>>> +1 for Nat's last few emails (avoiding generating too much traffic :-).
>>>
>>> Re: below, this is where I was thinking of masking/filter in bound
>>> config.  The main thing that needs to be checked at
>>> configuration time is whether the client has a valid set of server host
>>> names to prevent a malicious proxy.
>>>
>>> So all the examples you mention below do boil down to
>>> https://example.org or https://example.com
>>>
>>> It=E2=80=99s not that the AS needs to return them. It simply needs to m=
atch
>>> them. If one of them matches, then the oauth config can be returned.
>>>
>>> I do agree re-directs (of the ESPN scenario) can become an issue if a
>>> discovery system matches on *.example.com.  It presumes there are no
>>> open redirect servers in the example.com domain.  As I mention in
>>> another email, we should discuss what happens when any oauth connection=
 is
>>> redirected.  Should the client re-validate the configuration?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>
>>>
>>>
>>>
>>> On Mar 16, 2016, at 11:42 PM, Nat Sakimura  wrote=
:
>>>
>>> IMHO, list of URIs that represent the partial paths under the same
>>> authority would not be too onerous.
>>>
>>> e.g., if you have
>>>
>>> https://example.com/apis/v1/userinfo
>>> https://example.com/apis/v2/userinfo
>>> https://example.org/some/api/endpoint
>>>
>>> etc., then the AS may provide
>>>
>>> https://example.com/apis/
>>> https://example.org/
>>>
>>> or something like that in the audiences.
>>>
>>> A completely new domain should not be trusted blindly.
>>> The resource should at least make sure to provide the domain as being
>>> under the same authority.
>>>
>>> Bearer Token is a Password. It should not be shared among different
>>> authorities.
>>>
>>> Best,
>>>
>>> Nat
>>>
>>> *From:* OAuth [mailto:oauth-bounces@ietf.org ] =
*On
>>> Behalf Of *George Fletcher
>>> *Sent:* Wednesday, March 16, 2016 3:15 AM
>>> *To:* John Bradley ; Brian Campbell <
>>> bcampbell@pingidentity.com>
>>> *Cc:*  
>>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>>> draft-hunt-oauth-bound-config-00.txt
>>>
>>>
>>> (..snip..)
>>>
>>> I'm not sure passing the full endpoint to the AS will help with my
>>> concerns... The AS could potentially do a webfinger on the resource URI=
 and
>>> determine if it's an RS that it supports... though that requires all RS=
's
>>> to support webfinger. What I really want to avoid is the AS having this
>>> list of URIs to RS that is almost assuredly to get out of sync.
>>>
>>> (..snip..)
>>> --
>>> PLEASE READ :This e-mail is confidential and intended for the
>>> named recipient only. If you are not an intended recipient,
>>> please notify the sender  and delete this e-mail.
>>>
>>> _______________________________________________
>>> 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
>>>
>>

--001a1138f428743522052e4fee8e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    2.3 should be removed from RFC6750. There is no reason to =
do it now. When we started the work, there was a lot of feature phones with=
 no capability to do header, but it has been 6 years now and they have larg=
ely disappeared.=C2=A0

    2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 18:56 John Bradley <ve7jtb@ve7jtb.com>:
    RFC 6750 Sec 2.3.=C2=A0 
    

    I wish clients used the header,=C2=A0=C2=A0 the reality is t=
hat the majority of client developers use a query paramater because it is e=
asy.=C2=A0 
    

    Form encoding is also allowed.=C2=A0 
    

    If the RS has user hosted content the web server may helpful=
ly make the headder available anyway to the web page.=C2=A0 
    

    Query is the worst.=C2=A0 In those cases the token will leak=
 if someone gets at the HTTP logs. 
    

    This is one of the reasons a specific audiance in the token =
is important to limit the loss if a RS is compromised.=C2=A0=C2=A0 
    

    John B. 
    

    On Mar 17, 2016 11:56 PM, "Nat Sakimura&quo=
t; <sakimura@gma=
il.com> wrote:
    We are talking about resource accesse=
s here, right? There's no query parameter from the point of view of OAu=
th: the access token is sent as Authorize header over TLS, so I am a bit pu=
zzled by your comment...

    Nat  

    <=
div dir=3D"ltr">2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bra=
dley <ve7jtb@ve7j=
tb.com>:
    It is not just redirects that are a threat.=C2=A0 Any user=
 hosted content could potentially extract an access token from a query para=
meter.

    John B.

    On Mar 17, 2016, at 1:34=
 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    +1 for Nat's last few emails (avoiding generating too much=
 traffic :-).

    Re: below, this is where I was thinking of=
 masking/filter in bound config.=C2=A0 The main thing that needs to be chec=
ked at=C2=A0
    configuration time is whether the client has a valid=
 set of server host names to prevent a malicious proxy.

    So all the examples you mention below do boil down to https://example.org or https://example.com
    It=E2=80=99s not that the AS needs to return them. It simply n=
eeds to match them. If one of them matches, then the oauth config can be re=
turned.

    I do agree re-directs (of the ESPN scenari=
o) can become an issue if a discovery system matches on *.example.com.=C2=A0 It presumes there a=
re no open redirect servers in the example.com domain.=C2=A0 As I mention in another email, we=
 should discuss what happens when any oauth connection is redirected.=C2=A0=
 Should the client re-validate the configuration?

    

    <=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">




    

    

    On Mar 16, 2016, at 11:42 PM, Nat S=
akimura <n-sak=
imura@nri.co.jp> wrote:

    <=
div style=3D"margin:0mm 0mm 0.0001pt;font-size:12pt;font-family:'\00ff2=
d\00ff33  \00ff30\0030b4\0030b7\0030c3\0030af'">IMHO, list of URIs that represent the partial paths under =
the same authority would not be too onerous.=C2=A0
    =C2=A0
    e.g., if you have=
=C2=A0
    =C2=A0
    https://example.com/apis/v1/userinfo
    https://example.co=
m/apis/v2/userinfo
    =C2=A0
    =

    e=
tc., then the AS may provide=C2=A0
    <=
div style=3D"margin:0mm 0mm 0.0001pt;font-size:12pt;font-family:'\00ff2=
d\00ff33  \00ff30\0030b4\0030b7\0030c3\0030af'">    =C2=A0
    =C2=A0<=
/span>
    or something like that in the audiences.=C2=A0
    =
=C2=A0
    A completely new domai=
n should not be trusted blindly.=C2=A0
    The resource should at least make sure to provide the domain as being und=
er the same authority.=C2=A0
    =
=C2=A0
    Bearer Token is a Password. It should not be share=
d among different authorities.=C2=A0
    =
=C2=A0
    Best,=C2=A0
    =C2=A0
    Nat
    =C2=A0
    From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org]=C2=A0=
On Behalf Of=C2=A0George Fletcher
    Sent:=
=C2=A0Wednesday, March 16, 2016 3:15 AM
    To:=C2=A0John Bradley <ve7jtb@ve7jtb.com>=
; Brian Campbell <bcampbell@pingid=
entity.com>
    Cc:=C2=A0<oauth@ietf.org> <oauth@ietf.org>
    Subject:=C2=A0Re: [OAUTH-WG] New Version Noti=
fication for draft-hunt-oauth-bound-config-00.txt
    (..snip..)=C2=A0
    I'm not sure passing the full endpoint to the AS will help wit=
h my concerns... The AS could potentially do a webfinger on the resource UR=
I and determine if it's an RS that it supports... though that requires =
all RS's to support webfinger. What I really want to avoid is the AS ha=
ving this list of URIs to RS that is almost assuredly to get out of sync.
    =

    (..snip..)
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    <=
a href=3D"https://www.ietf.org/mailman/listinfo/oauth" style=3D"color:purpl=
e;text-decoration:underline;font-family:Helvetica;font-size:12px;font-style=
:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;background-color:rgb(255,255,255)" target=3D"_blank">https://www.ie=
tf.org/mailman/listinfo/oauth


    _______=
________________________________________
    
OAuth mailing list
    
OAuth@ietf.org
    
https://www.ietf.org/mailman/listinfo/oauth
    

    



--001a1138f428743522052e4fee8e--


From nobody Fri Mar 18 04:07:40 2016
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 A634C12D51B for ; Fri, 18 Mar 2016 04:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.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 1UVU8PFv5LLK for ; Fri, 18 Mar 2016 04:07:36 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 E18E112D6D0 for ; Fri, 18 Mar 2016 04:07:35 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id g3so134420681ywa.3 for ; Fri, 18 Mar 2016 04:07:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=IJKpxDnLG2vOcYcbdcwSabk+kFPXyna8WdYYUad9SS8=; b=gcUrUYtRSjtR3fbJXG80iR9MW6r2J8xGJ5s09NaItXN8qE8sJlKnoVU6duvNYHign3 XOxAijpEeAxuFvVIdqx7bS7WlU4HJ0Nd76jBTkxGeWBLviXY66sjQur62nEatrjNMce/ 5+zop6z/F3nT0AlqzrRquKlw43eJWhmPXJhQIzZq2HLNiL2onRTE7XnqONk3dOp8YuZ5 3VztN4V0d36iBbRKpYyxVceJlKZA4gvHHoxY/FD/g+jN1ibTLrcGh0WRwYSVC5XvyQ9h yg//3xr/Ua8EcLTQPe/cm80b8xE8k+yyFdP5jrg3PP9iedl4+PEX1IZ5t71urt45Jrxs 0ENA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IJKpxDnLG2vOcYcbdcwSabk+kFPXyna8WdYYUad9SS8=; b=JbTeJlsac4DAHWVTgXi8msHeYQ4uClcaj23Gc8dLALj7bbwh3hkzi/iqeDbVB0/tKt Fr9X/xN+65Y2AU9/jGYbmNke3ATsId87UzHuEXdr0/1ottiZcpAqYKlPWpiT3U5eS6cw WtbCdZyLzn8tXc/lwKfU0zvRE5M25yYxVH6gIDa+o3HKFRhByPtUiLvimmJ4f9tucUwg HrDHuCsiU/nq6UPyUjzK7zutXaNsVRlCe3+Oel1OIEHytsWGsa9R3SfzL1nUJXRGi5HE zjoWtyMvo4O+2WY2Hss52ZotrZ6/ZboAhwcmuKJBNzMhmRzczzhCfE9omaGVmWLSndKK +YSw==
X-Gm-Message-State: AD7BkJLu2PAGUkuizsIWYojc4APs9drfcw404e51AhCB7qrcN2X7+37nGdqbV3WcuYpAKdT40T2MSnwEWqLPcA==
MIME-Version: 1.0
X-Received: by 10.13.214.1 with SMTP id y1mr6321651ywd.307.1458299254885; Fri, 18 Mar 2016 04:07:34 -0700 (PDT)
Received: by 10.37.214.130 with HTTP; Fri, 18 Mar 2016 04:07:34 -0700 (PDT)
Received: by 10.37.214.130 with HTTP; Fri, 18 Mar 2016 04:07:34 -0700 (PDT)
In-Reply-To: 
References: <20160313225337.1648.22870.idtracker@ietfa.amsl.com>  <2A77FB9B-A455-4AB3-A3BC-0596E29C6174@ve7jtb.com>   <1EC7A886-B3A3-472E-887C-9C9D3A2DFA4F@ve7jtb.com>  <6BDC23EA-F098-4449-9322-98A3FC197701@ve7jtb.com> <169679A3-A288-4444-AE81-1E4619DA6B1C@mit.edu> <56E7494F.906@pingidentity.com> <56E825B9.6090400@aol.com> <1AB1046F-B097-4AFE-A499-804515C6EC75@ve7jtb.com>  <5CF88900-DF39-4FC8-AC12-D1FDC0C6C3D2@ve7jtb.com>   <56E85111.9030308@aol.com> <009a01d18018$33bfe700$9b3fb500$@nri.co.jp> <1471B213-0953-4705-9096-62F16858D6DC@oracle.com>    
Date: Fri, 18 Mar 2016 08:07:34 -0300
Message-ID: 
From: John Bradley 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=94eb2c0770e410a53c052e50c191
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 11:07:38 -0000

--94eb2c0770e410a53c052e50c191
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree,  but getting that horse back in the barn is not going to be an
overnight project.

We have multiple issues with bearrer tokens.  At the moment we punt the
issue to the client and count on it being configured properly to not leak
the AT.

Better tokens will never be as secure as PoP tokens ,   we can apply
various bandages to bearrer,  but the developers will as at what cost.

John B.
On Mar 18, 2016 7:08 AM, "Nat Sakimura"  wrote:

> 2.3 should be removed from RFC6750. There is no reason to do it now. When
> we started the work, there was a lot of feature phones with no capability
> to do header, but it has been 6 years now and they have largely
> disappeared.
>
> 2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 18:56 John Bradley :
>
>> RFC 6750 Sec 2.3.
>>
>> I wish clients used the header,   the reality is that the majority of
>> client developers use a query paramater because it is easy.
>>
>> Form encoding is also allowed.
>>
>> If the RS has user hosted content the web server may helpfully make the
>> headder available anyway to the web page.
>>
>> Query is the worst.  In those cases the token will leak if someone gets
>> at the HTTP logs.
>>
>> This is one of the reasons a specific audiance in the token is important
>> to limit the loss if a RS is compromised.
>>
>> John B.
>> On Mar 17, 2016 11:56 PM, "Nat Sakimura"  wrote:
>>
>>> We are talking about resource accesses here, right? There's no query
>>> parameter from the point of view of OAuth: the access token is sent as
>>> Authorize header over TLS, so I am a bit puzzled by your comment...
>>>
>>> Nat
>>>
>>> 2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bradley :
>>>
>>>> It is not just redirects that are a threat.  Any user hosted content
>>>> could potentially extract an access token from a query parameter.
>>>>
>>>> John B.
>>>>
>>>> On Mar 17, 2016, at 1:34 PM, Phil Hunt  wrote:
>>>>
>>>> +1 for Nat's last few emails (avoiding generating too much traffic :-)=
.
>>>>
>>>> Re: below, this is where I was thinking of masking/filter in bound
>>>> config.  The main thing that needs to be checked at
>>>> configuration time is whether the client has a valid set of server hos=
t
>>>> names to prevent a malicious proxy.
>>>>
>>>> So all the examples you mention below do boil down to
>>>> https://example.org or https://example.com
>>>>
>>>> It=E2=80=99s not that the AS needs to return them. It simply needs to =
match
>>>> them. If one of them matches, then the oauth config can be returned.
>>>>
>>>> I do agree re-directs (of the ESPN scenario) can become an issue if a
>>>> discovery system matches on *.example.com.  It presumes there are no
>>>> open redirect servers in the example.com domain.  As I mention in
>>>> another email, we should discuss what happens when any oauth connectio=
n is
>>>> redirected.  Should the client re-validate the configuration?
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 16, 2016, at 11:42 PM, Nat Sakimura 
>>>> wrote:
>>>>
>>>> IMHO, list of URIs that represent the partial paths under the same
>>>> authority would not be too onerous.
>>>>
>>>> e.g., if you have
>>>>
>>>> https://example.com/apis/v1/userinfo
>>>> https://example.com/apis/v2/userinfo
>>>> https://example.org/some/api/endpoint
>>>>
>>>> etc., then the AS may provide
>>>>
>>>> https://example.com/apis/
>>>> https://example.org/
>>>>
>>>> or something like that in the audiences.
>>>>
>>>> A completely new domain should not be trusted blindly.
>>>> The resource should at least make sure to provide the domain as being
>>>> under the same authority.
>>>>
>>>> Bearer Token is a Password. It should not be shared among different
>>>> authorities.
>>>>
>>>> Best,
>>>>
>>>> Nat
>>>>
>>>> *From:* OAuth [mailto:oauth-bounces@ietf.org ]=
 *On
>>>> Behalf Of *George Fletcher
>>>> *Sent:* Wednesday, March 16, 2016 3:15 AM
>>>> *To:* John Bradley ; Brian Campbell <
>>>> bcampbell@pingidentity.com>
>>>> *Cc:*  
>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>>>> draft-hunt-oauth-bound-config-00.txt
>>>>
>>>>
>>>> (..snip..)
>>>>
>>>> I'm not sure passing the full endpoint to the AS will help with my
>>>> concerns... The AS could potentially do a webfinger on the resource UR=
I and
>>>> determine if it's an RS that it supports... though that requires all R=
S's
>>>> to support webfinger. What I really want to avoid is the AS having thi=
s
>>>> list of URIs to RS that is almost assuredly to get out of sync.
>>>>
>>>> (..snip..)
>>>> --
>>>> PLEASE READ :This e-mail is confidential and intended for the
>>>> named recipient only. If you are not an intended recipient,
>>>> please notify the sender  and delete this e-mail.
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>

--94eb2c0770e410a53c052e50c191
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I agree,=C2=A0 but getting that horse back in the barn is no=
t going to be an overnight project.=C2=A0 
    

    We have multiple issues with bearrer tokens.=C2=A0 At the mo=
ment we punt the issue to the client and count on it being configured prope=
rly to not leak the AT.=C2=A0 
    

    Better tokens will never be as secure as PoP tokens ,=C2=A0=
=C2=A0 we can apply various bandages to bearrer,=C2=A0 but the developers w=
ill as at what cost. 
    

    John B. 
    

    On Mar 18, 2016 7:08 AM, "Nat Sakimura"=
; <sakimura@gmail.com> wrot=
e:
    =
2.3 should be removed from RFC6750. There is no reason to do it now. When w=
e started the work, there was a lot of feature phones with no capability to=
 do header, but it has been 6 years now and they have largely disappeared.=
=C2=A0

    2016=E5=B9=B43=
=E6=9C=8818=E6=97=A5(=E9=87=91) 18:56 John Bradley <ve7jtb@ve7jtb.com>:
    RFC 6750 Sec 2.3.=C2=A0 
    

    I wish clients used the header,=C2=A0=C2=A0 the reality is t=
hat the majority of client developers use a query paramater because it is e=
asy.=C2=A0 
    

    Form encoding is also allowed.=C2=A0 
    

    If the RS has user hosted content the web server may helpful=
ly make the headder available anyway to the web page.=C2=A0 
    

    Query is the worst.=C2=A0 In those cases the token will leak=
 if someone gets at the HTTP logs. 
    

    This is one of the reasons a specific audiance in the token =
is important to limit the loss if a RS is compromised.=C2=A0=C2=A0 
    

    John B. 
    

    On Mar 17, 2016 11:56 PM, "Nat Sakimura&quo=
t; <sakimura@gma=
il.com> wrote:
    We are talking about resource accesse=
s here, right? There's no query parameter from the point of view of OAu=
th: the access token is sent as Authorize header over TLS, so I am a bit pu=
zzled by your comment...

    Nat  

    <=
div dir=3D"ltr">2016=E5=B9=B43=E6=9C=8818=E6=97=A5(=E9=87=91) 2:49 John Bra=
dley <ve7jtb@ve7j=
tb.com>:
    It is not just redirects that are a threat.=C2=A0 Any user=
 hosted content could potentially extract an access token from a query para=
meter.

    John B.

    On Mar 17, 2016, at 1:34=
 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    +1 for Nat's last few emails (avoiding generating too much=
 traffic :-).

    Re: below, this is where I was thinking of=
 masking/filter in bound config.=C2=A0 The main thing that needs to be chec=
ked at=C2=A0
    configuration time is whether the client has a valid=
 set of server host names to prevent a malicious proxy.

    So all the examples you mention below do boil down to https://example.org or https://example.com
    It=E2=80=99s not that the AS needs to return them. It simply n=
eeds to match them. If one of them matches, then the oauth config can be re=
turned.

    I do agree re-directs (of the ESPN scenari=
o) can become an issue if a discovery system matches on *.example.com.=C2=A0 It presumes there a=
re no open redirect servers in the example.com domain.=C2=A0 As I mention in another email, we=
 should discuss what happens when any oauth connection is redirected.=C2=A0=
 Should the client re-validate the configuration?

    

    <=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">




    

    

    On Mar 16, 2016, at 11:42 PM, Nat S=
akimura <n-sak=
imura@nri.co.jp> wrote:

    <=
div style=3D"margin:0mm 0mm 0.0001pt;font-size:12pt;font-family:'\00ff2=
d\00ff33  \00ff30\0030b4\0030b7\0030c3\0030af'">IMHO, list of URIs that represent the =
partial paths under the same authority would not be too onerous.=C2=
=A0
    =C2=A0
    e.g=
., if you have=C2=A0
    =C2=A0=

    =C2=
=A0
    etc., then the AS may provide=C2=A0
    =
=C2=A0
    <=
span lang=3D"EN-US" style=3D"font-size:10pt;font-family:Arial,sans-serif">h=
ttps://example.org/
    =C2=A0
    or something like that in the audiences.<=
span>=C2=A0
    =C2=A0
    A completely new domain should not be trusted blindly.=C2=A0<=
u>
    The resource should at least make sure to provide =
the domain as being under the same authority.=C2=A0<=
/u>
    =C2=A0
    Bearer Token is a Password. =
It should not be shared among different authorities.=C2=A0<=
/u>
    =C2=A0
    Best,=C2=A0
    =C2=A0
    Nat<=
/u>
    =C2=A0
    =
From:=C2=A0OAuth [mailto:oauth-bounces@ietf.org=
]=C2=A0On Behalf Of=C2=A0George FletcherSent:=C2=A0Wednesday, March 16, 2016 3:15 AM
    To=
:=C2=A0John Bradley <ve7jt=
b@ve7jtb.com>; Brian Campbell <bcampbell@pingidentity.com>
    Cc:=C2=A0<=
oauth@ietf.org> <oauth@ietf.org>
    Subject:=C2=A0Re: [OAUTH-=
WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt
    =C2=A0
    (..sni=
p..)=C2=A0
    I'm not sure passing the full endpoint to =
the AS will help with my concerns... The AS could potentially do a webfinge=
r on the resource URI and determine if it's an RS that it supports... t=
hough that requires all RS's to support webfinger. What I really want t=
o avoid is the AS having this list of URIs to RS that is almost assuredly t=
o get out of sync.

    (..snip..)=

    --=

    PLEASE READ :This e-mail is conf=
idential and intended for the
    named recipient only. If you are not an intended recipien=
t,
    please no=
tify the sender=C2=A0 and delete this e-mail.
    <=
/u>=C2=A0
    _______________________________________________
    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
    





--94eb2c0770e410a53c052e50c191--


From nobody Fri Mar 18 05:50:52 2016
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 7FB3E12D570 for ; Fri, 18 Mar 2016 05:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 Jki42-EaPEHD for ; Fri, 18 Mar 2016 05:50:48 -0700 (PDT)
Received: from omr-a005e.mx.aol.com (omr-a005e.mx.aol.com [204.29.186.50]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D565F12D556 for ; Fri, 18 Mar 2016 05:50:47 -0700 (PDT)
Received: from mtaout-aac02.mx.aol.com (mtaout-aac02.mx.aol.com [172.27.2.34]) by omr-a005e.mx.aol.com (Outbound Mail Relay) with ESMTP id 00736380004E; Fri, 18 Mar 2016 08:50:47 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aac02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C49C63800008F; Fri, 18 Mar 2016 08:50:46 -0400 (EDT)
To: Thomas Broyer , "oauth@ietf.org" 
References: <56EAEB54.8010208@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EBF9A8.8070909@aol.com>
Date: Fri, 18 Mar 2016 08:50:48 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030006020300010308010204"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458305446; bh=6p1UF6rBWxrCLfyiB3eJ9UabgoY+/Jk5VxHuzbhiQ94=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=0q1jQzXRSPYBXzFDXTb+h0f3eaf8+dV7scp7PIywygkVyc01dqBN4uQbyekVXJo21 Q6Ph3DJdKMeNiPJM4AAq8T+ugbTKo1O3wfVsEivR4h61Epsb/WBH9GrC1XDbNOJVyg CkY/i8ks+eQQeWyO1RJCsvml4n24M9uKaJnwKal4=
x-aol-sid: 3039ac1b022256ebf9a6417d
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 12:50:50 -0000

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

I was thinking of goal #2 as addressing the issue of audience in the 
token. If the RS "authenticates" itself when calling introspection, then 
the AS could apply the audience restriction for the RS. Is that what you 
were thinking?

On 3/18/16 3:09 AM, Thomas Broyer wrote:
>
> Note that goal #2 is already taken care of by introspection (endpoint 
> varying response depending on authenticated client/RS), so maybe 
> should be refined here.
>
>
> Le jeu. 17 mars 2016 18:44, George Fletcher  > a écrit :
>
>     Goals:
>
>     1. Help the client not send a token to the "wrong" endpoint
>         a. wrong AS /token endpoint
>         b. evil RS endpoint(s)
>     2. Allow good RS to determine if the token being validated was
>     intended
>     for that RS
>
>     Other high-level goals?
>
>     Use cases:
>
>     1. RS that supports multiple AS (we've had this in production
>     since 2011)
>     2. RS rejects token not issued for use at the RS
>     3. Client that dynamically supports new RS (say any client that
>     supports
>     the jabber API)
>     4. Client that dynamically supports new AS
>
>     Feel free to add to the list :)
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>


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


  
    
  
  
    I was thinking of goal #2
      as addressing the issue of audience in the token. If the RS
      "authenticates" itself when calling introspection, then the AS
      could apply the audience restriction for the RS. Is that what you
      were thinking?
    
    
    
    
    On 3/18/16 3:09 AM, Thomas Broyer
      wrote:
    
    
    
    
    
      
    Note that goal #2 is already taken care of by
        introspection (endpoint varying response depending on
        authenticated client/RS), so maybe should be refined here.
    
      
    
      
    
        
    Le jeu. 17 mars 2016 18:44, George Fletcher <gffletch@aol.com>
          a écrit :
    
        
    
        
    Goals:
    
          
    
          1. Help the client not send a token to the "wrong" endpoint
    
              a. wrong AS /token endpoint
    
              b. evil RS endpoint(s)
    
          2. Allow good RS to determine if the token being validated was
          intended
    
          for that RS
    
          
    
          Other high-level goals?
    
          
    
          Use cases:
    
          
    
          1. RS that supports multiple AS (we've had this in production
          since 2011)
    
          2. RS rejects token not issued for use at the RS
    
          3. Client that dynamically supports new RS (say any client
          that supports
    
          the jabber API)
    
          4. Client that dynamically supports new AS
    
          
    
          Feel free to add to the list :)
    
          
    
          _______________________________________________
    
          OAuth mailing list
    
          OAuth@ietf.org
    
          https://www.ietf.org/mailman/listinfo/oauth
    
        
    
      
    
    
    
    
    
  


--------------030006020300010308010204--


From nobody Fri Mar 18 06:00:21 2016
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 944F512D525 for ; Fri, 18 Mar 2016 06:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 YfZyBzBG-PWb for ; Fri, 18 Mar 2016 06:00:18 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 69C1D12D51E for ; Fri, 18 Mar 2016 06:00:18 -0700 (PDT)
X-AuditID: 12074425-d93ff70000007cc8-27-56ebfbe1ad96
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id F2.10.31944.1EBFBE65; Fri, 18 Mar 2016 09:00:17 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u2ID0GII014380; Fri, 18 Mar 2016 09:00:16 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2ID0DrR025239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 Mar 2016 09:00:15 -0400
To: George Fletcher , Thomas Broyer , "oauth@ietf.org" 
References: <56EAEB54.8010208@aol.com>  <56EBF9A8.8070909@aol.com>
From: Justin Richer 
Message-ID: <56EBFBD4.6060502@mit.edu>
Date: Fri, 18 Mar 2016 09:00:04 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56EBF9A8.8070909@aol.com>
Content-Type: multipart/alternative; boundary="------------090500010200020206020002"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hRV1n34+3WYwbJpAhZ3ulawW5x8+4rN 4vi/i8wOzB73d69k99g56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mva31xSc0a3Y2HCWrYFx vWIXIyeHhICJxPLHTSxdjFwcQgJtTBJ7rrSxQTgbGSXWT37CDuHcZpI42X6ODaRFWCBKYubK zywgtohAmcTuhYeYIYq6GCU+dh1iB0mwCahKTF/TwgRi8wqoSfzfuYsVxGYBiu9cvRCsRlQg RuL4u3OMEDWCEidnPgEbyimgLvHgdAtYPbNAmMT0S88YJzDyzUJSNgtJCsK2lbgzdzczhC0v 0bx1NpStK7Fo2wp2ZPEFjGyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxgsKa 3UV1B+Ocv16HGAU4GJV4eF9UvQ4TYk0sK67MPcQoycGkJMpb+g0oxJeUn1KZkVicEV9UmpNa fIhRgoNZSYT39Q+gHG9KYmVValE+TEqag0VJnJeRgYFBSCA9sSQ1OzW1ILUIJivDwaEkwTvj F1CjYFFqempFWmZOCUKaiYMTZDgP0HBtkBre4oLE3OLMdIj8KUZdjn3r7qxlEmLJy89LlRLn nQBSJABSlFGaBzcHlI4S3h42fcUoDvSWMO9lkCoeYCqDm/QKaAkT0JJjca9AlpQkIqSkGhil Ji5eOHu+p9jbzWKalk+VK65MEHdfu/PS+R0f4vQ2atftalwfwcoqfEFvjVLQyX1bT3fc29e7 VuPAoQDrLXy3ZZryFissOdy7RSPjV0jHq7DCbS8UONaqBPaa8YZvv2Y5bbHuobNvpCJTe7cv XXYq2vhIvLReziLvio+nShbwVQrcvvDfLLtZiaU4I9FQi7moOBEARqtvjCIDAAA=
Archived-At: 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 13:00:20 -0000

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

I'm with George. You can do introspection with no audience restriction. 
We implemented introspection with only scope restriction from the RS.

  -- Justin

On 3/18/2016 8:50 AM, George Fletcher wrote:
> I was thinking of goal #2 as addressing the issue of audience in the 
> token. If the RS "authenticates" itself when calling introspection, 
> then the AS could apply the audience restriction for the RS. Is that 
> what you were thinking?
>
> On 3/18/16 3:09 AM, Thomas Broyer wrote:
>>
>> Note that goal #2 is already taken care of by introspection (endpoint 
>> varying response depending on authenticated client/RS), so maybe 
>> should be refined here.
>>
>>
>> Le jeu. 17 mars 2016 18:44, George Fletcher  a écrit :
>>
>>     Goals:
>>
>>     1. Help the client not send a token to the "wrong" endpoint
>>         a. wrong AS /token endpoint
>>         b. evil RS endpoint(s)
>>     2. Allow good RS to determine if the token being validated was
>>     intended
>>     for that RS
>>
>>     Other high-level goals?
>>
>>     Use cases:
>>
>>     1. RS that supports multiple AS (we've had this in production
>>     since 2011)
>>     2. RS rejects token not issued for use at the RS
>>     3. Client that dynamically supports new RS (say any client that
>>     supports
>>     the jabber API)
>>     4. Client that dynamically supports new AS
>>
>>     Feel free to add to the list :)
>>
>>     _______________________________________________
>>     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


--------------090500010200020206020002
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    I'm with George. You can do introspection with no audience
    restriction. We implemented introspection with only scope
    restriction from the RS.
    
    
    
     -- Justin
    
    
    
    
    On 3/18/2016 8:50 AM, George Fletcher
      wrote:
    
    
    
    
    
      
      I was thinking of goal
        #2 as addressing the issue of audience in the token. If the RS
        "authenticates" itself when calling introspection, then the AS
        could apply the audience restriction for the RS. Is that what
        you were thinking?
    
      
    
      
    On 3/18/16 3:09 AM, Thomas Broyer
        wrote:
    
      
    
      
    
        
    Note that goal #2 is already taken care of by
          introspection (endpoint varying response depending on
          authenticated client/RS), so maybe should be refined here.
    
        
    
        
    
          
    Le jeu. 17 mars 2016 18:44, George Fletcher
            <gffletch@aol.com> a
            écrit :
    
          
    
          
    Goals:
    
            
    
            1. Help the client not send a token to the "wrong" endpoint
    
                a. wrong AS /token endpoint
    
                b. evil RS endpoint(s)
    
            2. Allow good RS to determine if the token being validated
            was intended
    
            for that RS
    
            
    
            Other high-level goals?
    
            
    
            Use cases:
    
            
    
            1. RS that supports multiple AS (we've had this in
            production since 2011)
    
            2. RS rejects token not issued for use at the RS
    
            3. Client that dynamically supports new RS (say any client
            that supports
    
            the jabber API)
    
            4. Client that dynamically supports new AS
    
            
    
            Feel free to add to the list :)
    
            
    
            _______________________________________________
    
            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

    
    
    
    
    
  


--------------090500010200020206020002--


From nobody Fri Mar 18 07:01:39 2016
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 56D6212D973 for ; Fri, 18 Mar 2016 07:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 mE5SsQq-U-RE for ; Fri, 18 Mar 2016 07:01:31 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 3DEFB12D762 for ; Fri, 18 Mar 2016 06:59:24 -0700 (PDT)
Received: by mail-lb0-x230.google.com with SMTP id k12so88951660lbb.1 for ; Fri, 18 Mar 2016 06:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=ciimnGFl8r0WwFKXbC2TpAsU+lwMnV0j6/ZyLStik88=; b=kl/xy4DJh64r8MBgCWlIY0IeesDtmn1w0+mXltnYl6rnqjiLIczthiCzCn/xvIxwoT q/+0VmNhyH2avBnvcN3Q28YPhRKslHcs30yvDtoX/Owi5/HYx5vCge0DvSNBadPJXk96 TCSL+3bVEkL36ucGgRxVxD6xVjDAfD/1erOSO4fv8UXkB21Xbawon0eEKPpCBjRIi3tx LTlZ/nnDfovux1vWvKe/bj9GaIZtyl7WMyWBGVXC/loE3Mi99U2SAlBzk0F9guAr1sHg DNcgXq1fZtl5TXbKGEmb81MDnQuVT1LrsIuHY93Vs+2Lz+LfvJH8wkH6xRA6bMuQxIJT Cl4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ciimnGFl8r0WwFKXbC2TpAsU+lwMnV0j6/ZyLStik88=; b=JIz5q882mLjxrQSGFczMCUtKKlaZ2+tfVNh19drip2THszxxa7jn1VHuvTq3hDJ9hN 6l539+gNNjHnKWv61gHs+X6si286DUNmxb2Y0GHvrzELInK9kkAqZJLY5aWcIYVIn8h0 euJuCABXaG1cpf2bEY27UICLWYblflvNiu5TC7QsxZUJv+c6Usek98Njq4u66O5xgZe4 D0r+1jDo9oTz3W3fjsBHiqoz9LGLvKF/KBU82pI45KDBCzrnNxAl7ckzZuLnCl78910w UvlxUxb4xnSVgSS3uCY2XLcecKX8GL6pRz/4xbusGjk9IYc6Ybmn24GkEKsysWpWw+Oy 53Sw==
X-Gm-Message-State: AD7BkJJMn8YKv2Ts2JFAb2F95mQ9EYWPbCI/H/bvypWYii5jstI5LEAVMJyOaLFrH/5qFczUHlyHQV1J1YUPJg==
X-Received: by 10.112.211.168 with SMTP id nd8mr5834874lbc.116.1458309562497;  Fri, 18 Mar 2016 06:59:22 -0700 (PDT)
MIME-Version: 1.0
References: <56EAEB54.8010208@aol.com>  <56EBF9A8.8070909@aol.com>
In-Reply-To: <56EBF9A8.8070909@aol.com>
From: Thomas Broyer 
Date: Fri, 18 Mar 2016 13:59:12 +0000
Message-ID: 
To: George Fletcher , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3bc4e720395052e5327ae
Archived-At: 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 14:01:37 -0000

--001a11c3bc4e720395052e5327ae
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 18, 2016 at 1:50 PM George Fletcher  wrote:

> I was thinking of goal #2 as addressing the issue of audience in the
> token. If the RS "authenticates" itself when calling introspection, then
> the AS could apply the audience restriction for the RS. Is that what you
> were thinking?
>

Yes (or I think so).
Scopes are declared in relation to "applications" (which can be either
clients or RS), and our introspection endpoint returns {"active":false} if
there's no matching scopes between what the "application" has declared and
those of the token.
We actually do "scope restriction" (only returning the scopes related to
the requesting application), with the added rule that if there's no scope
left we return {"active":false} rather than an empty list of scopes.

--001a11c3bc4e720395052e5327ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




    On Fri=
, Mar 18, 2016 at 1:50 PM George Fletcher <gffletch@aol.com> wrote:
    
 =20
   =20
 =20
  
    
    I was thinking of goal #2
      as addressing the issue of audience in the token. If the RS
      "authenticates" itself when calling introspection, then the=
 AS
      could apply the audience restriction for the RS. Is that what you
      were thinking?

    Yes (or I=
 think so).
    Scopes are declared in relation to "applications=
" (which can be either clients or RS), and our introspection endpoint =
returns {"active":false} if there's no matching scopes betwee=
n what the "application" has declared and those of the token.
    We actually do "scope restriction" (only returning the sco=
pes related to the requesting application), with the added rule that if the=
re's no scope left we return {"active":false} rather than an =
empty list of scopes.
    

--001a11c3bc4e720395052e5327ae--


From nobody Fri Mar 18 07:14:42 2016
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 4A90412D5C9 for ; Fri, 18 Mar 2016 07:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.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 YEkrIR6xXG3x for ; Fri, 18 Mar 2016 07:14:37 -0700 (PDT)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85FA12D582 for ; Fri, 18 Mar 2016 07:14:35 -0700 (PDT)
Received: from mtaout-aam02.mx.aol.com (mtaout-aam02.mx.aol.com [172.27.19.146]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id EECCE3800262; Fri, 18 Mar 2016 10:14:34 -0400 (EDT)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aam02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7A56838000086; Fri, 18 Mar 2016 10:14:34 -0400 (EDT)
To: Thomas Broyer , "oauth@ietf.org" 
References: <56EAEB54.8010208@aol.com>  <56EBF9A8.8070909@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56EC0D4A.2060309@aol.com>
Date: Fri, 18 Mar 2016 10:14:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060108010709060107020509"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1458310474; bh=krsKgp36adLx2iZnLpTCrr/5L1OFiGc2aArsrwP8TDQ=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=sqSXkdDt04CUR/2fUF6BObnqUV0SUBE5GWWseP0wo499sgszU+rzJIDJOkNOSSHAK PGYi25BGbHEJHLYKE3qNMs11J9LkdqLP6gawDyuG5VZO42I8pY4I6m2UurNzhDisJF P1XZS6ssU4lEgBgpTyMEgqnNCmaVg71TMoXl/n5s=
x-aol-sid: 3039ac1b139256ec0d4a091c
X-AOL-IP: 10.172.102.179
Archived-At: 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 14:14:40 -0000

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

This is pretty much what we do today as well.  The additional goal is to 
specifically bind tokes to a particular resource outside the context of 
the scope value. Just like in SAML, the RS would not process any token 
which was not specifically created for use with that RS. So it's an 
additional layer of protection beyond scopes.

Thanks,
George

On 3/18/16 9:59 AM, Thomas Broyer wrote:
>
>
> On Fri, Mar 18, 2016 at 1:50 PM George Fletcher  > wrote:
>
>     I was thinking of goal #2 as addressing the issue of audience in
>     the token. If the RS "authenticates" itself when calling
>     introspection, then the AS could apply the audience restriction
>     for the RS. Is that what you were thinking?
>
>
> Yes (or I think so).
> Scopes are declared in relation to "applications" (which can be either 
> clients or RS), and our introspection endpoint returns 
> {"active":false} if there's no matching scopes between what the 
> "application" has declared and those of the token.
> We actually do "scope restriction" (only returning the scopes related 
> to the requesting application), with the added rule that if there's no 
> scope left we return {"active":false} rather than an empty list of scopes.


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


  
    
  
  
    This is pretty much what
      we do today as well.  The additional goal is to specifically bind
      tokes to a particular resource outside the context of the scope
      value. Just like in SAML, the RS would not process any token which
      was not specifically created for use with that RS. So it's an additional
      layer of protection beyond scopes.
    
      
    
      Thanks,
    
      George
    
    
    
    
    On 3/18/16 9:59 AM, Thomas Broyer
      wrote:
    
    
    
    
    
      

    
        
    
        
    
          
    On Fri, Mar 18, 2016 at 1:50 PM George Fletcher
            <gffletch@aol.com>
            wrote:
    
          
    
          
    
            
     I was thinking of
                goal #2 as addressing the issue of audience in the
                token. If the RS "authenticates" itself when calling
                introspection, then the AS could apply the audience
                restriction for the RS. Is that what you were thinking?
    
          
    
          

    
          
    
          
    Yes (or I think so).
    
          
    Scopes are declared in relation to "applications" (which
            can be either clients or RS), and our introspection endpoint
            returns {"active":false} if there's no matching scopes
            between what the "application" has declared and those of the
            token.
    
          
    We actually do "scope restriction" (only returning the
            scopes related to the requesting application), with the
            added rule that if there's no scope left we return
            {"active":false} rather than an empty list of scopes.
    
        
    
      
    
    
    
    
    
  


--------------060108010709060107020509--


From nobody Fri Mar 18 15:05:10 2016
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 A835712D684 for ; Fri, 18 Mar 2016 15:05: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, HTML_MESSAGE=0.001, 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 DYto-vkqDmPU for ; Fri, 18 Mar 2016 15:05:06 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 9273F12D5BE for ; Fri, 18 Mar 2016 15:05:06 -0700 (PDT)
Received: by mail-ig0-x229.google.com with SMTP id av4so48649873igc.1 for ; Fri, 18 Mar 2016 15:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vge5+OoHz4pZtCJetlqzs4epDVA6tzP5x/krTAbMqE4=; b=AV+AWjAr94/lpunlahKT4tquFCiVtqmF0CraBcHRGnGRkpypBv7zve9c05hKIx94hq u7IrXdOIrfQcFeL7Bcn1EKsnqtIm/i64oLE3vSRdHzBLCVLMx4rbQVDrPeoFwIjwKzbK 8Ei6fm6YiAnMnKEpHluNcLd7hJLz+p6GCBlPs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vge5+OoHz4pZtCJetlqzs4epDVA6tzP5x/krTAbMqE4=; b=ZraQFSnqb75n1aRqkmmhttJ8IT9IVDBArVBoVN5kzqo8W5dXgSVYZoFlkf6wK0G5ze G8FbrE1ezQBdLhjyt4ctGTiPejE+j9Iq9zyKl4E2qZCbGRLFisTokjCWeLNK5MhvHtB+ 1TntaORwxqQfYLJHFP1tJRXwTbvoKpi7TkrciK+lhe0vx5yjIyPk2YWrg5aRAcfNU3Wx mcjP4qGJwXK0oQqrnKkhdl8iyUyhbC5x7op6xPDV+dUW8X2jcMAf7/qk/RL8y/27F0Vu stCSIsG3M1+641eePeyaVX0l8JHYW7mMMBwmrp3Vv7uUPqK1zCZDNGtJvIeWBmjmZzq+ 7HqA==
X-Gm-Message-State: AD7BkJLnzntJwu6NDQXtL9piK4U95Y7ajOFukXN+//JxEhoUEwMm5b2WmWwn7SEDvJPdEKXegm9FVdmYZlbbBcO3
X-Received: by 10.50.32.70 with SMTP id g6mr1634854igi.57.1458338705725; Fri, 18 Mar 2016 15:05:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 18 Mar 2016 15:04:36 -0700 (PDT)
In-Reply-To: <56EAEB54.8010208@aol.com>
References: <56EAEB54.8010208@aol.com>
From: Brian Campbell 
Date: Fri, 18 Mar 2016 16:04:36 -0600
Message-ID: 
To: George Fletcher 
Content-Type: multipart/alternative; boundary=047d7b10ca55847b45052e59f064
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 22:05:09 -0000

--047d7b10ca55847b45052e59f064
Content-Type: text/plain; charset=UTF-8

The "a. wrong AS /token endpoint" is the mix-up issue, which can be
mitigated by returning an identifier for the AS in the authorization
response. It is something that needs to be addressed but "discovery" or
metadata aren't needed and audience restricted access tokens tokens don't
help.

Maybe that's obvious but there seems to be a lot of confusion on all this
so I wanted to reiterate it.

On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher  wrote:

> Goals:
>
> 1. Help the client not send a token to the "wrong" endpoint
>    a. wrong AS /token endpoint
>    b. evil RS endpoint(s)
> 2. Allow good RS to determine if the token being validated was intended
> for that RS
>
> Other high-level goals?
>
> Use cases:
>
> 1. RS that supports multiple AS (we've had this in production since 2011)
> 2. RS rejects token not issued for use at the RS
> 3. Client that dynamically supports new RS (say any client that supports
> the jabber API)
> 4. Client that dynamically supports new AS
>
> Feel free to add to the list :)
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--047d7b10ca55847b45052e59f064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    The "a. wrong AS /token endpoint" is the mi=
x-up issue, which can be mitigated by returning an identifier for the AS in=
 the authorization response. It is something that needs to be addressed but=
 "discovery" or metadata aren't needed and audience restricted access t=
okens tokens don't help.

    Maybe that's obvious but ther=
e seems to be a lot of confusion on all this so I wanted to reiterate it.

    On Thu, M=
ar 17, 2016 at 11:37 AM, George Fletcher <gffletch@aol.com> w=
rote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    
=C2=A0 =C2=A0a. wrong AS /token endpoint
    
=C2=A0 =C2=A0b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended for=
 that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since 201=
1)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports th=
e jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

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


    

--047d7b10ca55847b45052e59f064--


From nobody Fri Mar 18 15:28:00 2016
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 A5C7B12D6F0 for ; Fri, 18 Mar 2016 15:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 LZccwjpIBowB for ; Fri, 18 Mar 2016 15:27:56 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 63A3E12D7DF for ; Fri, 18 Mar 2016 15:27:56 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2IMRrfd021517 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Mar 2016 22:27:54 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2IMRrQs031257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2016 22:27:53 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2IMRrUn008305; Fri, 18 Mar 2016 22:27:53 GMT
Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Mar 2016 15:27:53 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-BBBC7E54-8DF6-41A8-AB02-DB4DAAE086DE
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: 
Date: Fri, 18 Mar 2016 15:27:51 -0700
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <56EAEB54.8010208@aol.com> 
To: Brian Campbell 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 22:27:58 -0000

--Apple-Mail-BBBC7E54-8DF6-41A8-AB02-DB4DAAE086DE
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

There are two variations.=20

Mitm the token endpoint is different then working one legit token endpoint a=
gainst another thru redirect and state misdirection.=20

In the mitm version you don't need multiple AS's.

Phil

> On Mar 18, 2016, at 15:04, Brian Campbell  wro=
te:
>=20
> The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitiga=
ted by returning an identifier for the AS in the authorization response. It i=
s something that needs to be addressed but "discovery" or metadata aren't ne=
eded and audience restricted access tokens tokens don't help.
>=20
> Maybe that's obvious but there seems to be a lot of confusion on all this s=
o I wanted to reiterate it.
>=20
>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher  wrot=
e:
>> Goals:
>>=20
>> 1. Help the client not send a token to the "wrong" endpoint
>>    a. wrong AS /token endpoint
>>    b. evil RS endpoint(s)
>> 2. Allow good RS to determine if the token being validated was intended f=
or that RS
>>=20
>> Other high-level goals?
>>=20
>> Use cases:
>>=20
>> 1. RS that supports multiple AS (we've had this in production since 2011)=

>> 2. RS rejects token not issued for use at the RS
>> 3. Client that dynamically supports new RS (say any client that supports t=
he jabber API)
>> 4. Client that dynamically supports new AS
>>=20
>> Feel free to add to the list :)
>>=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-BBBC7E54-8DF6-41A8-AB02-DB4DAAE086DE
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


    There are two variations. 
    <=
div id=3D"AppleMailSignature">
    Mitm t=
he token endpoint is different then working one legit token endpoint against=
 another thru redirect and state misdirection. 

    In the mitm version yo=
u don't need multiple AS's.

    Phil

    On Mar 18, 2016, at 15=
:04, Brian Campbell <bcampb=
ell@pingidentity.com> wrote:

    <=
div>
    The "a. wrong AS /token endpoint" is the mix-up is=
sue, which can be mitigated by returning an identifier for the AS in the aut=
horization response. It is something that needs to be addressed but "discove=
ry" or metadata aren't needed and audience restricted access tokens tokens don't help.<=
br>
    Maybe that's obvious but there seems to be a lot of confusion o=
n all this so I wanted to reiterate it.
    =

    On Thu, Mar 17, 2016 at 11:37 AM, George Flet=
cher <gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    
   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended for t=
hat RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports the=
 jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

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


    

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

--Apple-Mail-BBBC7E54-8DF6-41A8-AB02-DB4DAAE086DE--


From nobody Fri Mar 18 15:39:31 2016
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 5B0AC12D5B9 for ; Fri, 18 Mar 2016 15:39:30 -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=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 0dNWfs69AN4G for ; Fri, 18 Mar 2016 15:39:28 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 0C7BC12D57F for ; Fri, 18 Mar 2016 15:39:28 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id o5so69679988iod.2 for ; Fri, 18 Mar 2016 15:39:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LObKCXjdEMJ3QzAC67wBI9rC3ezzIZp6/Wkto13o54E=; b=hTpupzArRtx6tMXk31hiBm+zqV9uAJQKfO0ovy7/wBRSjiok7T5m0Om2naoLFm2axl yZMe3exS0AlBH0mtleXVj0xN1bI5kKBj6d1PKzXJW1Neuv9e3NHGb/F2Y/3vnbRWgKHT JyRPQkHKR8UPtvsgeUKVwWIEE3VP/7GA5XD1w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LObKCXjdEMJ3QzAC67wBI9rC3ezzIZp6/Wkto13o54E=; b=FAa8brThdm10q7vpxcjWM6hwx2n13eue7NA6VX4s3V9srek0BU6492Ui6+4pPX/z64 +SaxwAY9Paq46oUf697xhs26EPYjoLNVRmMM+7VQAbLzpCrnYOErYtFNiUruNGrGy9+a j/7Dx5bJiGdB6z4SqHCMcrE1/utCi0snp1XSyauP4VznypQwZX9n+nt2DRiBMq+M3vbc f8KtBDse1dzwE3Wk/dW4Npie9srDrxgRKsuzfUlvqumdCpAksmCjuj43FnZQ9K1uXDC5 Q1RY59YdnxSa6i+TCrI6GLIjijjCNnC++o8ikqnFkwrlLjr/+NDvJ7VH8QzhM9oWe5nB T7xg==
X-Gm-Message-State: AD7BkJIh8+AH0qOtg0jG0wel0JPGGxfCI9oegEq4h59V+XN1WcCJe2QAKqgCrxkSxEQYClnbox08NVLzMaJNJmor
X-Received: by 10.107.137.152 with SMTP id t24mr20303674ioi.147.1458340767341;  Fri, 18 Mar 2016 15:39:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Fri, 18 Mar 2016 15:38:57 -0700 (PDT)
In-Reply-To: 
References: <56EAEB54.8010208@aol.com>  
From: Brian Campbell 
Date: Fri, 18 Mar 2016 16:38:57 -0600
Message-ID: 
To: "Phil Hunt (IDM)" 
Content-Type: multipart/alternative; boundary=001a113f9022664a83052e5a6bce
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 22:39:30 -0000

--001a113f9022664a83052e5a6bce
Content-Type: text/plain; charset=UTF-8

How does one Mitm the token endpoint?

On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) 
wrote:

> There are two variations.
>
> Mitm the token endpoint is different then working one legit token endpoint
> against another thru redirect and state misdirection.
>
> In the mitm version you don't need multiple AS's.
>
> Phil
>
> On Mar 18, 2016, at 15:04, Brian Campbell 
> wrote:
>
> The "a. wrong AS /token endpoint" is the mix-up issue, which can be
> mitigated by returning an identifier for the AS in the authorization
> response. It is something that needs to be addressed but "discovery" or
> metadata aren't needed and audience restricted access tokens tokens don't
> help.
>
> Maybe that's obvious but there seems to be a lot of confusion on all this
> so I wanted to reiterate it.
>
> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher 
> wrote:
>
>> Goals:
>>
>> 1. Help the client not send a token to the "wrong" endpoint
>>    a. wrong AS /token endpoint
>>    b. evil RS endpoint(s)
>> 2. Allow good RS to determine if the token being validated was intended
>> for that RS
>>
>> Other high-level goals?
>>
>> Use cases:
>>
>> 1. RS that supports multiple AS (we've had this in production since 2011)
>> 2. RS rejects token not issued for use at the RS
>> 3. Client that dynamically supports new RS (say any client that supports
>> the jabber API)
>> 4. Client that dynamically supports new AS
>>
>> Feel free to add to the list :)
>>
>> _______________________________________________
>> 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
>
>

--001a113f9022664a83052e5a6bce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    How does one Mitm the token endpoint?

    On Fri, Mar 18, 2016 at 4:27 PM,=
 Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
    There are two variations.=C2=
=A0

    Mitm the token endpoint is different then work=
ing one legit token endpoint against another thru redirect and state misdir=
ection.=C2=A0

    In the mitm version you don't ne=
ed multiple AS's.
    Phil

    On Mar 18, 2016, a=
t 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /to=
ken endpoint" is the mix-up issue, which can be mitigated by returning=
 an identifier for the AS in the authorization response. It is something th=
at needs to be addressed but "discovery" or metadata=
 aren't needed and audience restricted access tokens tokens don't h=
elp.

    Maybe that's obvious but there seems to be a lot of c=
onfusion on all this so I wanted to reiterate it.

    On Thu, Mar 17, 2016 at 11:37 AM,=
 George Fletcher <gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    
=C2=A0 =C2=A0a. wrong AS /token endpoint
    
=C2=A0 =C2=A0b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended for=
 that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since 201=
1)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports th=
e jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

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


    

    ___________________=
____________________________
    OAuth mailing list
    <=
span>OAuth@ietf.org=

    https://www.ietf.org/mailman/listinfo/oauth
    <=
/div>

    

--001a113f9022664a83052e5a6bce--


From nobody Fri Mar 18 15:53:02 2016
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 22F8212D705 for ; Fri, 18 Mar 2016 15:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 1W7SWPxaFVoB for ; Fri, 18 Mar 2016 15:52:59 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 BD62A12D576 for ; Fri, 18 Mar 2016 15:52:58 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2IMquss009294 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Mar 2016 22:52:56 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2IMquR3029344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2016 22:52:56 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2IMqm4Q013206; Fri, 18 Mar 2016 22:52:54 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Mar 2016 15:52:42 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D2E69FE-D514-4DE2-8D3F-BF0C3124F6EC"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Fri, 18 Mar 2016 15:52:41 -0700
Message-Id: <20024B1B-7EC0-4354-A173-94F9F58AE1A3@oracle.com>
References: <56EAEB54.8010208@aol.com>   
To: Brian Campbell 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 22:53:01 -0000

--Apple-Mail=_4D2E69FE-D514-4DE2-8D3F-BF0C3124F6EC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

By convincing the client to use a bad URL.  That=E2=80=99s kinda why =
we=E2=80=99re worried about bad discovery no?

Depending on the type of client authentication, the client will =
establish a valid connection to the hacker=E2=80=99s proxy which then =
replays the token request to the real endpoint.  The hacker now has the =
token.

Same thing for the resource endpoint - except worse. The hacker =
doesn=E2=80=99t need the token as they now see the payload.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 18, 2016, at 3:38 PM, Brian Campbell =
 wrote:
>=20
> How does one Mitm the token endpoint?
>=20
> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) > wrote:
> There are two variations.=20
>=20
> Mitm the token endpoint is different then working one legit token =
endpoint against another thru redirect and state misdirection.=20
>=20
> In the mitm version you don't need multiple AS's.
>=20
> Phil
>=20
> On Mar 18, 2016, at 15:04, Brian Campbell > wrote:
>=20
>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be =
mitigated by returning an identifier for the AS in the authorization =
response. It is something that needs to be addressed but "discovery" or =
metadata aren't needed and audience restricted access tokens tokens =
don't help.
>>=20
>> Maybe that's obvious but there seems to be a lot of confusion on all =
this so I wanted to reiterate it.
>>=20
>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher > wrote:
>> Goals:
>>=20
>> 1. Help the client not send a token to the "wrong" endpoint
>>    a. wrong AS /token endpoint
>>    b. evil RS endpoint(s)
>> 2. Allow good RS to determine if the token being validated was =
intended for that RS
>>=20
>> Other high-level goals?
>>=20
>> Use cases:
>>=20
>> 1. RS that supports multiple AS (we've had this in production since =
2011)
>> 2. RS rejects token not issued for use at the RS
>> 3. Client that dynamically supports new RS (say any client that =
supports the jabber API)
>> 4. Client that dynamically supports new AS
>>=20
>> Feel free to add to the list :)
>>=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 =

>=20


--Apple-Mail=_4D2E69FE-D514-4DE2-8D3F-BF0C3124F6EC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

By convincing the client to use a bad URL.  That=E2=80=99s=
 kinda why we=E2=80=99re worried about bad discovery no?

    Depending on the type of =
client authentication, the client will establish a valid connection to =
the hacker=E2=80=99s proxy which then replays the token request to the =
real endpoint.  The hacker now has the token.

    Same thing for the =
resource endpoint - except worse. The hacker doesn=E2=80=99t need the =
token as they now see the payload.

    


    

    

    On Mar 18, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

    How does one Mitm the token endpoint?

    On Fri, =
Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
    There are two variations. 

    Mitm the token endpoint =
is different then working one legit token endpoint against another thru =
redirect and state misdirection. 

    In the mitm version you don't need =
multiple AS's.

    Phil

    On Mar 18, =
2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /token =
endpoint" is the mix-up issue, which can be mitigated by returning an =
identifier for the AS in the authorization response. It is something =
that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access =
tokens tokens don't help.

    Maybe =
that's obvious but there seems to be a lot of confusion on all this so I =
wanted to reiterate it.
    On Thu, Mar 17, 2016 at 11:37 AM, =
George Fletcher <gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    =

   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended =
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since =
2011)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports =
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

    
_______________________________________________
    
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

    

    =

--Apple-Mail=_4D2E69FE-D514-4DE2-8D3F-BF0C3124F6EC--


From nobody Fri Mar 18 16:01:10 2016
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 18D8112D705 for ; Fri, 18 Mar 2016 16:01:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 tFP3_BV6z6p9 for ; Fri, 18 Mar 2016 16:01:06 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 2A5EC12D7ED for ; Fri, 18 Mar 2016 16:01:06 -0700 (PDT)
Received: by mail-qg0-x235.google.com with SMTP id w104so112957851qge.1 for ; Fri, 18 Mar 2016 16:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=HsAxOFqTIYjYLB87cc6GI3Ls4DbTtfHoI05x4fVqf9w=; b=f3SRK9apm+v8KZQSlRowO0xFrAnsQRZcIPE1xB0D5RfxBIn4/8mJp0rxOWORfI4Czh yDSTTbqKF/cT02tH99zNtbhHtSTJZGvyg0Am23ZorDR9iSVNx1dUUMkP6955Yr9t8PrB 6MEZ8XGDNrJlKHruO/UOhJ5zlH6s9HPXMOlK5F/eUuDGiimqOTTx6VZmfCNeBPMliScW AXfoiTjK8z+Dq8/leCOE+mrHuUoesVPgOVdNin75dCaSVHgdtxp2JaO0BQ4YpAZ1JUuc Z1jkiVD5QyxmXHloaoz2sZbNJ8Gq7QwA5QpWXnenqj+FvvxpNPQaTZzFtURKvDg87YJ/ V5vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HsAxOFqTIYjYLB87cc6GI3Ls4DbTtfHoI05x4fVqf9w=; b=FF2tSxXN87HMF0D29qPYo5u80OOR4GdWYAwFwRl7eIDmnHuIhUhHASOEbZzPKD7qJt nRQfAopw21HyS9XC8u6GzE+vwst20+DiVIhwtwSzJohsOjmoUee21uRaE/McknVLqt4R 45gr8fHVWAqOTDnDjjRkfewvihhk+EZyy4NhNt39XCn6JP5WE790jtGDlM14o/kR/riI e/xgW3Beg2lLhZfG3HrTDvj9l4Ojtq2h82tUcPeidYJpnSgRiJhHKtwmI9utKucR/UWN OA+6pzI7VaMw4PkxdoHtCQVY+wODrJAlnZtTZxUGW5wRbEZEzrCf0mjUYOliAmdMWgxs Aidw==
X-Gm-Message-State: AD7BkJJD8RGivAL2Aauj3MVqNpSFwkzAovWWvSu4Jp/g/NVzsMY9qd0dCWNkdREQgChDlg==
X-Received: by 10.140.98.98 with SMTP id n89mr26614248qge.9.1458342065119; Fri, 18 Mar 2016 16:01:05 -0700 (PDT)
Received: from [192.168.8.101] ([181.202.83.141]) by smtp.gmail.com with ESMTPSA id y129sm7001348qka.33.2016.03.18.16.01.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 16:01:04 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_06FAE696-9E57-48E2-98FF-65CCAD9813DB"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <20024B1B-7EC0-4354-A173-94F9F58AE1A3@oracle.com>
Date: Fri, 18 Mar 2016 20:01:00 -0300
Message-Id: 
References: <56EAEB54.8010208@aol.com>    <20024B1B-7EC0-4354-A173-94F9F58AE1A3@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 23:01:09 -0000

--Apple-Mail=_06FAE696-9E57-48E2-98FF-65CCAD9813DB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6C0C47F6-592D-4300-881B-7763235CD0FA"


--Apple-Mail=_6C0C47F6-592D-4300-881B-7763235CD0FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The Mitigation we agreed on for the bad token endpoint is returning the =
issuer and client_id form the authorization endpoint.

Phil are you saying that you no longer agree with that?=20

The question that was unresolved was how the client would get a bad =
resource URI, and what the correct mitigation is if any.

John B.


> On Mar 18, 2016, at 7:52 PM, Phil Hunt  wrote:
>=20
> By convincing the client to use a bad URL.  That=E2=80=99s kinda why =
we=E2=80=99re worried about bad discovery no?
>=20
> Depending on the type of client authentication, the client will =
establish a valid connection to the hacker=E2=80=99s proxy which then =
replays the token request to the real endpoint.  The hacker now has the =
token.
>=20
> Same thing for the resource endpoint - except worse. The hacker =
doesn=E2=80=99t need the token as they now see the payload.
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 18, 2016, at 3:38 PM, Brian Campbell =
> wrote:
>>=20
>> How does one Mitm the token endpoint?
>>=20
>> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) =
> wrote:
>> There are two variations.=20
>>=20
>> Mitm the token endpoint is different then working one legit token =
endpoint against another thru redirect and state misdirection.=20
>>=20
>> In the mitm version you don't need multiple AS's.
>>=20
>> Phil
>>=20
>> On Mar 18, 2016, at 15:04, Brian Campbell > wrote:
>>=20
>>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be =
mitigated by returning an identifier for the AS in the authorization =
response. It is something that needs to be addressed but "discovery" or =
metadata aren't needed and audience restricted access tokens tokens =
don't help.
>>>=20
>>> Maybe that's obvious but there seems to be a lot of confusion on all =
this so I wanted to reiterate it.
>>>=20
>>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher > wrote:
>>> Goals:
>>>=20
>>> 1. Help the client not send a token to the "wrong" endpoint
>>>    a. wrong AS /token endpoint
>>>    b. evil RS endpoint(s)
>>> 2. Allow good RS to determine if the token being validated was =
intended for that RS
>>>=20
>>> Other high-level goals?
>>>=20
>>> Use cases:
>>>=20
>>> 1. RS that supports multiple AS (we've had this in production since =
2011)
>>> 2. RS rejects token not issued for use at the RS
>>> 3. Client that dynamically supports new RS (say any client that =
supports the jabber API)
>>> 4. Client that dynamically supports new AS
>>>=20
>>> Feel free to add to the list :)
>>>=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 =

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


--Apple-Mail=_6C0C47F6-592D-4300-881B-7763235CD0FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The Mitigation we agreed on for the bad token endpoint is =
returning the issuer and client_id form the authorization endpoint.

    Phil are you saying that =
you no longer agree with that? 

    The question that was unresolved was =
how the client would get a bad resource URI, and what the correct =
mitigation is if any.

    John B.


    On Mar 18, 2016, at 7:52 PM, =
Phil Hunt <phil.hunt@oracle.com> wrote:

    By convincing =
the client to use a bad URL.  That=E2=80=99s kinda why we=E2=80=99re =
worried about bad discovery no?

    Depending on the type of client authentication, the client =
will establish a valid connection to the hacker=E2=80=99s proxy which =
then replays the token request to the real endpoint.  The hacker =
now has the token.

    Same thing for the resource endpoint - except worse. The =
hacker doesn=E2=80=99t need the token as they now see the =
payload.

    




    

    

    On Mar 18, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

    How does one Mitm the token endpoint?

    On Fri, =
Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
    There are two variations. 

    Mitm the token endpoint =
is different then working one legit token endpoint against another thru =
redirect and state misdirection. 

    In the mitm version you don't need =
multiple AS's.

    Phil

    On Mar 18, =
2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /token =
endpoint" is the mix-up issue, which can be mitigated by returning an =
identifier for the AS in the authorization response. It is something =
that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access =
tokens tokens don't help.

    Maybe =
that's obvious but there seems to be a lot of confusion on all this so I =
wanted to reiterate it.
    On Thu, Mar 17, 2016 at 11:37 AM, =
George Fletcher <gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    =

   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended =
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since =
2011)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports =
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

    
_______________________________________________
    
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

    


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

    =

--Apple-Mail=_6C0C47F6-592D-4300-881B-7763235CD0FA--

--Apple-Mail=_06FAE696-9E57-48E2-98FF-65CCAD9813DB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTgyMzAxMDFaMCMGCSqGSIb3DQEJBDEWBBTIEDXaJ1Y2TDh31xzLzNp3
Zu8GMDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBIfsGa/kLWmeJIhG2/rfYr3uxRQRVECTKm35kOtgTJlV+hpvj6Rdcm
X7D3Rp2vzqlGuguD9lOn5br5bSJsDNbMI8jA+e1iuAseoMGj9LK//y5n/pxfTEYH7LWjtgLi6RBa
j50RsJXORYy4/DHyaRu1EI97MMfqXZFwmsBZHhgZfGCFhG+piNiNesY6h35/ci2iKtOZppXUX86u
xYvFPldktzn+yW7nwWx7fy3awTCGSMeShXwSG0zQkHA6jh0OB8Dp64mSF2jcc0g6DUE/Id/K3zfq
Ld6pFuCotOly3hJAK9Lb4SaVy31sxyEBAphVbYTnGAy1+ebszMaIn1zi9sDxAAAAAAAA
--Apple-Mail=_06FAE696-9E57-48E2-98FF-65CCAD9813DB--


From nobody Fri Mar 18 16:17:11 2016
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 3C39A12D8EB for ; Fri, 18 Mar 2016 16:17:10 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 kcCYnQCHq3xG for ; Fri, 18 Mar 2016 16:17:05 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 CA6BC12D874 for ; Fri, 18 Mar 2016 16:17:04 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id s68so55696093qkh.3 for ; Fri, 18 Mar 2016 16:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=6B91TXRGjGiIZU67BrlxuMEfXIfEfy70WhLB7eM7hu8=; b=2NNWpzwX6SumYhhnrXNoGg/jr0rUwvXMTLUhmJ7NhEcZO4VN3LH8mfQ5EK3+cHNkYE PI80qlsezRA6vUvaN7cwAncc4aCjY9mv8++Oa/kg9Ez58eSvyVbxfMv8MlasOil9FagI a3v30O3vM2pjERcvErqFF39sMZvi0cZeod7eC40Nr+B1imiwdrHELZa9OI2ej+YRRx9A EDEls9CBLDASq4mZ1t5wZgki7e0oXmTpMmjVWoof7RPe5JBxG3y7XmIB4/+LuAH5FBpH RXE9nsvEBteE3YZTXazYc5Kx21t+wRT4StiujtS/3tl6DcTcr4Jqntq3i/9hXXDgSIjR VYZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6B91TXRGjGiIZU67BrlxuMEfXIfEfy70WhLB7eM7hu8=; b=X9nrjOF4znywCJHAFSYE2Uz/b7jaHAzrYIJldG0cUVjBd3WIeqzRiofwEU2l08Ym3i J16scO2NHQW5t5poqyRWQFd6z+QCpUizk/jc3mh74C8uYDGZvGmkCRt/xgtmlK/O/tUI uzb8S3iNXjNcK3bxoiAdMmQ3B+7J58hk7yRz9+u2ZrAQjIDXCpHYi9u4P/I5N4Jx+Kor dh6LuGqk+eHKfNVb3yncoZaVY4UzTnWiF1WII0s/MhNJjUm7xyKbYfeQSaxIGudClXiu B1vLt+mahakQPxkvWm3L3nVmbe5ixspuk0Eg0CjHPMbvDh9+5XAeJwNhM3NzGIjD1mTO iA6g==
X-Gm-Message-State: AD7BkJK0k5Tbw+8rdMx1rtTQFfQ1W1W1CCVnWCEaOrJQm0lAvr31KYx0Oa3aMuY4joggoQ==
X-Received: by 10.55.75.144 with SMTP id y138mr25861633qka.96.1458343023854; Fri, 18 Mar 2016 16:17:03 -0700 (PDT)
Received: from [192.168.8.101] ([181.202.83.141]) by smtp.gmail.com with ESMTPSA id e11sm7022931qkb.39.2016.03.18.16.17.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 16:17:03 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_522B7762-96B1-4D8E-8EAF-2F4AC5A91ED9"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 18 Mar 2016 20:16:59 -0300
Message-Id: 
References: <56EAEB54.8010208@aol.com>  
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 23:17:10 -0000

--Apple-Mail=_522B7762-96B1-4D8E-8EAF-2F4AC5A91ED9
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F42D40E8-DA2E-4C18-AC38-1FF9A8E3D124"


--Apple-Mail=_F42D40E8-DA2E-4C18-AC38-1FF9A8E3D124
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

You still have a good AS and a bad AS it is just that the bad AS is =
using the good AS=E2=80=99s authorization endpoint.

I guess it comes down to how you define what a AS is if it is malicious.

Remember all of the attacks postulated in the papers require a xsrf =
attack or man in the network to cause a client to start a authorization =
with the bad AS triggering bad discovery and registration.

If the bad AS is publishing a malicious RS and the =E2=80=9Cgood=E2=80=9D =
registration, authorization, and token endpoints.   It will have a =
different issuer from the=20
good AS authorization endpoint.   When the client performs authorization =
thinking it is going to bad AS and gets back the issuer for good AS that =
will trigger an error in the client and it will never present the AT to =
the bad RS=E2=80=99s resource endpoint.

If the developer hard codes some bad RS endpoint in the client then, I =
admit returning the iss and client_id from the authorization endpoint =
won=E2=80=99t help.

John B.


> On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM)  =
wrote:
>=20
> There are two variations.=20
>=20
> Mitm the token endpoint is different then working one legit token =
endpoint against another thru redirect and state misdirection.=20
>=20
> In the mitm version you don't need multiple AS's.
>=20
> Phil
>=20
> On Mar 18, 2016, at 15:04, Brian Campbell > wrote:
>=20
>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be =
mitigated by returning an identifier for the AS in the authorization =
response. It is something that needs to be addressed but "discovery" or =
metadata aren't needed and audience restricted access tokens tokens =
don't help.
>>=20
>> Maybe that's obvious but there seems to be a lot of confusion on all =
this so I wanted to reiterate it.
>>=20
>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher > wrote:
>> Goals:
>>=20
>> 1. Help the client not send a token to the "wrong" endpoint
>>    a. wrong AS /token endpoint
>>    b. evil RS endpoint(s)
>> 2. Allow good RS to determine if the token being validated was =
intended for that RS
>>=20
>> Other high-level goals?
>>=20
>> Use cases:
>>=20
>> 1. RS that supports multiple AS (we've had this in production since =
2011)
>> 2. RS rejects token not issued for use at the RS
>> 3. Client that dynamically supports new RS (say any client that =
supports the jabber API)
>> 4. Client that dynamically supports new AS
>>=20
>> Feel free to add to the list :)
>>=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 =

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


--Apple-Mail=_F42D40E8-DA2E-4C18-AC38-1FF9A8E3D124
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

You still have a good AS and a bad AS it is just that the bad =
AS is using the good AS=E2=80=99s authorization endpoint.

    I guess it comes down to =
how you define what a AS is if it is malicious.

    Remember all of the attacks postulated =
in the papers require a xsrf attack or man in the network to cause a =
client to start a authorization with the bad AS triggering bad discovery =
and registration.

    If the bad AS is publishing a malicious RS and the =E2=80=9Cgoo=
d=E2=80=9D registration, authorization, and token endpoints.   It =
will have a different issuer from the 
    good AS =
authorization endpoint.   When the client performs authorization =
thinking it is going to bad AS and gets back the issuer for good AS that =
will trigger an error in the client and it will never present the AT to =
the bad RS=E2=80=99s resource endpoint.

    If the developer hard codes some bad RS =
endpoint in the client then, I admit returning the iss and client_id =
from the authorization endpoint won=E2=80=99t help.

    John B.


    On =
Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    There are two =
variations. 

    Mitm the token endpoint is different then working one legit =
token endpoint against another thru redirect and state =
misdirection. 

    In the mitm version you don't need multiple AS's.

    Phil

    On =
Mar 18, 2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /token =
endpoint" is the mix-up issue, which can be mitigated by returning an =
identifier for the AS in the authorization response. It is something =
that needs to be addressed but "discovery" or metadata aren't needed and =
audience restricted access tokens tokens don't help.

    Maybe that's obvious but there seems to be a lot of =
confusion on all this so I wanted to reiterate it.

    On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher =
<gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    =

   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended =
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since =
2011)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports =
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

    
_______________________________________________
    
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
    ______________________________________=
_________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

    =

--Apple-Mail=_F42D40E8-DA2E-4C18-AC38-1FF9A8E3D124--

--Apple-Mail=_522B7762-96B1-4D8E-8EAF-2F4AC5A91ED9
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTgyMzE2NjBaMCMGCSqGSIb3DQEJBDEWBBQG6hiOK+vwZXl5l/j4Md5d
BcxG8TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCBMHBQfmtE1GzCsvCx6RMnVweVpbQHuT2oRtpaIU7syoxdpTpU4wWW
lJM5pF4YSYO7vHD5mbJIYxsTV8qjxa/HbR8Ze9JtI2YzgHWvhQnGGggnJ2nt1Qh7153+htb7S1CP
ar/owpRxCNAgoG2eptvVTKhCdbzWvhLez/zXrVWtF2kEfUyVa9MGGEOguwkQCHu7o2sZMrl3bqxq
L7ofw3OIB8rm7kfuyZTFgtdL0PVn7CH8EBiTDWmoPXy0k5foM438mj1vEUZWNdVUD1qdbjcETd2d
LSwR6YfHjSRQ1r2/fLDZY61eQHm3xewV4oAUbkyyeDgPXzL4fBmqqk1Jc9gtAAAAAAAA
--Apple-Mail=_522B7762-96B1-4D8E-8EAF-2F4AC5A91ED9--


From nobody Fri Mar 18 16:19:24 2016
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 7C7D712D55D for ; Fri, 18 Mar 2016 16:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 D-rpjF94Buns for ; Fri, 18 Mar 2016 16:19:20 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 E2A3F12D51B for ; Fri, 18 Mar 2016 16:19:19 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2INJI67030721 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2016 23:19:19 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2INJIKK021754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2016 23:19:18 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2INJAnl021824; Fri, 18 Mar 2016 23:19:16 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Mar 2016 16:19:05 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_6988764A-8FC5-40A3-ACEF-923EC22333CE"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Fri, 18 Mar 2016 16:19:03 -0700
Message-Id: <6C87CFDA-FD24-4C85-8876-D60BE5EFB5F8@oracle.com>
References: <56EAEB54.8010208@aol.com>    <20024B1B-7EC0-4354-A173-94F9F58AE1A3@oracle.com> 
To: John Bradley 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 23:19:23 -0000

--Apple-Mail=_6988764A-8FC5-40A3-ACEF-923EC22333CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

John,

I haven=E2=80=99t changed my mind. But I now think we=E2=80=99ve come =
away with a different understanding of the threats.

I recall that we agreed that =E2=80=9Ciss=E2=80=9D and =E2=80=9Cclient_id=E2=
=80=9D are for mitigating mix-up, by allowing a client to figure out =
what token endpoint a grant is for.  There is nothing that helps a =
client to determine that the token endpoint it is about to use is valid. =
 IOW. The client could have the correct =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Cclient_id=E2=80=9D from the AS authorization endpoint, but it =
thinks it is supposed to pass the grant to token.evil.com instead of =
token.example.com to redeem it.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 18, 2016, at 4:01 PM, John Bradley  wrote:
>=20
> The Mitigation we agreed on for the bad token endpoint is returning =
the issuer and client_id form the authorization endpoint.
>=20
> Phil are you saying that you no longer agree with that?=20
>=20
> The question that was unresolved was how the client would get a bad =
resource URI, and what the correct mitigation is if any.
>=20
> John B.
>=20
>=20
>> On Mar 18, 2016, at 7:52 PM, Phil Hunt > wrote:
>>=20
>> By convincing the client to use a bad URL.  That=E2=80=99s kinda why =
we=E2=80=99re worried about bad discovery no?
>>=20
>> Depending on the type of client authentication, the client will =
establish a valid connection to the hacker=E2=80=99s proxy which then =
replays the token request to the real endpoint.  The hacker now has the =
token.
>>=20
>> Same thing for the resource endpoint - except worse. The hacker =
doesn=E2=80=99t need the token as they now see the payload.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com =
phil.hunt@oracle.com =

>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 18, 2016, at 3:38 PM, Brian Campbell =
> wrote:
>>>=20
>>> How does one Mitm the token endpoint?
>>>=20
>>> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) =
> wrote:
>>> There are two variations.=20
>>>=20
>>> Mitm the token endpoint is different then working one legit token =
endpoint against another thru redirect and state misdirection.=20
>>>=20
>>> In the mitm version you don't need multiple AS's.
>>>=20
>>> Phil
>>>=20
>>> On Mar 18, 2016, at 15:04, Brian Campbell =
> wrote:
>>>=20
>>>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be =
mitigated by returning an identifier for the AS in the authorization =
response. It is something that needs to be addressed but "discovery" or =
metadata aren't needed and audience restricted access tokens tokens =
don't help.
>>>>=20
>>>> Maybe that's obvious but there seems to be a lot of confusion on =
all this so I wanted to reiterate it.
>>>>=20
>>>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher > wrote:
>>>> Goals:
>>>>=20
>>>> 1. Help the client not send a token to the "wrong" endpoint
>>>>    a. wrong AS /token endpoint
>>>>    b. evil RS endpoint(s)
>>>> 2. Allow good RS to determine if the token being validated was =
intended for that RS
>>>>=20
>>>> Other high-level goals?
>>>>=20
>>>> Use cases:
>>>>=20
>>>> 1. RS that supports multiple AS (we've had this in production since =
2011)
>>>> 2. RS rejects token not issued for use at the RS
>>>> 3. Client that dynamically supports new RS (say any client that =
supports the jabber API)
>>>> 4. Client that dynamically supports new AS
>>>>=20
>>>> Feel free to add to the list :)
>>>>=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 =

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


--Apple-Mail=_6988764A-8FC5-40A3-ACEF-923EC22333CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


    John,

    I haven=E2=80=99t changed my mind. But =
I now think we=E2=80=99ve come away with a different understanding of =
the threats.

    I =
recall that we agreed that =E2=80=9Ciss=E2=80=9D and =E2=80=9Cclient_id=E2=
=80=9D are for mitigating mix-up, by allowing a client to figure out =
what token endpoint a grant is for.  There is nothing that helps a =
client to determine that the token endpoint it is about to use is valid. =
 IOW. The client could have the correct =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Cclient_id=E2=80=9D from the AS authorization endpoint, but it =
thinks it is supposed to pass the grant to token.evil.com instead of =
token.example.com to =
redeem it.

    


    

    

    On Mar 18, 2016, at 4:01 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    The Mitigation =
we agreed on for the bad token endpoint is returning the issuer and =
client_id form the authorization endpoint.

    Phil are you saying that you no longer =
agree with that? 

    The question that was unresolved was how the client would get =
a bad resource URI, and what the correct mitigation is if any.

    John B.


    On Mar 18, 2016, at 7:52 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    By convincing =
the client to use a bad URL.  That=E2=80=99s kinda why we=E2=80=99re =
worried about bad discovery no?

    Depending on the type of client authentication, the client =
will establish a valid connection to the hacker=E2=80=99s proxy which =
then replays the token request to the real endpoint.  The hacker =
now has the token.

    Same thing for the resource endpoint - except worse. The =
hacker doesn=E2=80=99t need the token as they now see the =
payload.

    




    

    

    On Mar 18, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

    How does one Mitm the token endpoint?

    On Fri, =
Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
    There are two variations. 

    Mitm the token endpoint =
is different then working one legit token endpoint against another thru =
redirect and state misdirection. 

    In the mitm version you don't need =
multiple AS's.

    Phil

    On Mar 18, =
2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /token =
endpoint" is the mix-up issue, which can be mitigated by returning an =
identifier for the AS in the authorization response. It is something =
that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access =
tokens tokens don't help.

    Maybe =
that's obvious but there seems to be a lot of confusion on all this so I =
wanted to reiterate it.
    On Thu, Mar 17, 2016 at 11:37 AM, =
George Fletcher <gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    =

   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended =
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since =
2011)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports =
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

    
_______________________________________________
    
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

    


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


    =

--Apple-Mail=_6988764A-8FC5-40A3-ACEF-923EC22333CE--


From nobody Fri Mar 18 16:28:44 2016
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 3A49012D829 for ; Fri, 18 Mar 2016 16:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 o5viNX7RkuBL for ; Fri, 18 Mar 2016 16:28:40 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 AF60E12D55D for ; Fri, 18 Mar 2016 16:28:40 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2INSd3R005757 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2016 23:28:39 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2INScCc007427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2016 23:28:38 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2INSUBI024575; Fri, 18 Mar 2016 23:28:36 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 18 Mar 2016 16:28:25 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_D36F0C86-46E8-4A69-BA5C-9C552C1FAA29"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Fri, 18 Mar 2016 16:28:23 -0700
Message-Id: 
References: <56EAEB54.8010208@aol.com>   
To: John Bradley 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 23:28:43 -0000

--Apple-Mail=_D36F0C86-46E8-4A69-BA5C-9C552C1FAA29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

John

You are trying to solve a completely different problem.

In the bad discovery scenario there is no good AS and bad AS.

1.  There is only one AS and one RS infrastrucutre

2.  The client is mis-configured because it has been given a bad =
endpoint for one of dyn-reg, token, or resource

The client has no way to know what constitutes a valid set of endpoints.

The AS is acting in good faith in all respects.  It become promiscuous =
because it is turning over grants and/or tokens over to clients that are =
sending them to a bad endpoint.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 18, 2016, at 4:16 PM, John Bradley  wrote:
>=20
> You still have a good AS and a bad AS it is just that the bad AS is =
using the good AS=E2=80=99s authorization endpoint.
>=20
> I guess it comes down to how you define what a AS is if it is =
malicious.
>=20
> Remember all of the attacks postulated in the papers require a xsrf =
attack or man in the network to cause a client to start a authorization =
with the bad AS triggering bad discovery and registration.
>=20
> If the bad AS is publishing a malicious RS and the =E2=80=9Cgood=E2=80=9D=
 registration, authorization, and token endpoints.   It will have a =
different issuer from the=20
> good AS authorization endpoint.   When the client performs =
authorization thinking it is going to bad AS and gets back the issuer =
for good AS that will trigger an error in the client and it will never =
present the AT to the bad RS=E2=80=99s resource endpoint.
>=20
> If the developer hard codes some bad RS endpoint in the client then, I =
admit returning the iss and client_id from the authorization endpoint =
won=E2=80=99t help.
>=20
> John B.
>=20
>=20
>> On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) > wrote:
>>=20
>> There are two variations.=20
>>=20
>> Mitm the token endpoint is different then working one legit token =
endpoint against another thru redirect and state misdirection.=20
>>=20
>> In the mitm version you don't need multiple AS's.
>>=20
>> Phil
>>=20
>> On Mar 18, 2016, at 15:04, Brian Campbell > wrote:
>>=20
>>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be =
mitigated by returning an identifier for the AS in the authorization =
response. It is something that needs to be addressed but "discovery" or =
metadata aren't needed and audience restricted access tokens tokens =
don't help.
>>>=20
>>> Maybe that's obvious but there seems to be a lot of confusion on all =
this so I wanted to reiterate it.
>>>=20
>>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher > wrote:
>>> Goals:
>>>=20
>>> 1. Help the client not send a token to the "wrong" endpoint
>>>    a. wrong AS /token endpoint
>>>    b. evil RS endpoint(s)
>>> 2. Allow good RS to determine if the token being validated was =
intended for that RS
>>>=20
>>> Other high-level goals?
>>>=20
>>> Use cases:
>>>=20
>>> 1. RS that supports multiple AS (we've had this in production since =
2011)
>>> 2. RS rejects token not issued for use at the RS
>>> 3. Client that dynamically supports new RS (say any client that =
supports the jabber API)
>>> 4. Client that dynamically supports new AS
>>>=20
>>> Feel free to add to the list :)
>>>=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 =

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


--Apple-Mail=_D36F0C86-46E8-4A69-BA5C-9C552C1FAA29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

John

    You =
are trying to solve a completely different problem.

    In the bad discovery =
scenario there is no good AS and bad AS.

    1.  There is only one AS and one =
RS infrastrucutre

    2.  The client is mis-configured because it has been =
given a bad endpoint for one of dyn-reg, token, or resource

    The client has no way to =
know what constitutes a valid set of endpoints.

    The AS is acting in good faith in all =
respects.  It become promiscuous because it is turning over grants =
and/or tokens over to clients that are sending them to a bad =
endpoint.

    


    

    

    On Mar 18, 2016, at 4:16 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    You still have =
a good AS and a bad AS it is just that the bad AS is using the good =
AS=E2=80=99s authorization endpoint.

    I guess it comes down to how you define =
what a AS is if it is malicious.

    Remember all of the attacks postulated =
in the papers require a xsrf attack or man in the network to cause a =
client to start a authorization with the bad AS triggering bad discovery =
and registration.

    If the bad AS is publishing a malicious RS and the =E2=80=9Cgoo=
d=E2=80=9D registration, authorization, and token endpoints.   It =
will have a different issuer from the 
    good AS =
authorization endpoint.   When the client performs authorization =
thinking it is going to bad AS and gets back the issuer for good AS that =
will trigger an error in the client and it will never present the AT to =
the bad RS=E2=80=99s resource endpoint.

    If the developer hard codes some bad RS =
endpoint in the client then, I admit returning the iss and client_id =
from the authorization endpoint won=E2=80=99t help.

    John B.


    On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    There are two =
variations. 

    Mitm the token endpoint is different then working one legit =
token endpoint against another thru redirect and state =
misdirection. 

    In the mitm version you don't need multiple AS's.

    Phil

    On =
Mar 18, 2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /token =
endpoint" is the mix-up issue, which can be mitigated by returning an =
identifier for the AS in the authorization response. It is something =
that needs to be addressed but "discovery" or metadata aren't needed and =
audience restricted access tokens tokens don't help.

    Maybe that's obvious but there seems to be a lot of =
confusion on all this so I wanted to reiterate it.

    On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher =
<gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    =

   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended =
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since =
2011)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports =
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

    
_______________________________________________
    
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
    ______________________________________=
_________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    =

--Apple-Mail=_D36F0C86-46E8-4A69-BA5C-9C552C1FAA29--


From nobody Fri Mar 18 16:29:38 2016
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 A793B12D50B for ; Fri, 18 Mar 2016 16:29:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 Ik-VVCqfWoUL for ; Fri, 18 Mar 2016 16:29:33 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 AA36012D557 for ; Fri, 18 Mar 2016 16:29:33 -0700 (PDT)
Received: by mail-qg0-x232.google.com with SMTP id a36so81722781qge.0 for ; Fri, 18 Mar 2016 16:29:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=r5KYVolT+aX0KNibOqBZm2fBnm3qrpklHlPhbUE94rQ=; b=Iexa+S6z0J/FqqMUp8eOVHfRikSanJv3o2ZO63lIEo+5PpfZSSB9ZcuKxFFByeufNO 4f6Vpo600Avye3EFdzBXDIAM1FBB4TNbfs/O9GzwJRgPSmKbF8nOzHm+sO7jK+e3lRuH Vnco/fdq/E+qPvOgOx/QO3+gZw1APgID4AyCT1DEbiSexRjjv8EEXCou5sQDoiGPWpfO sxp1m/BkvmEnzR6AQ0QcFS+w8kdEYijDPd018NdmwIIAfPzT8V+gy0n8XalCxJvBBMFq TYznd1x+bmy14EltOg3bxLTjcmtSE7pbV1/ZA33yPtv7Q0tLnr8Yy3cf39KDSNv/ubLQ U8Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=r5KYVolT+aX0KNibOqBZm2fBnm3qrpklHlPhbUE94rQ=; b=D0S18srL35L1G6GNGEt1JUpSiNXEpE4/Y6vkhCuk4ae1YKjsKGpprFt2cOb4rOt/f+ ybDfPgtTXa5OKboGgxDze50qysIYZo6xvYvlToZBAQEBBQiRmPYtu0+D5vHq8pZZsVT+ nGbVEUdNs+rdh6sEexgmiFLpI8zh8aSfM/xdBkgd45SJj8ksVr36AXPVQvce0IkrDpMW /lBb3du2c8ipPqIeT1egUy3eKW7WZZVS6UGsWg/fhuFa/zOZhIT4C74TGWfasdCMDLtE VwPj+A8C2ywNLYjaISYHqFPRhHgC+ijZwdMhKhEpCR57fUbZQbFc6Koy66WWjwHskcP+ fP4Q==
X-Gm-Message-State: AD7BkJKzSB0v8m85sZlvRMo3gvpOgv5yynUgRk/oqT2HQ/oZ1qpyW5j28hMByOxJColKvg==
X-Received: by 10.140.159.69 with SMTP id f66mr27609776qhf.18.1458343772696; Fri, 18 Mar 2016 16:29:32 -0700 (PDT)
Received: from [192.168.8.101] ([181.202.83.141]) by smtp.gmail.com with ESMTPSA id 49sm7021821qgx.32.2016.03.18.16.29.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 16:29:31 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_8085E5B8-9FC8-4234-A1B0-4CF10B170C58"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <6C87CFDA-FD24-4C85-8876-D60BE5EFB5F8@oracle.com>
Date: Fri, 18 Mar 2016 20:29:27 -0300
Message-Id: 
References: <56EAEB54.8010208@aol.com>    <20024B1B-7EC0-4354-A173-94F9F58AE1A3@oracle.com>  <6C87CFDA-FD24-4C85-8876-D60BE5EFB5F8@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 23:29:36 -0000

--Apple-Mail=_8085E5B8-9FC8-4234-A1B0-4CF10B170C58
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FFA25CFE-25B6-4864-A824-D74AD5D58938"


--Apple-Mail=_FFA25CFE-25B6-4864-A824-D74AD5D58938
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The mitigation prevents the client from sending the code to a token =
endpoint that is not associated with the AS returning the code.

I think you need to describe a MiTM attack on the token endpoint that =
the proposed mitigation that was reviewed by the researchers doesn=E2=80=99=
t mitigate.

You seem to have defined some new attacks as not being the confused =
client attacks that you are trying to mitigate.

Perhaps not understanding the attack is causing some of us to not =
understand the value of the mitigation you propose.

John B.


=20
> On Mar 18, 2016, at 8:19 PM, Phil Hunt  wrote:
>=20
> John,
>=20
> I haven=E2=80=99t changed my mind. But I now think we=E2=80=99ve come =
away with a different understanding of the threats.
>=20
> I recall that we agreed that =E2=80=9Ciss=E2=80=9D and =E2=80=9Cclient_i=
d=E2=80=9D are for mitigating mix-up, by allowing a client to figure out =
what token endpoint a grant is for.  There is nothing that helps a =
client to determine that the token endpoint it is about to use is valid. =
 IOW. The client could have the correct =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Cclient_id=E2=80=9D from the AS authorization endpoint, but it =
thinks it is supposed to pass the grant to token.evil.com =
 instead of token.example.com =
 to redeem it.
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 18, 2016, at 4:01 PM, John Bradley > wrote:
>>=20
>> The Mitigation we agreed on for the bad token endpoint is returning =
the issuer and client_id form the authorization endpoint.
>>=20
>> Phil are you saying that you no longer agree with that?=20
>>=20
>> The question that was unresolved was how the client would get a bad =
resource URI, and what the correct mitigation is if any.
>>=20
>> John B.
>>=20
>>=20
>>> On Mar 18, 2016, at 7:52 PM, Phil Hunt > wrote:
>>>=20
>>> By convincing the client to use a bad URL.  That=E2=80=99s kinda why =
we=E2=80=99re worried about bad discovery no?
>>>=20
>>> Depending on the type of client authentication, the client will =
establish a valid connection to the hacker=E2=80=99s proxy which then =
replays the token request to the real endpoint.  The hacker now has the =
token.
>>>=20
>>> Same thing for the resource endpoint - except worse. The hacker =
doesn=E2=80=99t need the token as they now see the payload.
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com =
phil.hunt@oracle.com =

>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Mar 18, 2016, at 3:38 PM, Brian Campbell =
> wrote:
>>>>=20
>>>> How does one Mitm the token endpoint?
>>>>=20
>>>> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) =
> wrote:
>>>> There are two variations.=20
>>>>=20
>>>> Mitm the token endpoint is different then working one legit token =
endpoint against another thru redirect and state misdirection.=20
>>>>=20
>>>> In the mitm version you don't need multiple AS's.
>>>>=20
>>>> Phil
>>>>=20
>>>> On Mar 18, 2016, at 15:04, Brian Campbell =
> wrote:
>>>>=20
>>>>> The "a. wrong AS /token endpoint" is the mix-up issue, which can =
be mitigated by returning an identifier for the AS in the authorization =
response. It is something that needs to be addressed but "discovery" or =
metadata aren't needed and audience restricted access tokens tokens =
don't help.
>>>>>=20
>>>>> Maybe that's obvious but there seems to be a lot of confusion on =
all this so I wanted to reiterate it.
>>>>>=20
>>>>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher =
> wrote:
>>>>> Goals:
>>>>>=20
>>>>> 1. Help the client not send a token to the "wrong" endpoint
>>>>>    a. wrong AS /token endpoint
>>>>>    b. evil RS endpoint(s)
>>>>> 2. Allow good RS to determine if the token being validated was =
intended for that RS
>>>>>=20
>>>>> Other high-level goals?
>>>>>=20
>>>>> Use cases:
>>>>>=20
>>>>> 1. RS that supports multiple AS (we've had this in production =
since 2011)
>>>>> 2. RS rejects token not issued for use at the RS
>>>>> 3. Client that dynamically supports new RS (say any client that =
supports the jabber API)
>>>>> 4. Client that dynamically supports new AS
>>>>>=20
>>>>> Feel free to add to the list :)
>>>>>=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 =

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

>>=20
>=20


--Apple-Mail=_FFA25CFE-25B6-4864-A824-D74AD5D58938
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The mitigation prevents the client from sending the code to a =
token endpoint that is not associated with the AS returning the =
code.

    I think you =
need to describe a MiTM attack on the token endpoint that the proposed =
mitigation that was reviewed by the researchers doesn=E2=80=99t =
mitigate.

    You =
seem to have defined some new attacks as not being the confused client =
attacks that you are trying to mitigate.

    Perhaps not understanding the attack is =
causing some of us to not understand the value of the mitigation you =
propose.

    John =
B.


     
    On Mar 18, 2016, at 8:19 PM, =
Phil Hunt <phil.hunt@oracle.com> wrote:

    John,

    I haven=E2=80=99t changed my mind. But I now think we=E2=80=99v=
e come away with a different understanding of the threats.

    I recall that we agreed =
that =E2=80=9Ciss=E2=80=9D and =E2=80=9Cclient_id=E2=80=9D are for =
mitigating mix-up, by allowing a client to figure out what token =
endpoint a grant is for.  There is nothing that helps a client to =
determine that the token endpoint it is about to use is valid. =
 IOW. The client could have the correct =E2=80=9Ciss=E2=80=9D and =
=E2=80=9Cclient_id=E2=80=9D from the AS authorization endpoint, but it =
thinks it is supposed to pass the grant to token.evil.com instead of =
token.example.com =
to redeem it.

    




    

    

    On Mar 18, 2016, at 4:01 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    The Mitigation =
we agreed on for the bad token endpoint is returning the issuer and =
client_id form the authorization endpoint.

    Phil are you saying that you no longer =
agree with that? 

    The question that was unresolved was how the client would get =
a bad resource URI, and what the correct mitigation is if any.

    John B.


    On Mar 18, 2016, at 7:52 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    By convincing =
the client to use a bad URL.  That=E2=80=99s kinda why we=E2=80=99re =
worried about bad discovery no?

    Depending on the type of client authentication, the client =
will establish a valid connection to the hacker=E2=80=99s proxy which =
then replays the token request to the real endpoint.  The hacker =
now has the token.

    Same thing for the resource endpoint - except worse. The =
hacker doesn=E2=80=99t need the token as they now see the =
payload.

    




    

    

    On Mar 18, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

    How does one Mitm the token endpoint?

    On Fri, =
Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
    There are two variations. 

    Mitm the token endpoint =
is different then working one legit token endpoint against another thru =
redirect and state misdirection. 

    In the mitm version you don't need =
multiple AS's.

    Phil

    On Mar 18, =
2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /token =
endpoint" is the mix-up issue, which can be mitigated by returning an =
identifier for the AS in the authorization response. It is something =
that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access =
tokens tokens don't help.

    Maybe =
that's obvious but there seems to be a lot of confusion on all this so I =
wanted to reiterate it.
    On Thu, Mar 17, 2016 at 11:37 AM, =
George Fletcher <gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    =

   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended =
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since =
2011)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports =
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

    
_______________________________________________
    
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

    


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



    =

--Apple-Mail=_FFA25CFE-25B6-4864-A824-D74AD5D58938--

--Apple-Mail=_8085E5B8-9FC8-4234-A1B0-4CF10B170C58
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTgyMzI5MjhaMCMGCSqGSIb3DQEJBDEWBBTvTTSVqXNWYUSh5EGd10tx
xFBeIzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQASZcZ5irkUjy1owZo+T/W2j9D9/KRzWfSQledYmuHFxHds8ur/+HtR
Ccc95f41t2Rw+Mn8ugZMTxQEwc0SwLK5iEXPm+0f5ofCYf9dBG0PMmaeZOSntNHpTOXeB1TtP4Tw
NDvo9vatMCRlpOOAZut3VOBCZC17HRrxKvRPTFZ01V3WEkCF26AS1TqPIX1n8hSLvYLG+LJwt2mE
RWalgA6e+7MXmaHcwaqdDwpxhTQtRUD53CDQI/cITI0d2KfZou87DsWCO1G7gxSyhDCVninEfXpO
qjBgCONSbwWp0FE7dk0f41UMbDEA8AY7rf25ut4c3GSmYm9uFw8egN/EiIc8AAAAAAAA
--Apple-Mail=_8085E5B8-9FC8-4234-A1B0-4CF10B170C58--


From nobody Fri Mar 18 16:43:53 2016
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 BED4C12D5C7 for ; Fri, 18 Mar 2016 16:43:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 G_ByxbZmcMMk for ; Fri, 18 Mar 2016 16:43:50 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 B452512D50B for ; Fri, 18 Mar 2016 16:43:49 -0700 (PDT)
Received: by mail-qg0-x22a.google.com with SMTP id w104so113572288qge.1 for ; Fri, 18 Mar 2016 16:43:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=XrvSzStg3U5VS9ZHC0znjPCWjWDBBFaPkZQ2eChY9nI=; b=VjoM6jLQ5LtmT3z4wV4duA3lYqYUN3SjQ6ttuH2e7nCkbFCfPkzPwRsFefMgJ1R1gi u6cNfTlxooAspTDyT8DZLPG9PwpQZOpNfH67j8JV8sR64Gs1FEO6p5wft1NpdYIYct6I HDv7/o770D/7e+RAR9iiMEikOq6AXMYmdBWlahzrGc4l0Ri+TN+xrqT6gfF/69XhxRNW 4l0B9fhxhJ31m0ojoJAymLtgaWdseac77YYSjceMOi9lqTB/L3nZhLbYTcXV+prrUyJB 3HX03f8z3iXW4dbip61qhLqAV3a4/XQZrpZb8NpAaMzPDNFqFh/JKEI44XTPGXqyKxxB i/lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XrvSzStg3U5VS9ZHC0znjPCWjWDBBFaPkZQ2eChY9nI=; b=clR9IH27/8uJ2pnO5W0FDSD1oiCcWzXt7W3Hy11QEiA1hqBS7CWPwhSEyzVJxFW293 YzUAEgQj3kemK1ll4uLfK0V5cAMR/05gykuxRm8GRQWas6xJl9kQ2xYd2zXsyXNN8sTQ a5cGT3g26kE/xo+uRPKmaToD0I6e/FI7aD1nqxAbrgwsKM+JDP1cJj7IRl11XCSZOE2m Ikunw78SpFO4wvYU4hs+o8ERpjQgPhKiT2h4dxT/2ixG/B+cvgAiN/WmrrMaFwv7oBu7 jTQ1CRCZWyQRq4hP6JYWdcy8u9zqe/3ok8hB5CEKc0bgK/YLbck1tuYbInZNP6cyCs5N JcbA==
X-Gm-Message-State: AD7BkJLOOW0Y+eQ+j5Q+t8PAqg7GPv4WlWHs013YCH7XXzSmJLrul9EfaxxAEbA9hko9OQ==
X-Received: by 10.140.177.17 with SMTP id x17mr27552898qhx.39.1458344628768; Fri, 18 Mar 2016 16:43:48 -0700 (PDT)
Received: from [192.168.8.101] ([181.202.83.141]) by smtp.gmail.com with ESMTPSA id s8sm7016271qhb.20.2016.03.18.16.43.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 16:43:48 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_A2E39F3B-D032-44D5-AC1A-BF49719D0A2A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 18 Mar 2016 20:43:44 -0300
Message-Id: 
References: <56EAEB54.8010208@aol.com>    
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 23:43:53 -0000

--Apple-Mail=_A2E39F3B-D032-44D5-AC1A-BF49719D0A2A
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0F383BD3-D698-47C2-901D-EA4381A151A0"


--Apple-Mail=_0F383BD3-D698-47C2-901D-EA4381A151A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Phil someone is giving the client the bad endpoints.  =46rom the =
perspective of the client that is an AS.

I count that as two entities one good and one bad.

We agreed not to force clients to do discovery. =20

How is the client being given this bad set of endpoints?

If it is being given them by dereferencing a issuer to get the =
.well-known then the mitigation will stop the attack because the two =
issuers can=E2=80=99t be the same unless the attacker has compromised =
the good AS=E2=80=99s .well-known, and that I would argue is a different =
problem.

John B.



> On Mar 18, 2016, at 8:28 PM, Phil Hunt  wrote:
>=20
> John
>=20
> You are trying to solve a completely different problem.
>=20
> In the bad discovery scenario there is no good AS and bad AS.
>=20
> 1.  There is only one AS and one RS infrastrucutre
>=20
> 2.  The client is mis-configured because it has been given a bad =
endpoint for one of dyn-reg, token, or resource
>=20
> The client has no way to know what constitutes a valid set of =
endpoints.
>=20
> The AS is acting in good faith in all respects.  It become promiscuous =
because it is turning over grants and/or tokens over to clients that are =
sending them to a bad endpoint.
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 18, 2016, at 4:16 PM, John Bradley > wrote:
>>=20
>> You still have a good AS and a bad AS it is just that the bad AS is =
using the good AS=E2=80=99s authorization endpoint.
>>=20
>> I guess it comes down to how you define what a AS is if it is =
malicious.
>>=20
>> Remember all of the attacks postulated in the papers require a xsrf =
attack or man in the network to cause a client to start a authorization =
with the bad AS triggering bad discovery and registration.
>>=20
>> If the bad AS is publishing a malicious RS and the =E2=80=9Cgood=E2=80=9D=
 registration, authorization, and token endpoints.   It will have a =
different issuer from the=20
>> good AS authorization endpoint.   When the client performs =
authorization thinking it is going to bad AS and gets back the issuer =
for good AS that will trigger an error in the client and it will never =
present the AT to the bad RS=E2=80=99s resource endpoint.
>>=20
>> If the developer hard codes some bad RS endpoint in the client then, =
I admit returning the iss and client_id from the authorization endpoint =
won=E2=80=99t help.
>>=20
>> John B.
>>=20
>>=20
>>> On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) > wrote:
>>>=20
>>> There are two variations.=20
>>>=20
>>> Mitm the token endpoint is different then working one legit token =
endpoint against another thru redirect and state misdirection.=20
>>>=20
>>> In the mitm version you don't need multiple AS's.
>>>=20
>>> Phil
>>>=20
>>> On Mar 18, 2016, at 15:04, Brian Campbell =
> wrote:
>>>=20
>>>> The "a. wrong AS /token endpoint" is the mix-up issue, which can be =
mitigated by returning an identifier for the AS in the authorization =
response. It is something that needs to be addressed but "discovery" or =
metadata aren't needed and audience restricted access tokens tokens =
don't help.
>>>>=20
>>>> Maybe that's obvious but there seems to be a lot of confusion on =
all this so I wanted to reiterate it.
>>>>=20
>>>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher > wrote:
>>>> Goals:
>>>>=20
>>>> 1. Help the client not send a token to the "wrong" endpoint
>>>>    a. wrong AS /token endpoint
>>>>    b. evil RS endpoint(s)
>>>> 2. Allow good RS to determine if the token being validated was =
intended for that RS
>>>>=20
>>>> Other high-level goals?
>>>>=20
>>>> Use cases:
>>>>=20
>>>> 1. RS that supports multiple AS (we've had this in production since =
2011)
>>>> 2. RS rejects token not issued for use at the RS
>>>> 3. Client that dynamically supports new RS (say any client that =
supports the jabber API)
>>>> 4. Client that dynamically supports new AS
>>>>=20
>>>> Feel free to add to the list :)
>>>>=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 =

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

>>=20
>=20


--Apple-Mail=_0F383BD3-D698-47C2-901D-EA4381A151A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Phil someone is giving the client the bad endpoints. =
 =46rom the perspective of the client that is an AS.

    I count that as two =
entities one good and one bad.

    We agreed not to force clients to do =
discovery.  

    How is the client being given this bad set of =
endpoints?

    If =
it is being given them by dereferencing a issuer to get the .well-known =
then the mitigation will stop the attack because the two issuers can=E2=80=
=99t be the same unless the attacker has compromised the good AS=E2=80=99s=
 .well-known, and that I would argue is a different problem.

    John B.



    On Mar 18, 2016, at 8:28 PM, =
Phil Hunt <phil.hunt@oracle.com> wrote:

    John

    You are trying to solve =
a completely different problem.

    In the bad discovery scenario there is =
no good AS and bad AS.

    1.  There is only one AS and one RS =
infrastrucutre

    2.  The client is mis-configured because it has been =
given a bad endpoint for one of dyn-reg, token, or resource

    The client has no way to =
know what constitutes a valid set of endpoints.

    The AS is acting in good faith in all =
respects.  It become promiscuous because it is turning over grants =
and/or tokens over to clients that are sending them to a bad =
endpoint.

    




    

    

    On Mar 18, 2016, at 4:16 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

    You still have =
a good AS and a bad AS it is just that the bad AS is using the good =
AS=E2=80=99s authorization endpoint.

    I guess it comes down to how you define =
what a AS is if it is malicious.

    Remember all of the attacks postulated =
in the papers require a xsrf attack or man in the network to cause a =
client to start a authorization with the bad AS triggering bad discovery =
and registration.

    If the bad AS is publishing a malicious RS and the =E2=80=9Cgoo=
d=E2=80=9D registration, authorization, and token endpoints.   It =
will have a different issuer from the 
    good AS =
authorization endpoint.   When the client performs authorization =
thinking it is going to bad AS and gets back the issuer for good AS that =
will trigger an error in the client and it will never present the AT to =
the bad RS=E2=80=99s resource endpoint.

    If the developer hard codes some bad RS =
endpoint in the client then, I admit returning the iss and client_id =
from the authorization endpoint won=E2=80=99t help.

    John B.


    On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

    There are two =
variations. 

    Mitm the token endpoint is different then working one legit =
token endpoint against another thru redirect and state =
misdirection. 

    In the mitm version you don't need multiple AS's.

    Phil

    On =
Mar 18, 2016, at 15:04, Brian Campbell <bcampbell@pingidentity.com> wrote:

    The "a. wrong AS /token =
endpoint" is the mix-up issue, which can be mitigated by returning an =
identifier for the AS in the authorization response. It is something =
that needs to be addressed but "discovery" or metadata aren't needed and =
audience restricted access tokens tokens don't help.

    Maybe that's obvious but there seems to be a lot of =
confusion on all this so I wanted to reiterate it.

    On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher =
<gffletch@aol.com> wrote:
    Goals:
    

    
1. Help the client not send a token to the "wrong" endpoint
    =

   a. wrong AS /token endpoint
    
   b. evil RS endpoint(s)
    
2. Allow good RS to determine if the token being validated was intended =
for that RS
    

    
Other high-level goals?
    

    
Use cases:
    

    
1. RS that supports multiple AS (we've had this in production since =
2011)
    
2. RS rejects token not issued for use at the RS
    
3. Client that dynamically supports new RS (say any client that supports =
the jabber API)
    
4. Client that dynamically supports new AS
    

    
Feel free to add to the list :)
    

    
_______________________________________________
    
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
    ______________________________________=
_________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth



    =

--Apple-Mail=_0F383BD3-D698-47C2-901D-EA4381A151A0--

--Apple-Mail=_A2E39F3B-D032-44D5-AC1A-BF49719D0A2A
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMTgyMzQzNDRaMCMGCSqGSIb3DQEJBDEWBBSgda3N1ZOwkpAzAWNiRYP4
W0FZMDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQA2yII9N8og04XtADC3Z0m4s1cWybujFgvulBWaqcUDXJm3pCkuRkmD
mhvT8+/nQeF2hEu/WpQFJn0Xs3MwzneIkRoA9nzPjKimsTbTHFDvbukWK/+7zd1L9rKxvDwhJVn6
GJRKcP/8OtY39d5rMcn7IYnGEwBPwYKT1GCCL94fdwGkgcBv5TD8yg/G6w32g48DwqlfYYkkutx5
JcjHY/KtlhU+ofljS+2zcFE8ngOSgAL6IsmIWdRhgGvrK3QzwO+dt88WcLWd3UYrFkyQH2TLKPUW
Jp6QkcbL8nk+8tENIWZFBOCDlYP2r6i1WwkHoOq9GUZ1uTssEMi3PGqXEM7VAAAAAAAA
--Apple-Mail=_A2E39F3B-D032-44D5-AC1A-BF49719D0A2A--


From nobody Sun Mar 20 08:00:10 2016
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 A6FB112D7AA; Sun, 20 Mar 2016 08:00:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160320150009.2298.70474.idtracker@ietfa.amsl.com>
Date: Sun, 20 Mar 2016 08:00:09 -0700
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-amr-values-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2016 15:00:09 -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 of the IETF.

        Title           : Authentication Method Reference Values
        Authors         : Michael B. Jones
                          Phil Hunt
                          Anthony Nadalin
	Filename        : draft-ietf-oauth-amr-values-00.txt
	Pages           : 12
	Date            : 2016-03-17

Abstract:
   The "amr" (Authentication Methods References) claim is defined and
   registered in the IANA "JSON Web Token Claims" registry but no
   standard Authentication Method Reference values are currently
   defined.  This specification establishes a registry for
   Authentication Method Reference values and defines an initial set of
   Authentication Method Reference values.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-amr-values-00


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 Sun Mar 20 08:00:42 2016
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 080EC12D7B3; Sun, 20 Mar 2016 08:00:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160320150038.2290.23766.idtracker@ietfa.amsl.com>
Date: Sun, 20 Mar 2016 08:00:38 -0700
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mix-up-mitigation-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2016 15:00:38 -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 of the IETF.

        Title           : OAuth 2.0 Mix-Up Mitigation
        Authors         : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-oauth-mix-up-mitigation-00.txt
	Pages           : 14
	Date            : 2016-03-18

Abstract:
   This specification defines an extension to The OAuth 2.0
   Authorization Framework that enables the authorization server to
   dynamically provide the client using it with additional information
   about the current protocol interaction that can be validated by the
   client and that enables the client to dynamically provide the
   authorization server with additional information about the current
   protocol interaction that can be validated by the authorization
   server.  This additional information can be used by the client and
   the authorization server to prevent classes of attacks in which the
   client might otherwise be tricked into using inconsistent sets of
   metadata from multiple authorization servers, including potentially
   using a token endpoint that does not belong to the same authorization
   server as the authorization endpoint used.  Recent research
   publications refer to these as "IdP Mix-Up" and "Malicious Endpoint"
   attacks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00


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 Sun Mar 20 14:18:02 2016
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 4F46C12D762 for ; Sun, 20 Mar 2016 14:18:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 roxIAsGM2S5H for ; Sun, 20 Mar 2016 14:17:58 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 E012412D548 for ; Sun, 20 Mar 2016 14:17:57 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id l68so88660481wml.0 for ; Sun, 20 Mar 2016 14:17:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:cc:to; bh=nu9GhScaV08UzBOSd8kjxiiqELfjJe0iVPDZg2WRw9g=; b=eZW1b+WS8BxCvTOr/Kqp0r9UkJD0P+At1gM5b6+b90Zo2YfmAOWxc8wzZJhlUhWbL7 sN9H9VUCwCGP+brwf5+vsuwS+LAIcVamb/7QW1IJfSVZcl3qq0NeGk5gn7/44/30BJUe UyaFxxRZY+A6SesIIgqmDRW6S2/Xbj1GQBDR0PeMftu4PviBiu75MqY4Yw8SJN/bMjxw OV9brCrWat4x8YHaURmNT1ndXeGvfyoPaBWsIvMu5RM6sU3d69s7NfkTf9ifSG7L+Iy9 DpquawwWHlIM356TEwXNOCb7bGnc2VCr7+CSfnST0oBC8cQqIF0J12YJUFGSTsCp6s/d JjQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:cc:to; bh=nu9GhScaV08UzBOSd8kjxiiqELfjJe0iVPDZg2WRw9g=; b=NXObJ2CKhhCNYVXdtlvmaiFt88kL1kpl/VeEYQV79nqv00ecJvbLw0u0W7BOHVE9v7 XnfXuqBz3CHOqA1bEFidoQ9qR2WduzqpOTphWrHUrocmPwsDDwCoEKrdAfyQBgDk/zLC 5LhGtH/sgFVMauV6KiFlbGw5T8r5R6x7iRywL6fBFht+fATW63FDFSoMPWgOvc5dDlI9 lf8czzCgdWX9mBJXr7NYD8rzmO40F/EdHutq5QuMzDMc1lp0UuVJQ7r3CG6WJd8d/aTF CEBXY3wZfvcbTsTmbuZn3LytHqaSkexhSVCAYzltx+uGiAHAIHM14E5/tTzQisr7+Ppq 4GVw==
X-Gm-Message-State: AD7BkJK1KpvhYob+a1yagz3Kt/QV5t9DhLBcFRdMMCFl1BKXDcqmZIaHg4x6Y8WPzhcchw==
X-Received: by 10.194.185.237 with SMTP id ff13mr29567663wjc.129.1458508676123;  Sun, 20 Mar 2016 14:17:56 -0700 (PDT)
Received: from [10.107.1.6] ([46.166.190.234]) by smtp.gmail.com with ESMTPSA id w184sm7688822wmb.1.2016.03.20.14.17.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Mar 2016 14:17:55 -0700 (PDT)
From: John Bradley 
Content-Type: multipart/signed; boundary="Apple-Mail=_A3082E99-00D6-4640-B167-216EC7D831EF"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Sun, 20 Mar 2016 21:17:53 +0000
References: <20160320201414.8930.5136.idtracker@ietfa.amsl.com>
To: "" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: Hannes Tschofenig 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2016 21:18:00 -0000

--Apple-Mail=_A3082E99-00D6-4640-B167-216EC7D831EF
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_26B22621-5C21-4AEE-983F-77721CC95CB6"


--Apple-Mail=_26B22621-5C21-4AEE-983F-77721CC95CB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

We have had a number of discussions  about splitting the audience part =
of PoP key distribution out into it=E2=80=99s own draft

Phil also requested  a draft on how I propose propose that proper =
audiencing of access tokens can mitigate against the threat of bearer =
access token leakage.

In response Brian Campbell and I have created a short 00 draft on how =
the client can specify the resource that it is requesting a token for =
without overloading scopes.

I hope that this will make some of the issues clearer for our =
discussion.

As Justin pointed out we may also want to separate out offline access =
and some other common things from scope as well.  This is intended to =
start the discussion not preclude other discussions around how to reduce =
the overloading of scope.

Regards
John Bradley



> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-campbell-oauth-resource-indicators-00.txt
> Date: March 20, 2016 at 8:14:14 PM GMT
> To: "Brian Campbell" , "John Bradley" =

>=20
>=20
> A new version of I-D, draft-campbell-oauth-resource-indicators-00.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>=20
> Name:		draft-campbell-oauth-resource-indicators
> Revision:	00
> Title:		Resource Indicators for OAuth 2.0
> Document date:	2016-03-20
> Group:		Individual Submission
> Pages:		7
> URL:            =
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicat=
ors-00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/=

> Htmlized:       =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00
>=20
>=20
> 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.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


--Apple-Mail=_26B22621-5C21-4AEE-983F-77721CC95CB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

We have had a number of discussions  about splitting the =
audience part of PoP key distribution out into it=E2=80=99s own =
draft

    Phil also =
requested  a draft on how I propose propose that proper audiencing =
of access tokens can mitigate against the threat of bearer access token =
leakage.

    In =
response Brian Campbell and I have created a short 00 draft on how the =
client can specify the resource that it is requesting a token for =
without overloading scopes.

    I hope that this will make some of the issues clearer for =
our discussion.

    As Justin pointed out we may also want to separate out =
offline access and some other common things from scope as well. =
 This is intended to start the discussion not preclude other =
discussions around how to reduce the overloading of scope.

    Regards
    John Bradley



    Begin forwarded message:

    From: =
internet-drafts@ietf.org
    Subject: =
New Version =
Notification for draft-campbell-oauth-resource-indicators-00.txt
    Date: =
March 20, 2016 at 8:14:14 PM =
GMT
    To: =
"Brian Campbell" <brian.d.campbell@gmail.com>, "John Bradley" <ve7jtb@ve7jtb.com>

    A new version of I-D, =
draft-campbell-oauth-resource-indicators-00.txt
    has been =
successfully submitted by Brian Campbell and posted to the
    IETF repository.

    Name:		=
draft-campbell-oauth-resource-indicators
    Revision:	00
    Title:		Resource =
Indicators for OAuth 2.0
    Document date:	=
2016-03-20
    Group:		Individual Submission
    Pages:=
		=
7
    URL: =
           https://www.ietf.org/internet-drafts/draft-campbell-oauth-resou=
rce-indicators-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-=
indicators/
    Htmlized: =
      https://tools.ietf.org/html/draft-campbell-oauth-resource-indic=
ators-00


    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.




    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.

    The IETF =
Secretariat


    =

--Apple-Mail=_26B22621-5C21-4AEE-983F-77721CC95CB6--

--Apple-Mail=_A3082E99-00D6-4640-B167-216EC7D831EF
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMjAyMTE3NTRaMCMGCSqGSIb3DQEJBDEWBBTTA6QLQhaKEmcv66LjIF4R
h5OaFjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCzE3dHoJJodlSv6DezGzImvWkBe60O+beCVY0WW8aR3mx/H5lRftYo
WecHlcuVf/o3dR2Jjmznorl4K3K2Ns6RiEktrKvpMPOrH4wrrgEzD+6sYL38pP/QHXnuuW4+XesO
3j9HRXJymLdQQNSaKPyKaXAVxyKlTJ2RsXJW1xN0t96wp8czaeHbZ8CoUhyoowSeix6z+CqiqnD7
dDMn/4WQd3pDXin/2CV/sW+FlvMvsztE/q4Wtq5XsaDmweO2zQ3b3aLTMQshKi9B3fwUMXtMMKhd
dnrLxX3MLaO4o5odkqF3oHZbuvYOl/yo2HVWim+SPJboorYrboNIzf2NfL1ZAAAAAAAA
--Apple-Mail=_A3082E99-00D6-4640-B167-216EC7D831EF--


From nobody Sun Mar 20 15:50:19 2016
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 CB74C12D548; Sun, 20 Mar 2016 15:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 hJ9smt5gvc91; Sun, 20 Mar 2016 15:50:14 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 E54A812D53A; Sun, 20 Mar 2016 15:50:13 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2KMoCP8004987 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Mar 2016 22:50:13 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2KMoCHX014773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Mar 2016 22:50:12 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2KMoBo9015763; Sun, 20 Mar 2016 22:50:11 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Mar 2016 15:50:11 -0700
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_E4A13D8B-3866-4267-82DB-1497CE6D4352"
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Sun, 20 Mar 2016 15:50:09 -0700
References: <20160320223939.8922.21591.idtracker@ietfa.amsl.com>
To: id-event@ietf.org
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "scim@ietf.org WG" , openid-general@lists.openid.net, "" 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-idevent-token-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2016 22:50:16 -0000

--Apple-Mail=_E4A13D8B-3866-4267-82DB-1497CE6D4352
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This draft specifies an identity/security event token based on JSON Web =
Tokens that can be extended for use in the identity space.=20

This is a preliminary draft based on the generous input of William =
Dennis, Morteza Ansari, as well the collective comments received on the =
id-event mailing list as well as informal discussion over the past few =
years.  Thanks to all who contributed!

Another draft will follow that defines how the id event token draft can =
be extended for SCIM. This should give other profiles an idea of how to =
extend the id event token draft for other uses.

There are also plans to do a subscription management draft that defines =
event feeds, and how they are delivered (or establishes a registry to =
support multiple methods.  Unfortunately we were not able to get this =
done in time for IETF95 through we will plan to discuss the =
requirements.

I encourage all to attend the SCIM session at IETF95 so we may further =
discuss the drafts and possible future direction.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-hunt-idevent-token-00.txt
> Date: March 20, 2016 at 3:39:39 PM PDT
> To: "William Denniss" , "Phil Hunt" =
, "Morteza Ansari" 
>=20
>=20
> A new version of I-D, draft-hunt-idevent-token-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
>=20
> Name:		draft-hunt-idevent-token
> Revision:	00
> Title:		Identity Event Token
> Document date:	2016-03-20
> Group:		Individual Submission
> Pages:		14
> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-idevent-token/
> Htmlized:       =
https://tools.ietf.org/html/draft-hunt-idevent-token-00
>=20
>=20
> Abstract:
>   This specification defines an Identity Event token which may be
>   distributed via a protocol such as HTTP.  An identity event token is
>   based on the JSON Web Token and may be optionally signed and/or
>   encrypted.  It describes a statement of fact that may be shared by =
an
>   event publisher with registered subscribers.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


--Apple-Mail=_E4A13D8B-3866-4267-82DB-1497CE6D4352
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

This draft specifies an identity/security event token based =
on JSON Web Tokens that can be extended for use in the identity =
space. 

    This is =
a preliminary draft based on the generous input of William Dennis, =
Morteza Ansari, as well the collective comments received on the id-event =
mailing list as well as informal discussion over the past few years. =
 Thanks to all who contributed!

    Another draft will follow that defines =
how the id event token draft can be extended for SCIM. This should give =
other profiles an idea of how to extend the id event token draft for =
other uses.

    There are also plans to do a subscription management draft =
that defines event feeds, and how they are delivered (or establishes a =
registry to support multiple methods.  Unfortunately we were not =
able to get this done in time for IETF95 through we will plan to discuss =
the requirements.

    I encourage all to attend the SCIM =
session at IETF95 so we may further discuss the drafts and possible =
future direction.

    


    

    



    Begin forwarded message:

    From: =
internet-drafts@ietf.org
    Subject: =
New Version =
Notification for draft-hunt-idevent-token-00.txt
    Date: =
March 20, 2016 at 3:39:39 PM =
PDT
    To: =
"William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>

    A new version =
of I-D, draft-hunt-idevent-token-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:		=
draft-hunt-idevent-token
    Revision:	00
    Title:=
		=
Identity Event Token
    Document date:	=
2016-03-20
    Group:		Individual Submission
    Pages:=
		=
14
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-0=
0.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-idevent-token/<=
br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-00


    Abstract:
     =
  This specification defines an Identity Event token which may =
be
       distributed via a protocol such as HTTP. =
 An identity event token is
       based on the =
JSON Web Token and may be optionally signed and/or
     =
  encrypted.  It describes a statement of fact that may =
be shared by an
       event publisher with =
registered subscribers.




    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.

    The IETF =
Secretariat


    =

--Apple-Mail=_E4A13D8B-3866-4267-82DB-1497CE6D4352--


From nobody Sun Mar 20 15:53:34 2016
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 E1D7112D561; Sun, 20 Mar 2016 15:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 9egDQLlbTS3i; Sun, 20 Mar 2016 15:53:27 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 2FAF512D555; Sun, 20 Mar 2016 15:53:27 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2KMrQ4J006594 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Mar 2016 22:53:26 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2KMrPx7019194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Mar 2016 22:53:26 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2KMrPlK026841; Sun, 20 Mar 2016 22:53:25 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Mar 2016 15:53:25 -0700
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4F286B55-98F7-4C80-8FEB-5568C47BF99C"
Message-Id: <1FBFEFDA-1B88-44B1-8A7A-1C4297FB71F1@oracle.com>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Sun, 20 Mar 2016 15:53:23 -0700
References: <20160320223949.8950.61033.idtracker@ietfa.amsl.com>
To: id-event@ietf.org
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "scim@ietf.org WG" , openid-general@lists.openid.net, "" 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-idevent-scim-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2016 22:53:29 -0000

--Apple-Mail=_4F286B55-98F7-4C80-8FEB-5568C47BF99C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

As mentioned in my previous message, this draft profiles the id-event =
token draft to define events for SCIM.

We plan to discuss this draft at the upcoming SCIM WG meeting at IETF95.

This draft may also be of interest to non-SCIM participants for creating =
other event profiles of id-event tokens.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-hunt-idevent-scim-00.txt
> Date: March 20, 2016 at 3:39:49 PM PDT
> To: "William Denniss" , "Phil Hunt" =
, "Morteza Ansari" 
>=20
>=20
> A new version of I-D, draft-hunt-idevent-scim-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
>=20
> Name:		draft-hunt-idevent-scim
> Revision:	00
> Title:		SCIM Event Extension
> Document date:	2016-03-20
> Group:		Individual Submission
> Pages:		14
> URL:            =
https://www.ietf.org/internet-drafts/draft-hunt-idevent-scim-00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-hunt-idevent-scim/
> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-scim-00
>=20
>=20
> Abstract:
>   This specification profiles the Identity Event Token specification =
to
>   define a set of identity events to be used with SCIM.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


--Apple-Mail=_4F286B55-98F7-4C80-8FEB-5568C47BF99C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

As mentioned in my previous message, this draft profiles the =
id-event token draft to define events for SCIM.

    We plan to discuss this draft at the =
upcoming SCIM WG meeting at IETF95.

    This draft may also be of interest to =
non-SCIM participants for creating other event profiles of id-event =
tokens.

    


    

    



    Begin forwarded message:

    From: =
internet-drafts@ietf.org
    Subject: =
New Version =
Notification for draft-hunt-idevent-scim-00.txt
    Date: =
March 20, 2016 at 3:39:49 PM =
PDT
    To: =
"William Denniss" <wdenniss@google.com>, "Phil Hunt" <phil.hunt@yahoo.com>, "Morteza Ansari" <morteza.ansari@cisco.com>

    A new version =
of I-D, draft-hunt-idevent-scim-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:		=
draft-hunt-idevent-scim
    Revision:	00
    Title:=
		=
SCIM Event Extension
    Document date:	=
2016-03-20
    Group:		Individual Submission
    Pages:=
		=
14
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-idevent-scim-00=
.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-idevent-scim/Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-scim-00


    Abstract:
     =
  This specification profiles the Identity Event Token =
specification to
       define a set of identity =
events to be used with SCIM.




    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.

    The IETF Secretariat


    =

--Apple-Mail=_4F286B55-98F7-4C80-8FEB-5568C47BF99C--


From nobody Sun Mar 20 16:16:28 2016
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 D1C5012D7AF; Sun, 20 Mar 2016 16:16:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160320231623.8918.64394.idtracker@ietfa.amsl.com>
Date: Sun, 20 Mar 2016 16:16:23 -0700
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2016 23:16:24 -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 of the IETF.

        Title           : OAuth 2.0 for Native Apps
        Authors         : William Denniss
                          John Bradley
	Filename        : draft-ietf-oauth-native-apps-01.txt
	Pages           : 16
	Date            : 2016-03-20

Abstract:
   OAuth 2.0 authorization requests from native apps should only be made
   through external user-agents such as the system browser (including
   via an in-app browser tab).  This specification details the security
   and usability reasons why this is the case, and how native apps and
   authorization servers can implement this best practice.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-01


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 Mon Mar 21 00:09:08 2016
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 5C68D12D54D for ; Mon, 21 Mar 2016 00:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 wiV8UrZ1TG66 for ; Mon, 21 Mar 2016 00:09:05 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3246512D623 for ; Mon, 21 Mar 2016 00:09:05 -0700 (PDT)
Received: from [192.168.10.140] ([80.92.114.73]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lg1Tn-1a19Md2YHb-00pb3A; Mon, 21 Mar 2016 08:09:00 +0100
To: John Bradley , "" 
References: <20160320201414.8930.5136.idtracker@ietfa.amsl.com> 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56EF9E0E.6010404@gmx.net>
Date: Mon, 21 Mar 2016 08:09:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PDr7xDQB0IcjfFIXVgWhEgFJvp458Je09"
X-Provags-ID: V03:K0:Ap7qOLPspmW+Obxq4TfX8m5msx3XpK8dSz2ochkEJvgMSXq1olM +ULk0+BEkBtG3qRljba7yHMUUSM/sd735wtJEnN99viNMhyOnpuxEb+VogYgvbXx6w65rdL CA+MKYyyf1R1WxIyY8/J3XJYvvEiwlGwIMG8lwAQGLigd5EynnoHZuRZURZLttGX21DSrIj KWl25wVTT8eXieuFe7R7A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:NP/kgCOY9q8=:5oz+SB2YqrUhbyLbAMjm/d SGvoGYlbqV2gwLgEgQhPwLaWnedSZ1M/sP7EJSksAdvwLusq8OHPbutc1DBpgXVhBPoZ03Q09 5St56Uet4zZlPO032YBW1146hILt4eYjkFOQH+sZ33DIAq9QFsnuK+rOwF7G/pa7Y4sM6C40Q NkosuZ0r2KnFZPOQsFwS/JZq/EZbK93f/MBzGLMd2V0ggkV1g1zozRTR8wAg54WIkxjBVPzzz XJdp8MQcDIhwETNmGKkiqAy5XjXfvx3nE9UxWmsS0BwrFdaFCFErWD6mqf0rb5SfcdH7+FIv+ qIfZgmGAQvwBIAK8gu/Vjvtg+OpR+ZAXOXZyHV/PcAhNjod0jL81yNqAyqmJE8AUMVDFLox04 IzQUwhe/m5VSox03Oa9im/A0T5jJuxoeeXcTklSHCGgWpapiJraxS+ORt8QAu3GSNWw1ldI6G 6QqqA96UrVFvMvqtjTQoqMkH+4Owu5mnR9Pl2evjmVoHrbhOZbyGoebmvZTdrfXNzO+iYgunX nEzqI0T1KdNIREyQND7ST4axfSDhZ/AE7oK1oymdOSjIJUsVydJ2GXp+FU6bdbFtUquomgUWH Rj2FyyWO9Qz4bwXjOLW/DnCTlZBaIODDhltgy09Yj0SFcShVKM0E/JzLTxgnuJHMAB/qPHgUN pVm9/s+X/bGI04FhZ4iCqvPFQag/dtPUKuGa4okfPP5G/HmZ09ybdrwL1YP18kXqgXucCwX/L HbxuEKKTWtcpwcbm3rX61nvstmj2hfXmJYzXYV47Q2jVi6bfCgu6hmNq5dY=
Archived-At: 
Cc: Hannes Tschofenig 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 07:09:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PDr7xDQB0IcjfFIXVgWhEgFJvp458Je09
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

FWIW: I also worth I wrote a draft a while ago about this topic:
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

On 03/20/2016 10:17 PM, John Bradley wrote:
> We have had a number of discussions  about splitting the audience part
> of PoP key distribution out into it=92s own draft
>=20
> Phil also requested  a draft on how I propose propose that proper
> audiencing of access tokens can mitigate against the threat of bearer
> access token leakage.
>=20
> In response Brian Campbell and I have created a short 00 draft on how
> the client can specify the resource that it is requesting a token for
> without overloading scopes.
>=20
> I hope that this will make some of the issues clearer for our discussio=
n.
>=20
> As Justin pointed out we may also want to separate out offline access
> and some other common things from scope as well.  This is intended to
> start the discussion not preclude other discussions around how to reduc=
e
> the overloading of scope.
>=20
> Regards
> John Bradley
>=20
>=20
>=20
>> Begin forwarded message:
>>
>> *From: *internet-drafts@ietf.org 
>> *Subject: **New Version Notification for
>> draft-campbell-oauth-resource-indicators-00.txt*
>> *Date: *March 20, 2016 at 8:14:14 PM GMT
>> *To: *"Brian Campbell" > >, "John Bradley"
>> >
>>
>>
>> A new version of I-D, draft-campbell-oauth-resource-indicators-00.txt
>> has been successfully submitted by Brian Campbell and posted to the
>> IETF repository.
>>
>> Name:draft-campbell-oauth-resource-indicators
>> Revision:00
>> Title:Resource Indicators for OAuth 2.0
>> Document date:2016-03-20
>> Group:Individual Submission
>> Pages:7
>> URL:
>>            https://www.ietf.org/internet-drafts/draft-campbell-oauth-r=
esource-indicators-00.txt
>> Status:
>>         https://datatracker.ietf.org/doc/draft-campbell-oauth-resource=
-indicators/
>> Htmlized:
>>       https://tools.ietf.org/html/draft-campbell-oauth-resource-indica=
tors-00
>>
>>
>> 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.
>>
>>
>>
>>
>> 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
>> .
>>
>> The IETF Secretariat
>>
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--PDr7xDQB0IcjfFIXVgWhEgFJvp458Je09
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW754OAAoJEGhJURNOOiAtapAH/RpU2PWGMMpfwUsz8qprQ00y
Cy1CaWLFXnRC8vjIZsdgDqnyGuVbFaIHUBtuMV1G835hxNAfe/UlcNdApnNSHZCL
bxoWWN5GWcGZjqo6IQIoUJ2e7jAVGI/jKKdIUYxOIYnRj4EV6BmxcSuW74KSlctr
QInne2kTkiS8UYlCF2HNVjhKy3tM6MOe9QeFnOadvqjsBpKGwE8Xu9ePZVrAbGbr
TUHR1R/BWTsnzHYHQpYWh4fIj9Hj6zrX0iGnyU9FtsSUESVyJDAUF023bw1JKJ1y
bsivPdDnLwptWGqjHTGNEs8AYDa0wI8wYP8oamA/9fXg0KxIoyO/pAGBKuTECx0=
=UiTT
-----END PGP SIGNATURE-----

--PDr7xDQB0IcjfFIXVgWhEgFJvp458Je09--


From nobody Mon Mar 21 01:09:13 2016
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 90E0212D66E for ; Mon, 21 Mar 2016 01:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 SMkN_aQy_PnP for ; Mon, 21 Mar 2016 01:09:10 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 34FD112D6B0 for ; Mon, 21 Mar 2016 01:09:10 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id l68so99124567wml.0 for ; Mon, 21 Mar 2016 01:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=W7kg/M3/RWFA7I7tzIhUnNLsGoNqe8IAs708HrN/xBQ=; b=WeoCDGQxsA4eXtO7RMqkZ3iMAh9BRquk8I/hrM0c3q7f6gk9OIGOlKy17rBkTT8t87 FP6H/ox6woi83QLs58j99Bjwb+ETd4fPcjl/AEG84Y7IhexUaijrSfTLmz+lxm+BX76q iqpgtvKut55Kqvl//R/GRBN95GjfuVknZMwLu7Pzg+1kbkWLa6Dg84t1o1pn03Ay3F+p ygwgFXX9f23+nOq/DOjmxb/INS16QF4eyousEXvPA7uGNHCqSGAMsufdBJGFMYiNEADQ wYRW8uKMEljZEfkuib1koBhIRapEY+Nb//tsip64taYalZdB2QN0md7RIpV8lUOnltta rlZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=W7kg/M3/RWFA7I7tzIhUnNLsGoNqe8IAs708HrN/xBQ=; b=AYnX7wb3e55mfOj4ovIH0T1rHoezlWlge+EqIAQfLTgUQ5BxqPMC/hX0UeVBAHRcH/ N1r92IG21G3ITpOOIX4RPIuB3zu3HMIz+aGQQms19YLzcnTHto0wANeQfejuzvNZ6zlv CPaAnSJHewB16W0m7MZpTiltCIOaNiapdJwP5z1ckwyknSBiVgfOTGtNRhORPlrgGpP5 7h9jwj7/2p0y2fzMUwEySsK+Lu/gzHVP0sfiEsMdw+BYv8AwD74xnrh06PkypVj4iXBM Rq1lamANQlumiApxd8JI8r1sIKyYMdTqjFU5tyDIfnOU1BT3nLJCV0CfvJgPf5pL2V0x u8xw==
X-Gm-Message-State: AD7BkJInMYs8lv8YzDT+8zHFEPTgyI5/vFSjnqCgB5hEl/h8FXsMbM0AZy9cnxZJCSSWMQ==
X-Received: by 10.194.185.237 with SMTP id ff13mr31838523wjc.129.1458547748528;  Mon, 21 Mar 2016 01:09:08 -0700 (PDT)
Received: from [10.125.1.6] ([46.166.137.232]) by smtp.gmail.com with ESMTPSA id a1sm8455426wje.43.2016.03.21.01.09.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Mar 2016 01:09:07 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_301D73D6-BD98-4946-8A14-A584CA115574"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56EF9E0E.6010404@gmx.net>
Date: Mon, 21 Mar 2016 08:09:06 +0000
Message-Id: <486347F9-07D0-4DB9-84AB-44FFFBCA2705@ve7jtb.com>
References: <20160320201414.8930.5136.idtracker@ietfa.amsl.com>  <56EF9E0E.6010404@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: Hannes Tschofenig , "" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 08:09:12 -0000

--Apple-Mail=_301D73D6-BD98-4946-8A14-A584CA115574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Thanks Hannes

We should merge them they are very similar.

We made a distinction between the resource URI and the audience to try =
and avoid some confusion about overloading the term audience.

We also covered the security considerations around user hosted content =
and being specific about the resource to avoid leakage.

We were less concerned about talking about key material, or the type of =
token.

We wanted to be able to show the WG that audience restricting AT has =
different and I argue better security properties than doing out of band =
discovery of the resource to try and stop AT leakage.

John B.



> On Mar 21, 2016, at 7:09 AM, Hannes Tschofenig =
 wrote:
>=20
> FWIW: I also worth I wrote a draft a while ago about this topic:
> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>=20
> On 03/20/2016 10:17 PM, John Bradley wrote:
>> We have had a number of discussions  about splitting the audience =
part
>> of PoP key distribution out into it=92s own draft
>>=20
>> Phil also requested  a draft on how I propose propose that proper
>> audiencing of access tokens can mitigate against the threat of bearer
>> access token leakage.
>>=20
>> In response Brian Campbell and I have created a short 00 draft on how
>> the client can specify the resource that it is requesting a token for
>> without overloading scopes.
>>=20
>> I hope that this will make some of the issues clearer for our =
discussion.
>>=20
>> As Justin pointed out we may also want to separate out offline access
>> and some other common things from scope as well.  This is intended to
>> start the discussion not preclude other discussions around how to =
reduce
>> the overloading of scope.
>>=20
>> Regards
>> John Bradley
>>=20
>>=20
>>=20
>>> Begin forwarded message:
>>>=20
>>> *From: *internet-drafts@ietf.org 
>>> *Subject: **New Version Notification for
>>> draft-campbell-oauth-resource-indicators-00.txt*
>>> *Date: *March 20, 2016 at 8:14:14 PM GMT
>>> *To: *"Brian Campbell" >> >, "John Bradley"
>>> >
>>>=20
>>>=20
>>> A new version of I-D, =
draft-campbell-oauth-resource-indicators-00.txt
>>> has been successfully submitted by Brian Campbell and posted to the
>>> IETF repository.
>>>=20
>>> Name:draft-campbell-oauth-resource-indicators
>>> Revision:00
>>> Title:Resource Indicators for OAuth 2.0
>>> Document date:2016-03-20
>>> Group:Individual Submission
>>> Pages:7
>>> URL:
>>>           =
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicat=
ors-00.txt
>>> Status:
>>>        =
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/=

>>> Htmlized:
>>>      =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00
>>>=20
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>>=20
>>> 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
>>> .
>>>=20
>>> The IETF Secretariat
>>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_301D73D6-BD98-4946-8A14-A584CA115574
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMjEwODA5MDdaMCMGCSqGSIb3DQEJBDEWBBS2yutCi0DVf7Y+SbVhV2LL
mrxrszCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQA8mboSYpW/Tp1yz2WYpGRdBlht2ao96M3k6WjObIWRJ6zD4o1w9z/O
yPSkTGJj2BGgzPku+BSaLqXhDXrabA7/FPLHPKnXFbxhFNTrOc5syTEmP1X2S4f6YsZK8BL6uS2f
BNdYBXUxjI0tbdLHCtX+h3idJLcXuM54+T0dxV9tdCwfLZfZNGab5jMH+RDFcgPmklZvzzBu8yKN
6Z3PEUG05MlW2aAXIm/SOdedwhethLozn7bmwRCt0r066SfKpG9dZsZparXwSWzUAaRmhFoSM/yW
ZChLmhIBOSXMAcNAm97e68G3CYlHKj72R3B6E2BN1FUqVjtKM+dVL8zdJrVEAAAAAAAA
--Apple-Mail=_301D73D6-BD98-4946-8A14-A584CA115574--


From nobody Mon Mar 21 01:47:58 2016
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 6118712D6F6 for ; Mon, 21 Mar 2016 01:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.101
X-Spam-Level: 
X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 LIr5LmfqcNxL for ; Mon, 21 Mar 2016 01:47:54 -0700 (PDT)
Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56D812D706 for ; Mon, 21 Mar 2016 01:47:53 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0078.outbound.protection.outlook.com [213.199.154.78]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-49-NuczpxNiSlyItwIZJEsd3g-1; Mon, 21 Mar 2016 08:47:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector1-arm-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TX5AeuTvEoGQFB4LyU2tU1mxC/ASugv0W7+8QDayY7o=; b=N3iV9vodMX88X6vl40o8rVMEzCQgdHAlH4e93y80qEDYGbRfVLRCz3rl9TilhQiBkwWfZ9PD29o9Ztuaxr0SXtlmTXEJ/gja5Ql5xVx982NJc72e39eHZ+rw5dR75zYWgj3+pEnwkPF9//iRI94ej0OtLqK6x3HLlsRp4YRO3AM=
Received: from AM4PR08MB1090.eurprd08.prod.outlook.com (10.167.91.144) by AM4PR08MB1092.eurprd08.prod.outlook.com (10.167.91.146) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 21 Mar 2016 08:47:49 +0000
Received: from AM4PR08MB1090.eurprd08.prod.outlook.com ([10.167.91.144]) by AM4PR08MB1090.eurprd08.prod.outlook.com ([10.167.91.144]) with mapi id 15.01.0434.021; Mon, 21 Mar 2016 08:47:49 +0000
From: Hannes Tschofenig 
To: John Bradley , Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
Thread-Index: AQHRgu36ts0EXZfJTU6RXY5Vtp4GI59jezsAgAAQyQCAAAmfEA==
Date: Mon, 21 Mar 2016 08:47:49 +0000
Message-ID: 
References: <20160320201414.8930.5136.idtracker@ietfa.amsl.com>  <56EF9E0E.6010404@gmx.net> <486347F9-07D0-4DB9-84AB-44FFFBCA2705@ve7jtb.com>
In-Reply-To: <486347F9-07D0-4DB9-84AB-44FFFBCA2705@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [193.171.77.3]
x-ms-office365-filtering-correlation-id: b170f20a-164b-49dd-2035-08d351657b65
x-microsoft-exchange-diagnostics: 1; AM4PR08MB1092; 5:BeFp0N6xwuoM4ewkJb6Zbfs7GMgr28kHqLwY9ZiBKitKYaza3yrvkHL5DtW7eOfZRX/zhvnDGsi1lGfTohW+w+LMdv8CyTc7kqxo5oTmOvn4UlA4p3UGHhwLmFDRKgAu+Np3eRCQvavZr5oxC4Q0HA==; 24:OHE8jtt3L7oQ5gtRUBAAdxNw9oF4j9Opu+AhbCLgKVCEvj/jRXs6L0ACUGXH9iErH9s27Itl04MV9uSZ542IYeaJX8+kjRFgluh2AABrgxw=; 20:0e3cOtSZ9MQvWgww49+KrgujHC+fNsaR6XoM7lLCz/4baz1sCGQr6X//nO8sh8QpeA87BDj+zdltbzSt6k5w2+/9u3Uwj5bTbAwu5hsyg1E+VPWsuumPGBrQtarQeJV5O37kPB5c6xIKtgyhip8nzElqKG2bJEiULsZp/I2qajg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR08MB1092;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM4PR08MB1092; BCL:0; PCL:0; RULEID:; SRVR:AM4PR08MB1092; 
x-forefront-prvs: 0888B1D284
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(40434004)(377424004)(24454002)(66066001)(3660700001)(54356999)(7110500001)(50986999)(122556002)(76176999)(106116001)(2906002)(189998001)(3280700002)(10400500002)(15650500001)(19580405001)(5004730100002)(86362001)(19580395003)(2420400007)(81166005)(87936001)(5890100001)(102836003)(3846002)(6116002)(77096005)(5003600100002)(76576001)(5001770100001)(5008740100001)(586003)(230783001)(74316001)(11100500001)(5002640100001)(15975445007)(33656002)(2900100001)(2950100001)(1096002)(1220700001)(92566002)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR08MB1092; H:AM4PR08MB1090.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 08:47:49.2049 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB1092
X-MC-Unique: NuczpxNiSlyItwIZJEsd3g-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 08:47:57 -0000

Hi John,

We certainly had some confusion about what is the best possible term for th=
e client to indicate to the resource server what RS it wants to access and =
for the AS to say what RS the client is allowed to access.

For me the inband approach (either by carrying the information in the AT or=
 by obtaining the information via token introspection in those cases where =
the AT is actually a reference rather than a self-contained token) is a use=
ful approach that should have actually provided by the OAuth spec from the =
first day onwards.

The reason draft-tschofenig-oauth-audience-00 was not advanced at that time=
 was that the group (at the time) wanted to include the functionality in th=
e PoP token work, as you are very well aware of. In the meanwhile it seems =
that the group had again changed their mind and wants to rather progress th=
e work as an independent doc.

Ciao
Hannes


-----Original Message-----
From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: 21 March 2016 09:09
To: Hannes Tschofenig
Cc: ; Hannes Tschofenig
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oa=
uth-resource-indicators-00.txt

Thanks Hannes

We should merge them they are very similar.

We made a distinction between the resource URI and the audience to try and =
avoid some confusion about overloading the term audience.

We also covered the security considerations around user hosted content and =
being specific about the resource to avoid leakage.

We were less concerned about talking about key material, or the type of tok=
en.

We wanted to be able to show the WG that audience restricting AT has differ=
ent and I argue better security properties than doing out of band discovery=
 of the resource to try and stop AT leakage.

John B.



> On Mar 21, 2016, at 7:09 AM, Hannes Tschofenig  wrote:
>
> FWIW: I also worth I wrote a draft a while ago about this topic:
> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>
> On 03/20/2016 10:17 PM, John Bradley wrote:
>> We have had a number of discussions  about splitting the audience part
>> of PoP key distribution out into it's own draft
>>
>> Phil also requested  a draft on how I propose propose that proper
>> audiencing of access tokens can mitigate against the threat of bearer
>> access token leakage.
>>
>> In response Brian Campbell and I have created a short 00 draft on how
>> the client can specify the resource that it is requesting a token for
>> without overloading scopes.
>>
>> I hope that this will make some of the issues clearer for our discussion=
.
>>
>> As Justin pointed out we may also want to separate out offline access
>> and some other common things from scope as well.  This is intended to
>> start the discussion not preclude other discussions around how to reduce
>> the overloading of scope.
>>
>> Regards
>> John Bradley
>>
>>
>>
>>> Begin forwarded message:
>>>
>>> *From: *internet-drafts@ietf.org 
>>> *Subject: **New Version Notification for
>>> draft-campbell-oauth-resource-indicators-00.txt*
>>> *Date: *March 20, 2016 at 8:14:14 PM GMT
>>> *To: *"Brian Campbell" >> >, "John Bradley"
>>> >
>>>
>>>
>>> A new version of I-D, draft-campbell-oauth-resource-indicators-00.txt
>>> has been successfully submitted by Brian Campbell and posted to the
>>> IETF repository.
>>>
>>> Name:draft-campbell-oauth-resource-indicators
>>> Revision:00
>>> Title:Resource Indicators for OAuth 2.0
>>> Document date:2016-03-20
>>> Group:Individual Submission
>>> Pages:7
>>> URL:
>>>           https://www.ietf.org/internet-drafts/draft-campbell-oauth-res=
ource-indicators-00.txt
>>> Status:
>>>        https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-i=
ndicators/
>>> Htmlized:
>>>      https://tools.ietf.org/html/draft-campbell-oauth-resource-indicato=
rs-00
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> 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
>>> .
>>>
>>> The IETF Secretariat
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

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.


From nobody Mon Mar 21 09:47:20 2016
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 8EF9912D8E0; Mon, 21 Mar 2016 09:47:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160321164715.31984.41236.idtracker@ietfa.amsl.com>
Date: Mon, 21 Mar 2016 09:47:15 -0700
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 16:47:15 -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 of the IETF.

        Title           : OAuth 2.0 Authorization Server Discovery Metadata
        Authors         : Michael B. Jones
                          Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-discovery-02.txt
	Pages           : 23
	Date            : 2016-03-21

Abstract:
   This specification defines a discovery metadata format that an OAuth
   2.0 client can use to obtain the information needed to interact with
   an OAuth 2.0 authorization server, including its endpoint locations
   and authorization server capabilities.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-02

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


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 Mon Mar 21 10:42:03 2016
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 D8E2C12D97C for ; Mon, 21 Mar 2016 10:42:01 -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=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 H8JouFJ_hNMw for ; Mon, 21 Mar 2016 10:42:00 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 01ABD12D9B0 for ; Mon, 21 Mar 2016 10:41:42 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id nk17so76547928igb.1 for ; Mon, 21 Mar 2016 10:41:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=w9qq9qMUdW9lX3RQa38HDCvPY0xngp1tOH3hq8A1OUE=; b=B/NaU7BSXYuIMzPH2Ofwo76UKfwDOh7AsRex74PBpLuHHAMd0lA3QGJMwRl1vT2Ndf rz1M8sda2vIC+UOQ4cZKHptNO3agCkZxk4xwOaXGJrXwMZmVqJ2a8Fkv2kfhIf5OMtEI yU2PrC+dwR2MiCvPEdXsPHZSHTp0O2wF9EqE4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=w9qq9qMUdW9lX3RQa38HDCvPY0xngp1tOH3hq8A1OUE=; b=HtMYkBagniGKom9xzJmazq47gNr8Qoe/GXOakaiX6bqdKVbv393JPPA9/zmp8c5kXr 1m0B+OyRaqbgq+GwGPSIzeP2MuRqDArzVF8PRHH6YkpQXOYntE+oKUjAu5Gl6lMppTEc tMq0cj0j5WudKWHuG6wSHueVN2agBlSHUmzCnut9kscA2aFbnO3vnEPQipLlXY49c/vQ mx3/N63/zl/hKwppZqrQvei2Au0fCA/pEZe4KmOGYZOtDQ8iZ0xhwshAaEbCbmbELjnh EGEoDqDXB+9WLncHVEMtAWRtCIM9DAfb97zz8w7Xx1g0QD4b7mxI4AVdLgROP8xUBLTu 4imA==
X-Gm-Message-State: AD7BkJICG9XktgMyGYn0DU9Fdltl4ZIO/5rxX3t+/9CzRPgo2BrLq8/khOnmuj/X8Ky0WQK0VzFPhp7WjDEqCSkM
X-Received: by 10.50.50.198 with SMTP id e6mr13598002igo.57.1458582102008; Mon, 21 Mar 2016 10:41:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Mon, 21 Mar 2016 10:41:12 -0700 (PDT)
In-Reply-To: 
References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com> 
From: Brian Campbell 
Date: Mon, 21 Mar 2016 11:41:12 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=047d7bd75df21102ca052e929cae
Archived-At: 
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 17:42:02 -0000

--047d7bd75df21102ca052e929cae
Content-Type: text/plain; charset=UTF-8

Very minor update to this draft before the deadline that moves Hannes from
Acknowledgements to Authors in acknowledgment of his similar work a few
years ago. Also fleshed out the IANA section with the formal registration
requests.


---------- Forwarded message ----------
From: 
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
To: Hannes Tschofenig , Hannes Tschofenig <
Hannes.Tschofenig@gmx.net>, Brian Campbell ,
John Bradley 



A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-campbell-oauth-resource-indicators
Revision:       01
Title:          Resource Indicators for OAuth 2.0
Document date:  2016-03-21
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
Status:
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
Htmlized:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01

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.




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.

The IETF Secretariat

--047d7bd75df21102ca052e929cae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Very minor update to this draft before the deadline that m=
oves Hannes from Acknowledgements to Authors in acknowledgment of his simil=
ar work a few years ago. Also fleshed out the IANA section with the formal =
registration requests. 


    ---------- Forwarded message ----------=

    From:  <internet-drafts@ietf=
.org>
    Date: Mon, Mar 21, 2016 at 11:31 AM
    Subject: New =
Version Notification for draft-campbell-oauth-resource-indicators-01.txtTo: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Hannes Tschofenig <Hannes.Tschofen=
ig@gmx.net>, Brian Campbell <brian.d.campbell@gmail.com>, John Bradle=
y <ve7jtb@ve7jtb.=
com>



    
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
    
has been successfully submitted by Brian Campbell and posted to the
    
IETF repository.
    

    
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-resource=
-indicators
    
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
    
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resource Indicators for OAuth 2.0<=
br>
Document date:=C2=A0 2016-03-21
    
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
    
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ca=
mpbell-oauth-resource-indicators-01.txt
    
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-resour=
ce-indicators/
    
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators=
-01
    
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell=
-oauth-resource-indicators-01
    

    
Abstract:
    
=C2=A0 =C2=A0This straw-man specification defines an extension to The OAuth=
 2.0
    
=C2=A0 =C2=A0Authorization Framework that enables the client and authorizat=
ion
    
=C2=A0 =C2=A0server to more explicitly to communicate about the protected
=C2=A0 =C2=A0resource(s) to be accessed.
    

    

    

    

    
Please note that it may take a couple of minutes from the time of submissio=
n
    
until the htmlized version and diff are available at tools.ietf.org.
    

    
The IETF Secretariat
    

    


    


    

--047d7bd75df21102ca052e929cae--


From nobody Mon Mar 21 13:15:54 2016
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 8565812DB4C for ; Mon, 21 Mar 2016 13:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 wYrf32s-6xqN for ; Mon, 21 Mar 2016 13:15:50 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A50112DB41 for ; Mon, 21 Mar 2016 13:15:32 -0700 (PDT)
Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lm2lZ-1a9JeD3qFd-00ZdX3 for ; Mon, 21 Mar 2016 21:15:29 +0100
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56F05664.1010507@gmx.net>
Date: Mon, 21 Mar 2016 21:15:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IGxRXQ6hRTvnCFFuU6Hec19ado7ma6XHE"
X-Provags-ID: V03:K0:1oN4fckbNBxjZb8GCeFSFbq3AmnFUdi3VI6+gYNiLGwXltec2Sp OzktmtDBYB7IWLOYW537z55WfOGd3dPxXiE8P2WuSum55eCAw0/Il/4oj+KcKKmZwrk+lSC +7MynbN3er2jPVcYkY5iRuE0AMRyS0/mZfFiJhD9NfjATAHP3qjhJnJNj88HX5Rc4RX9ECJ kQOVVMa40fAYh6htz8Pdg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:xvSQCFSarbI=:lGxkCQ5EUAm7QNyANYGDUg 83Hwg094queLJV8urk5aSEFjA8miqBprfFQcK9Qm3Mgvq5i7OGnDQR5IyhO105Fal7MdYbiTn zYlMGCayNic0aSsbfrQ/EoVuR84JpjSq7aMwaLkEoh6aZUPPPPyLmDV0ZH13+mReCIV69yqif reaNhcEQbQO7Cj839+Q9GrurZjXY4UARQcNI9MgutbYws67+fbmi2VsxAl3z/Q8wjzBkpHcx3 MKWeWXkeVgwco0NueiAzOSZSZUDylRFTCA59w5UT5kLu9669JG3LGCjTuXwLrhcBZoLohvnpG IseKYwhBIBixRXlpqot2vTlmnDnnCIszMT2EnlfLKOU0ZEVu9tahgzKXr/zVRKCph4XdHY+2r ZuNBFNYtgVaiMjHJ2PZvL71QLltAwCdkqQDyu9wvLd6ZsulfdNC8mKcjEhytxj9kqawsi+QCB 4Zau8+zoYC6lCXHXMqeRere4UzMG9HtFKCkTpakWFN3LkmeKSvYLfXXYEmEs2Ml6Na8oknY7Q NyW6MCGXXoQTUYsn6gh7nlzXFL5RbZ7ZjjTHeDHWXaAM0inCWp5IAL1OFIN03CoRyTTad34fL fZGc6SVfCMe7FumUBaRQgwgeJTHm3FbXJG7AxADicmdMRwO2ivlpPuyxBSKXZkLqYrADKMNUA Cz48hVgITxnacB8MK05RSvP60nw6IyPa3bwnRa0tfn3xX+wxmcN+LyalcoU23X/yYZ4Lg39Pr CIFnlUMC4hSzDRQ9bKkZfmI+ADAqXUgMFYGnDzG+sfBPTu/h5t+U0p4m0ew=
Archived-At: 
Subject: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 20:15:52 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IGxRXQ6hRTvnCFFuU6Hec19ado7ma6XHE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

I need your help creating the agenda for the next meeting. We have a 2
1/2 hour slot and many different topics to discuss. I put a strawman
proposal together but there are various things missing:

* who volunteers to present and to lead the discussion,
* what time allocation is appropriate,
* what you are trying to accomplish during the meeting (goals), and
* what other items would you like to discuss (I know there are various
items missing from the list).

So, you input is needed!

-------

IETF 95 OAuth Meeting Agenda
Wednesday, 10:00-12:30
Chairs: Hannes Tschofenig/Derek Atkins

- Status Update (Hannes, 5 min)

- OAuth 2.0 JWT Authorization Request (Nat, 15 min )
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

- OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/

- Proof-of-Possession (TBD, 35 min)
http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

- Token Exchange (TBD, 15 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/

- OAuth 2.0 for Native Apps (William, 15 min)
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/

- Authentication Method Reference Values (Mike, 15 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/

- Conclusion (Hannes, 5 min)

-------

The latest version can be found at:
https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth

Ciao
Hannes & Derek


--IGxRXQ6hRTvnCFFuU6Hec19ado7ma6XHE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW8FZkAAoJEGhJURNOOiAtHo4H/iRNcJ+L2faHXiUbtKgM2EiX
cf1ManYkWshHc4062qNljtI7oz4efNzfCMO/GUnrp1LfKaY3rTwTsuX80kBIq4uV
tZ+DA34GFMLao2UvENIY2tYQtILGBmp9CCu+X4UkV5wsza/t5QDib9U7/lOWnHfJ
Jl7BO4ZlVq0FCmbUovmqd7dR6z7YfO099U6t2QGwZqzUcjnMLTdgvMBffAGH3M8K
dj+KeBV5gIIfM8MkQrknfkkkka3T2csVTy2zekCfnlJ3hS0HCVEg3N2tnAxjT2gL
Bxjm7BgxuWCE/DmIWJLHwRhOqbh8AVbG1mONjkhMEocdLMAJOFcPFiB0W+ByT5c=
=XqWF
-----END PGP SIGNATURE-----

--IGxRXQ6hRTvnCFFuU6Hec19ado7ma6XHE--


From nobody Mon Mar 21 13:16:08 2016
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 51BD312DB50 for ; Mon, 21 Mar 2016 13:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 LdpCkpsQHWCz for ; Mon, 21 Mar 2016 13:15:52 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 8C1CC12DB4A for ; Mon, 21 Mar 2016 13:15:37 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2LKFaLd032353 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2016 20:15:37 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2LKFaUx001291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2016 20:15:36 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2LKFaSM030730; Mon, 21 Mar 2016 20:15:36 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Mar 2016 13:15:36 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_7918E253-4CFD-4F54-A9B2-1FA734F859D3"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Mon, 21 Mar 2016 13:15:34 -0700
Message-Id: <0DBACD62-E2FB-43D2-A2F6-F1A16794117A@oracle.com>
References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com>  
To: Brian Campbell 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 20:15:57 -0000

--Apple-Mail=_7918E253-4CFD-4F54-A9B2-1FA734F859D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

What about server processing rules and error conditions?  The client =
passes the resource in with every request. What happens if it sends a =
bad URL.  I see the registration for invalid_resource, but I see no =
processing logic for the server that describes when that is returned.  =
I=E2=80=99ll assume that is TBD.

The draft seems more finer grained than with bound configuration =
approach.  It suggests that the client will make a different URL request =
for each resource URL. This could lead to a lot of unnecessary =
authorizations.  I think we still have to resolve the audience to =
resource relationship problem and just how much detail the AS service =
needs to know.

I note that we have a similar issue with bound config on how granular =
resource URL processing is needed.  My main goal is for config to =
validate the domain name only as a major improvement as we just need to =
make sure the client is talking to a valid server and not a MITM proxy.

Finally, there is the question of optionality (in order to have =
backwards compatibility for static clients). If resource is optional, =
than how do we deal with dynamic clients that simply don=E2=80=99t both =
to use the resource parameter? =20

We=E2=80=99re depending on client developers taking an extra step to =
provide the resource parameter. Maybe optionality for resource url =
becomes part of the client_id registration?  In contrast, config =
discovery is brand new, so making validation required is not such a big =
deal as static clients wouldn=E2=80=99t use discovery.

Another failure condition both drafts should consider: =20
* when an authorization, token, or resource endpoint starts to fail, =
should the client fall back to discovery to re-verify configuration?  If =
so, on what errors?  A valid usecase would be a service provider =
deciding to re-configure its services naturally over time. =20
* what are the issues when an endpoint that was part of configuration =
issues a re-direct? There are good and bad scenarios (e.g. to a specific =
cluster node), a resource that was relocated, or a hacked service that =
wants to steal tokens.  In these cases, should the client re-validate =
the new resource URI either using this draft or the bound config method?

On a positive note, unrelated to security, there have been a lot of =
inquiries over the years about how to authorize against on user-owned =
resources.  E.g. How can I ask for authorizations to Brian=E2=80=99s =
github project?  I think this is worth discussing.  Weighing the =
security and functionality needs would be a worthwhile discussion in BA.

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 21, 2016, at 10:41 AM, Brian Campbell =
 wrote:
>=20
> Very minor update to this draft before the deadline that moves Hannes =
from Acknowledgements to Authors in acknowledgment of his similar work a =
few years ago. Also fleshed out the IANA section with the formal =
registration requests.=20
>=20
>=20
> ---------- Forwarded message ----------
> From: >
> Date: Mon, Mar 21, 2016 at 11:31 AM
> Subject: New Version Notification for =
draft-campbell-oauth-resource-indicators-01.txt
> To: Hannes Tschofenig >, Hannes Tschofenig =
>, Brian =
Campbell >, John Bradley >
>=20
>=20
>=20
> A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>=20
> Name:           draft-campbell-oauth-resource-indicators
> Revision:       01
> Title:          Resource Indicators for OAuth 2.0
> Document date:  2016-03-21
> Group:          Individual Submission
> Pages:          8
> URL:            =
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicat=
ors-01.txt =

> Status:         =
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/=
 =

> Htmlized:       =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 =

> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-resource-indicato=
rs-01 =

>=20
> 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.
>=20
>=20
>=20
>=20
> 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 =
.
>=20
> The IETF Secretariat
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_7918E253-4CFD-4F54-A9B2-1FA734F859D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

What about server processing rules and error conditions? =
 The client passes the resource in with every request. What happens =
if it sends a bad URL.  I see the registration for =
invalid_resource, but I see no processing logic for the server that =
describes when that is returned.  I=E2=80=99ll assume that is =
TBD.

    The draft seems =
more finer grained than with bound configuration approach.  It =
suggests that the client will make a different URL request for each =
resource URL. This could lead to a lot of unnecessary authorizations. =
 I think we still have to resolve the audience to resource =
relationship problem and just how much detail the AS service needs to =
know.

    I note =
that we have a similar issue with bound config on how granular resource =
URL processing is needed.  My main goal is for config to validate =
the domain name only as a major improvement as we just need to make sure =
the client is talking to a valid server and not a MITM proxy.

    Finally, there is the =
question of optionality (in order to have backwards compatibility for =
static clients). If resource is optional, than how do we deal with =
dynamic clients that simply don=E2=80=99t both to use the resource =
parameter?  

    We=E2=80=99re depending on client developers taking an extra =
step to provide the resource parameter. Maybe optionality for resource =
url becomes part of the client_id registration?  In contrast, =
config discovery is brand new, so making validation required is not such =
a big deal as static clients wouldn=E2=80=99t use discovery.

    Another failure =
condition both drafts should consider:  
    * =
when an authorization, token, or resource endpoint starts to fail, =
should the client fall back to discovery to re-verify configuration? =
 If so, on what errors?  A valid usecase would be a service =
provider deciding to re-configure its services naturally over time. =
 
    * what are the issues when an endpoint that =
was part of configuration issues a re-direct? There are good and bad =
scenarios (e.g. to a specific cluster node), a resource that was =
relocated, or a hacked service that wants to steal tokens.  In =
these cases, should the client re-validate the new resource URI either =
using this draft or the bound config method?

    On a =
positive note, unrelated to security, there have been a lot of inquiries =
over the years about how to authorize against on user-owned resources. =
 E.g. How can I ask for authorizations to Brian=E2=80=99s github =
project?  I think this is worth discussing.  Weighing the =
security and functionality needs would be a worthwhile discussion in =
BA.

    


    

    

    On Mar 21, 2016, at 10:41 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

    Very minor update to this draft before the deadline that =
moves Hannes from Acknowledgements to Authors in acknowledgment of his =
similar work a few years ago. Also fleshed out the IANA section with the =
formal registration requests. 


    ---------- Forwarded message =
----------
    From:  <internet-drafts@ietf.org>
    Date: Mon, Mar 21, 2016 at 11:31 AM
    Subject: =
New Version Notification for =
draft-campbell-oauth-resource-indicators-01.txt
    To: Hannes =
Tschofenig <hannes.tschofenig@gmx.net>, Hannes =
Tschofenig <Hannes.Tschofenig@gmx.net>, Brian =
Campbell <brian.d.campbell@gmail.com>, John =
Bradley <ve7jtb@ve7jtb.com>



    
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
    
has been successfully submitted by Brian Campbell and posted to the
    
IETF repository.
    

    
Name:          =
 draft-campbell-oauth-resource-indicators
    
Revision:       01
    
Title:          Resource Indicators for OAuth =
2.0
    
Document date:  2016-03-21
    
Group:          Individual Submission
    
Pages:          8
    
URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-resou=
rce-indicators-01.txt
    
Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-=
indicators/
    
Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-resource-indic=
ators-01
    
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-resour=
ce-indicators-01
    

    
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.
    

    

    

    

    
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.
    

    
The IETF Secretariat
    

    


    


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

    =

--Apple-Mail=_7918E253-4CFD-4F54-A9B2-1FA734F859D3--


From nobody Mon Mar 21 13:46:28 2016
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 0596812DB61 for ; Mon, 21 Mar 2016 13:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 QUY2jV2HgLI0 for ; Mon, 21 Mar 2016 13:46:24 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 1156412D93E for ; Mon, 21 Mar 2016 13:46:24 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2LKkLjY004023 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Mar 2016 20:46:22 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2LKkLv9010731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2016 20:46:21 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2LKkLqX026240; Mon, 21 Mar 2016 20:46:21 GMT
Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Mar 2016 13:46:20 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_B3D0B7EC-B816-42EF-8678-A32F6E49020D"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <56F05664.1010507@gmx.net>
Date: Mon, 21 Mar 2016 13:46:19 -0700
Message-Id: <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com>
References: <56F05664.1010507@gmx.net>
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 20:46:26 -0000

--Apple-Mail=_B3D0B7EC-B816-42EF-8678-A32F6E49020D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99m not sure you intend to discuss it in the Mix-up section, but =
I think we need time to discuss the correct configuration of clients and =
the resource/aud relationship issues (specifically: =
draft-campbell-oauth-resource-indicators =
=
 and draft-hunt-oauth-bound-config =
).

There is apparently overlap with mix-up mitigation (either in reality or =
perception), so I think it is important to have a verbal discussion on =
this to get to consensus and understanding of the separate issues.

As for POP-architecture, that has been on hold pending the mix-up =
discussions and understanding of dynamic client risks.  So, not much =
need to discuss from my perspective.

Thanks,

Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig =
 wrote:
>=20
> Hi all,
>=20
> I need your help creating the agenda for the next meeting. We have a 2
> 1/2 hour slot and many different topics to discuss. I put a strawman
> proposal together but there are various things missing:
>=20
> * who volunteers to present and to lead the discussion,
> * what time allocation is appropriate,
> * what you are trying to accomplish during the meeting (goals), and
> * what other items would you like to discuss (I know there are various
> items missing from the list).
>=20
> So, you input is needed!
>=20
> -------
>=20
> IETF 95 OAuth Meeting Agenda
> Wednesday, 10:00-12:30
> Chairs: Hannes Tschofenig/Derek Atkins
>=20
> - Status Update (Hannes, 5 min)
>=20
> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>=20
> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
>=20
> - Proof-of-Possession (TBD, 35 min)
> http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>=20
> - Token Exchange (TBD, 15 min)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>=20
> - OAuth 2.0 for Native Apps (William, 15 min)
> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>=20
> - Authentication Method Reference Values (Mike, 15 min)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>=20
> - Conclusion (Hannes, 5 min)
>=20
> -------
>=20
> The latest version can be found at:
> https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth
>=20
> Ciao
> Hannes & Derek
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_B3D0B7EC-B816-42EF-8678-A32F6E49020D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I=E2=80=99m not sure you intend to discuss it in the Mix-up =
section, but I think we need time to discuss the correct configuration =
of clients and the resource/aud relationship issues =
(specifically: draft-campbell-oauth-resource-indicators and draft-hunt-oauth-bound-config).

    There is apparently overlap with mix-up =
mitigation (either in reality or perception), so I think it is important =
to have a verbal discussion on this to get to consensus and =
understanding of the separate issues.

    As for POP-architecture, that has been =
on hold pending the mix-up discussions and understanding of dynamic =
client risks.  So, not much need to discuss from my =
perspective.

    Thanks,

    


    

    

    On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

    Hi =
all,

    I need your help creating the agenda =
for the next meeting. We have a 2
    1/2 hour slot and many =
different topics to discuss. I put a strawman
    proposal =
together but there are various things missing:

    * who volunteers to present and to lead the discussion,
    * what time allocation is appropriate,
    * what =
you are trying to accomplish during the meeting (goals), and
    * what other items would you like to discuss (I know there =
are various
    items missing from the list).

    So, you input is needed!

    -------

    IETF 95 OAuth Meeting =
Agenda
    Wednesday, 10:00-12:30
    Chairs: Hannes =
Tschofenig/Derek Atkins

    - Status Update =
(Hannes, 5 min)

    - OAuth 2.0 JWT =
Authorization Request (Nat, 15 min )
    https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
    - OAuth 2.0 Mix-Up Mitigation (TBD, 45 =
min)
    https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitiga=
tion/

    - Proof-of-Possession (TBD, 35 =
min)
    http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-posse=
ssion/
    http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architectu=
re/
    http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distri=
bution/
    https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-r=
equest/

    - Token Exchange (TBD, 15 min)
    https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchang=
e/

    - OAuth 2.0 for Native Apps (William, 15 =
min)
    http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-app=
s/

    - Authentication Method Reference Values =
(Mike, 15 min)
    https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
    - Conclusion (Hannes, 5 min)
    -------

    The latest version can =
be found at:
    https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth

    Ciao
    Hannes & Derek

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

    =

--Apple-Mail=_B3D0B7EC-B816-42EF-8678-A32F6E49020D--


From nobody Mon Mar 21 14:47:53 2016
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 E175612D0CB for ; Mon, 21 Mar 2016 14:47:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ve7jtb-com.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 lT8RP_EhfcKn for ; Mon, 21 Mar 2016 14:47:40 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 DF58812D09F for ; Mon, 21 Mar 2016 14:47:26 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id l68so168510983wml.0 for ; Mon, 21 Mar 2016 14:47:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=7dcmI7vqbJD+gY35yd0UfYVtTuEK9xXgSwRk/6+ROt8=; b=e86zBQty3Q4fAW5G5G3f4Kl60cLS0KaC1Q39PWkvUyN4CHawPlafN1sxrDQXxAv/Go ois3udBNJHmDQlSEmog56GGbUuDX18RS4qerkj6KJ/jX9JrL1mQSRLaV6T7HHS4SQFFz gUWumdrg/7YBeTSdJoatXc6t+HK8tyGmXnp9Wdnml5l8mcB+YdDsSYUMV8BNXOc5T5vj QPCLcic0IZMrf8TDBkQQTD80bD1RcC5Unt6ZG3ER0ha2V4rg2PxzKQqdnZpBR9ja7yXx 6RvbQgb6FBiuW977Ibxf0e5Ka6WrF7MNkMQG8Tbo4YenTsGcPJixzIT4CGegLPqr8hg2 j1CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7dcmI7vqbJD+gY35yd0UfYVtTuEK9xXgSwRk/6+ROt8=; b=j0PdV/7tWm3QsloBmKtr6SGBcCb9m7NY1Ni+PyvAvzNuHJyVmLjDwT4PnzSO9QW41j NV5EfJskhy2ifWHpp2V0sBZHSw1V4NeBCRc7/2NgKwzcyK9ZMn76BZDSzG6upv12lFf1 S+e/kMXmUJssTljknTJdLLXC7PJc+uFCq6hq3RjjKTcku7XP0cpI7SCjGzdhmi044RwL OZBmZmBa6cIPsue57Vkhy74nM6z01YnZdPQD1/IOmAwfdsg156q7QdFqVr1vW5RBMNvh OKTO4Cxzlh0MzBz1Q7f221pvZN0lX3k2FoJhYtM/MM9lB87O3P86dIOX/8QgBFyUC6ZQ CRzA==
X-Gm-Message-State: AD7BkJKLfo86Mj7je2nRLoJ6zWSWaGvU1CGiSGTzI+hri+1mv+hzAlNYzr0QG2FiJMhmGg==
X-Received: by 10.194.60.44 with SMTP id e12mr32480972wjr.137.1458596845345; Mon, 21 Mar 2016 14:47:25 -0700 (PDT)
Received: from [10.143.194.212] ([31.55.56.113]) by smtp.gmail.com with ESMTPSA id w188sm14285292wmw.19.2016.03.21.14.47.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Mar 2016 14:47:23 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_524EAA9C-7D22-4A93-B4D3-3A1AC332AC19"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com>
Date: Mon, 21 Mar 2016 21:47:22 +0000
Message-Id: <16BDBD68-0851-4650-850E-454EE7D3ABE6@ve7jtb.com>
References: <56F05664.1010507@gmx.net> <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 21:47:43 -0000

--Apple-Mail=_524EAA9C-7D22-4A93-B4D3-3A1AC332AC19
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4B807AA7-07C4-41E9-BCAF-73A259B90203"


--Apple-Mail=_4B807AA7-07C4-41E9-BCAF-73A259B90203
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

For mix up we have the mix-up mitigation draft,  and the question of if =
the mitigation for the cut and paste attack should stay as part of that =
or be separate.

There are the two drafts that attempt to prevent leakage of bearer AT by =
the RS.
  =20
We don=E2=80=99t necessarily have consensus yet on if this is a real =
problem that OAuth needs to solve vs the API/Application using OAuth, as =
OAuth itself doesn=E2=80=99t say anything about how the client learns =
about the RS other than developer config out of band.

I can try and lead all or part of it.

John B.

> On Mar 21, 2016, at 8:46 PM, Phil Hunt  wrote:
>=20
> I=E2=80=99m not sure you intend to discuss it in the Mix-up section, =
but I think we need time to discuss the correct configuration of clients =
and the resource/aud relationship issues (specifically: =
draft-campbell-oauth-resource-indicators =
=
 and draft-hunt-oauth-bound-config =
).
>=20
> There is apparently overlap with mix-up mitigation (either in reality =
or perception), so I think it is important to have a verbal discussion =
on this to get to consensus and understanding of the separate issues.
>=20
> As for POP-architecture, that has been on hold pending the mix-up =
discussions and understanding of dynamic client risks.  So, not much =
need to discuss from my perspective.
>=20
> Thanks,
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig =
> wrote:
>>=20
>> Hi all,
>>=20
>> I need your help creating the agenda for the next meeting. We have a =
2
>> 1/2 hour slot and many different topics to discuss. I put a strawman
>> proposal together but there are various things missing:
>>=20
>> * who volunteers to present and to lead the discussion,
>> * what time allocation is appropriate,
>> * what you are trying to accomplish during the meeting (goals), and
>> * what other items would you like to discuss (I know there are =
various
>> items missing from the list).
>>=20
>> So, you input is needed!
>>=20
>> -------
>>=20
>> IETF 95 OAuth Meeting Agenda
>> Wednesday, 10:00-12:30
>> Chairs: Hannes Tschofenig/Derek Atkins
>>=20
>> - Status Update (Hannes, 5 min)
>>=20
>> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ =

>>=20
>> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
>>=20
>> - Proof-of-Possession (TBD, 35 min)
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>> =
http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
>> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>>=20
>> - Token Exchange (TBD, 15 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>=20
>> - OAuth 2.0 for Native Apps (William, 15 min)
>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>>=20
>> - Authentication Method Reference Values (Mike, 15 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>=20
>> - Conclusion (Hannes, 5 min)
>>=20
>> -------
>>=20
>> The latest version can be found at:
>> https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth
>>=20
>> Ciao
>> Hannes & Derek
>>=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=_4B807AA7-07C4-41E9-BCAF-73A259B90203
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

For mix up we have the mix-up mitigation draft,  and the =
question of if the mitigation for the cut and paste attack should stay =
as part of that or be separate.

    There are the two drafts that attempt to prevent leakage of =
bearer AT by the RS.
       
    We don=E2=80=99t necessarily have consensus yet on if this is =
a real problem that OAuth needs to solve vs the API/Application using =
OAuth, as OAuth itself doesn=E2=80=99t say anything about how the client =
learns about the RS other than developer config out of band.

    I can try and lead all =
or part of it.

    John B.

    On Mar 21, 2016, at 8:46 PM, =
Phil Hunt <phil.hunt@oracle.com> wrote:

    I=E2=80=99m =
not sure you intend to discuss it in the Mix-up section, but I think we =
need time to discuss the correct configuration of clients and the =
resource/aud relationship issues (specifically: draft-campbell-oauth-resource-indicators and draft-hunt-oauth-bound-config).

    There is apparently overlap with mix-up =
mitigation (either in reality or perception), so I think it is important =
to have a verbal discussion on this to get to consensus and =
understanding of the separate issues.

    As for POP-architecture, that has been =
on hold pending the mix-up discussions and understanding of dynamic =
client risks.  So, not much need to discuss from my =
perspective.

    Thanks,

    




    

    

    On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

    Hi =
all,

    I need your help creating the agenda =
for the next meeting. We have a 2
    1/2 hour slot and many =
different topics to discuss. I put a strawman
    proposal =
together but there are various things missing:

    * who volunteers to present and to lead the discussion,
    * what time allocation is appropriate,
    * what =
you are trying to accomplish during the meeting (goals), and
    * what other items would you like to discuss (I know there =
are various
    items missing from the list).

    So, you input is needed!

    -------

    IETF 95 OAuth Meeting =
Agenda
    Wednesday, 10:00-12:30
    Chairs: Hannes =
Tschofenig/Derek Atkins

    - Status Update =
(Hannes, 5 min)

    - OAuth 2.0 JWT =
Authorization Request (Nat, 15 min )
    https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
    - OAuth 2.0 Mix-Up Mitigation (TBD, 45 =
min)
    https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitiga=
tion/

    - Proof-of-Possession (TBD, 35 =
min)
    http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-posse=
ssion/
    http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architectu=
re/
    http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distri=
bution/
    https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-r=
equest/

    - Token Exchange (TBD, 15 min)
    https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchang=
e/

    - OAuth 2.0 for Native Apps (William, 15 =
min)
    http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-app=
s/

    - Authentication Method Reference Values =
(Mike, 15 min)
    https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
    - Conclusion (Hannes, 5 min)
    -------

    The latest version can =
be found at:
    https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth

    Ciao
    Hannes & Derek

    _______________________________________________
    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

    =

--Apple-Mail=_4B807AA7-07C4-41E9-BCAF-73A259B90203--

--Apple-Mail=_524EAA9C-7D22-4A93-B4D3-3A1AC332AC19
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAzMjEyMTQ3MjNaMCMGCSqGSIb3DQEJBDEWBBQSiFUE9h1ZkCYU41qxlSh5
bMcTJDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAlPkOGR3w3pCzgoWKF3JKWeLyUramhrra6Zsc+1MTlhjD7+wFCTUzZ
V8XzQK40DRwacLuYKb0xYl5tKVhcpPVch9ro/Q9cQ07+up/U47MD5c7k1WcpElcj1iJKuUAF0aWN
jVY3PIn542elF2EJSleHkDqgbN4L05Kv80jfNmxI4KdDNoeOzRieLYM+liScH0Xo9NWmWwdIkh1n
QlSHE373hc2CsGaVN9eiC77jOYaqNy6Xhknjw4eqYqQWHBjIAuiJxr+7rZ+X/nAf5JNLQIFuIVgw
BVCXekWI+OzW04MMeAjf+jWkdrVtXO1p/DKyNGm0rns2zqVsIXJTmhI60s3YAAAAAAAA
--Apple-Mail=_524EAA9C-7D22-4A93-B4D3-3A1AC332AC19--


From nobody Mon Mar 21 15:18:45 2016
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 85D0E12D0BF for ; Mon, 21 Mar 2016 15:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 CYAzKWW-Kgw4 for ; Mon, 21 Mar 2016 15:18:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E203B12D119 for ; Mon, 21 Mar 2016 15:18:22 -0700 (PDT)
Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MdaiW-1aPMJg1oVQ-00PNKi; Mon, 21 Mar 2016 23:18:16 +0100
To: Phil Hunt 
References: <56F05664.1010507@gmx.net> <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56F0732B.7090600@gmx.net>
Date: Mon, 21 Mar 2016 23:18:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h4FuclXRrQ4hKNATO83TiTeJ9adsrowS9"
X-Provags-ID: V03:K0:Z42buL7JFL6yWm9LZLnL3U+bZ2o+yiBgH156nwt8juCFNej6z6y c5EIHaFnWHRNyUu2oJR3qp51il+c7juACBlu0XtkOXmd2bJYlYtnk59K9Gk/NcHOLvqFkVy bheY2b61ryqOVU1xTKGFmddUlcT5TPJ3CBTPdG88PGyDsbhxCqIm2ABHq66+wa/HYJApxZH ObaSlfBxhtEYxV4iwnjlg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:jc+KlT35RYA=:CR8OeLPVc0Y6g5dLoZudYb cLtbGK7DRQZv9QZ1k+2UuV9f/ZrKXfHmqiwq7YVzRbXejUGxg2RtNqjAJtAg9vjcy2xR/fDfR jqeI2AIN94FSq0bV0ZwzmilTEseta4X2Uob8pbK08+W2YJu9ZN8q7SwgV3IUFw2qvB9shn0w8 ay1ZUFNYyEaOKk50+oly3/z1ISAy8J/I3FQzrHC0R3fTXMdeKPkYF1d2VuQ6rZE+/Br8mC7nN Ayk9K6br9t5rPZBUhvXG+loBqODG8Fd8+ejnwwCY708f2d0qsMFSQCVbxcKr9TDyF0BSMSieu KIbTsj79zeWBB5V2EfAHqJBSgysLfl2HBD779rHhKTWPQqJl9EgKh6sUoRzrVk3eXGwmff1Nz XBepv1s/z4Bw03c8v6l0WDgi/YaBvb6XDi0nWnQfuD2UjG9aWgK8g/+/kyrOaWL0hWIrXBqpo oppWj0Przi1A28G35o7q5Hvw3k1ukZ6T4+cPUbs8cZJlho4alk0mSDpQG0ROlHu0e8XK1Iawe acU6Jqs5BzJZl//pogLDMlKoyV+yYH6lgl8d1V6DYuvipgOH+67HvojAmAAAX6s2atSkyQ2x5 q5vzVjTYYavoEGlDaSGiNZGX7pvtUDf5vvP2N/wTj6Rrq1siYFi07cHvAkY01VSHsFMqXJ3rh KoEa/PLM45slRy4FhLmrNDPPITciLoyn5Efyk8uRFJuglxCypGOUIHh80ufbzoiChFXPTHEQK NgJMw7YzejYE+ez9VK9baZHUXsI5krGH/m5ekcDbvrPz6YNPmGTTX87TKvw=
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 22:18:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--h4FuclXRrQ4hKNATO83TiTeJ9adsrowS9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Phil,

we can put this topic as an additional agenda item to the list by
removing time from the PoP and the mix-up agenda items

Ciao
Hannes

On 03/21/2016 09:46 PM, Phil Hunt wrote:
> I=E2=80=99m not sure you intend to discuss it in the Mix-up section, bu=
t I think
> we need time to discuss the correct configuration of clients and the
> resource/aud relationship issues
> (specifically: draft-campbell-oauth-resource-indicators
>  and draft-hunt-oauth-bound-config
> ).
>=20
> There is apparently overlap with mix-up mitigation (either in reality o=
r
> perception), so I think it is important to have a verbal discussion on
> this to get to consensus and understanding of the separate issues.
>=20
> As for POP-architecture, that has been on hold pending the mix-up
> discussions and understanding of dynamic client risks.  So, not much
> need to discuss from my perspective.
>=20
> Thanks,
>=20
> Phil
>=20
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>=20
>=20
>=20
>=20
>=20
>> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig
>> > wrote:
>>
>> Hi all,
>>
>> I need your help creating the agenda for the next meeting. We have a 2=

>> 1/2 hour slot and many different topics to discuss. I put a strawman
>> proposal together but there are various things missing:
>>
>> * who volunteers to present and to lead the discussion,
>> * what time allocation is appropriate,
>> * what you are trying to accomplish during the meeting (goals), and
>> * what other items would you like to discuss (I know there are various=

>> items missing from the list).
>>
>> So, you input is needed!
>>
>> -------
>>
>> IETF 95 OAuth Meeting Agenda
>> Wednesday, 10:00-12:30
>> Chairs: Hannes Tschofenig/Derek Atkins
>>
>> - Status Update (Hannes, 5 min)
>>
>> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>
>> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
>>
>> - Proof-of-Possession (TBD, 35 min)
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/=

>> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/=

>>
>> - Token Exchange (TBD, 15 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>
>> - OAuth 2.0 for Native Apps (William, 15 min)
>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>>
>> - Authentication Method Reference Values (Mike, 15 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>
>> - Conclusion (Hannes, 5 min)
>>
>> -------
>>
>> The latest version can be found at:
>> https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth
>>
>> Ciao
>> Hannes & Derek
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--h4FuclXRrQ4hKNATO83TiTeJ9adsrowS9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW8HMrAAoJEGhJURNOOiAtuy4H/2A43I1PCn4gzlmGw98p7O4X
GiDljVsMQ2VN2fgXQUSZvROHx7dZGeW/EiiURkcZn7NTrWpYw+b3/gACcvX1/IFt
D0CYWa4ACQBuNuOHze0ycUYpswXC46LME/RmF/0NmVTfQKtZxUd4vU15J2Fgf93y
GA/JGY5o0V4FuNUdBjqP/sChf+QLr2quMqy3hnhx5UfbDuBZ9WneKGXnlO96ARrR
8OYH2QoCin4OTh6yXchBXFXyrsJ9K73mnAOsRenJcN5dp8xcOKBmGpef9w+e+O86
cNBPDC593a8Ufz0GTrShqDcii8tdCa3T3Y7pDbw4QsNNmDT/a+XMt87xUhf5gzU=
=XocN
-----END PGP SIGNATURE-----

--h4FuclXRrQ4hKNATO83TiTeJ9adsrowS9--


From nobody Mon Mar 21 15:30:12 2016
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 8FA1812D121 for ; Mon, 21 Mar 2016 15:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 8hZZzYd3hggD for ; Mon, 21 Mar 2016 15:30:10 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 E965A12D11B for ; Mon, 21 Mar 2016 15:30:09 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2LMU7ih009218 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2016 22:30:08 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2LMU6WO022437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2016 22:30:07 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2LMU6LT009448; Mon, 21 Mar 2016 22:30:06 GMT
Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Mar 2016 15:30:06 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D20)
In-Reply-To: <56F0732B.7090600@gmx.net>
Date: Mon, 21 Mar 2016 15:30:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <57BECD77-5764-4AC9-A751-23A1EDE3453E@oracle.com>
References: <56F05664.1010507@gmx.net> <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com> <56F0732B.7090600@gmx.net>
To: Hannes Tschofenig 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 22:30:11 -0000

Sounds good.=20

Phil

> On Mar 21, 2016, at 15:18, Hannes Tschofenig  w=
rote:
>=20
> Hi Phil,
>=20
> we can put this topic as an additional agenda item to the list by
> removing time from the PoP and the mix-up agenda items
>=20
> Ciao
> Hannes
>=20
>> On 03/21/2016 09:46 PM, Phil Hunt wrote:
>> I=E2=80=99m not sure you intend to discuss it in the Mix-up section, but I=
 think
>> we need time to discuss the correct configuration of clients and the
>> resource/aud relationship issues
>> (specifically: draft-campbell-oauth-resource-indicators
>>  and draft-hunt-oauth-bound-config
>> ).
>>=20
>> There is apparently overlap with mix-up mitigation (either in reality or
>> perception), so I think it is important to have a verbal discussion on
>> this to get to consensus and understanding of the separate issues.
>>=20
>> As for POP-architecture, that has been on hold pending the mix-up
>> discussions and understanding of dynamic client risks.  So, not much
>> need to discuss from my perspective.
>>=20
>> Thanks,
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig
>>> > wrote:
>>>=20
>>> Hi all,
>>>=20
>>> I need your help creating the agenda for the next meeting. We have a 2
>>> 1/2 hour slot and many different topics to discuss. I put a strawman
>>> proposal together but there are various things missing:
>>>=20
>>> * who volunteers to present and to lead the discussion,
>>> * what time allocation is appropriate,
>>> * what you are trying to accomplish during the meeting (goals), and
>>> * what other items would you like to discuss (I know there are various
>>> items missing from the list).
>>>=20
>>> So, you input is needed!
>>>=20
>>> -------
>>>=20
>>> IETF 95 OAuth Meeting Agenda
>>> Wednesday, 10:00-12:30
>>> Chairs: Hannes Tschofenig/Derek Atkins
>>>=20
>>> - Status Update (Hannes, 5 min)
>>>=20
>>> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>=20
>>> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
>>>=20
>>> - Proof-of-Possession (TBD, 35 min)
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>>>=20
>>> - Token Exchange (TBD, 15 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>>=20
>>> - OAuth 2.0 for Native Apps (William, 15 min)
>>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>>>=20
>>> - Authentication Method Reference Values (Mike, 15 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>>=20
>>> - Conclusion (Hannes, 5 min)
>>>=20
>>> -------
>>>=20
>>> The latest version can be found at:
>>> https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth
>>>=20
>>> Ciao
>>> Hannes & Derek
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20


From nobody Mon Mar 21 15:31:57 2016
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 EB3C812D121 for ; Mon, 21 Mar 2016 15:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 L1SULmrjaDRg for ; Mon, 21 Mar 2016 15:31:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A3912D10E for ; Mon, 21 Mar 2016 15:31:53 -0700 (PDT)
Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MdrK9-1aPd4W2oZh-00PePv; Mon, 21 Mar 2016 23:31:45 +0100
To: John Bradley , Phil Hunt 
References: <56F05664.1010507@gmx.net> <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com> <16BDBD68-0851-4650-850E-454EE7D3ABE6@ve7jtb.com>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56F07654.2070702@gmx.net>
Date: Mon, 21 Mar 2016 23:31:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <16BDBD68-0851-4650-850E-454EE7D3ABE6@ve7jtb.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U6b3gGdFaq7xMRvWG8PFXwvgWegTdAKlI"
X-Provags-ID: V03:K0:OdIERVGqY3nHC0UZ1jPbjgY+wBBMO1NCbVyIu9zIbXZDO8Mbp4G FuitAF0cehGPKMu4VVziBDl9UhU1vW4kNkE8oXQsDjDvymDc3zqBQ41LoF2vAQUCRovn1lv tiuEh0HT2yJBYZQ5iEjcDZY/8iUaagK7MdSc/l37X8C6ZPjNLfEOVfV01sUUnvUHrQLREh4 hCMliOWptj0fNYRedGcsQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:XYxbonOJ/Rw=:PSKgqvCEwkCAbLY9/GUbeg 2+FCX4uUVYU2ohtGjE8z8fvkjOB/LzqdV0WDM1cm3MUQW254kOsrwXRGGYayw/lTdWDvZsP1y FTqsVtJZnCufREHJz6xm055SHppIEZ4GjE6qPr3G1szUG15F5H4t0FKbRZI1lbZ+/AUC/mXkm DgXlS2Xi/bmu+H4axY0DW+pYlwUCquMgw+OeRYCPwgEVuOhbDyyvCWFUEadxIDN7NldjPCFgF pvdGP0JnFSeb3l1suosK5kgzbSLZMqq8nK74XVIw2gDrrumNYnZ/h3lywblHc7WK4P+crgKaa NbrRGO54bbE+3L93w+GV5O9Tdgt81fTUpqPer1qq5Xov7QLHXCm7O3iiekCq+bIZbYp8hA3xB 1ASsmZXcCixXB4RZJqMP0VaSiyq1QXSg1e3nvdQHSJGDnSEhYvb0TqfhFfaGg7c4yD5fUYHC/ XyZbZAUopg9Y9JHUuLWtbwR5dmePUE9oFpDUQMgRctNMdInwPfquFUS7rOJJV2vji6ksprDFl N1H/oJ1hfX7rdlJyOPL0XM4Xes/OKjD4S9PNvTmBsD4uOooQIq5nfKw+iJ+ScdZK+ubThxBgw zwwcczAympmsl/K26cweCOLyJIxFDkL3+9nU6mvfdZs87QPKoWNSZz65lm+awsHCFNM/EIfa0 KrE2EqgBZxNMKnW6xb2OFsdCUNV9CNLc3mDM8F52iOEo/ZJIG2vCS8Gxt5qEGsFtEPbqrH2jV oGX2ZPb1ffLURtjY8L/1kNeeXainUsBwUbaa0EmXcxrpN++dMgJMaQdicNI=
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 22:31:56 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--U6b3gGdFaq7xMRvWG8PFXwvgWegTdAKlI
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi John,



On 03/21/2016 10:47 PM, John Bradley wrote:
> For mix up we have the mix-up mitigation draft,  and the question of if=

> the mitigation for the cut and paste attack should stay as part of that=

> or be separate.

That's a good summary.

>=20
> There are the two drafts that attempt to prevent leakage of bearer AT b=
y
> the RS.
>   =20
> We don=E2=80=99t necessarily have consensus yet on if this is a real pr=
oblem
> that OAuth needs to solve vs the API/Application using OAuth, as OAuth
> itself doesn=E2=80=99t say anything about how the client learns about t=
he RS
> other than developer config out of band.
>=20
> I can try and lead all or part of it.

I think it is fair that this topic is part of a separate discussion item
on the agenda, as Phil proposed.

Ciao
Hannes

>=20
> John B.
>=20
>> On Mar 21, 2016, at 8:46 PM, Phil Hunt > > wrote:
>>
>> I=E2=80=99m not sure you intend to discuss it in the Mix-up section, b=
ut I
>> think we need time to discuss the correct configuration of clients and=

>> the resource/aud relationship issues
>> (specifically: draft-campbell-oauth-resource-indicators
>>  and draft-hunt-oauth-bound-config
>> ).
>>
>> There is apparently overlap with mix-up mitigation (either in reality
>> or perception), so I think it is important to have a verbal discussion=

>> on this to get to consensus and understanding of the separate issues.
>>
>> As for POP-architecture, that has been on hold pending the mix-up
>> discussions and understanding of dynamic client risks.  So, not much
>> need to discuss from my perspective.
>>
>> Thanks,
>>
>> Phil
>>
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>
>>
>>
>>
>>
>>> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig
>>> > wrote:=

>>>
>>> Hi all,
>>>
>>> I need your help creating the agenda for the next meeting. We have a =
2
>>> 1/2 hour slot and many different topics to discuss. I put a strawman
>>> proposal together but there are various things missing:
>>>
>>> * who volunteers to present and to lead the discussion,
>>> * what time allocation is appropriate,
>>> * what you are trying to accomplish during the meeting (goals), and
>>> * what other items would you like to discuss (I know there are variou=
s
>>> items missing from the list).
>>>
>>> So, you input is needed!
>>>
>>> -------
>>>
>>> IETF 95 OAuth Meeting Agenda
>>> Wednesday, 10:00-12:30
>>> Chairs: Hannes Tschofenig/Derek Atkins
>>>
>>> - Status Update (Hannes, 5 min)
>>>
>>> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>
>>> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
>>>
>>> - Proof-of-Possession (TBD, 35 min)
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/=

>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution=
/
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request=
/
>>>
>>> - Token Exchange (TBD, 15 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>>
>>> - OAuth 2.0 for Native Apps (William, 15 min)
>>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>>>
>>> - Authentication Method Reference Values (Mike, 15 min)
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
>>>
>>> - Conclusion (Hannes, 5 min)
>>>
>>> -------
>>>
>>> The latest version can be found at:
>>> https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> _______________________________________________
>>> 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
>=20


--U6b3gGdFaq7xMRvWG8PFXwvgWegTdAKlI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW8HZVAAoJEGhJURNOOiAtvOkH/iYkDTFT7JKxzhLWK21A1FKQ
Wn+kEXFQbga8ZMuzrBLxTiuRbRar9uSk5jrLbdxLQ4hpJlKvy5NuvfVSf6JJrp2G
Jy/ofgzldb56h/V6Ex/tbLH609GUjKVZrLU4jBGUNwWwUd0w1AkjAo83wVyML0Ov
nybnw/8o1NpLUxwgEyTumMs70MJNgzd/lfvXWNwVsY5278mVnaPa0DPtLwb+1c0j
OHTGLofe5zY5xxxUx9k58G++0R9V/Amx6bzsmnjrVL+akumxmdTLjrT4IJBAEHt1
0zJZaXe2+F2F4NOlJ2g10FTYn42Ece53LW3KmOxiHFdmlz3rV2d3jkjxrvzR1+g=
=6Aoz
-----END PGP SIGNATURE-----

--U6b3gGdFaq7xMRvWG8PFXwvgWegTdAKlI--


From nobody Tue Mar 22 03:47:53 2016
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 4EB0512D768 for ; Tue, 22 Mar 2016 03:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level: 
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 XnKO7PDOdTd9 for ; Tue, 22 Mar 2016 03:47:48 -0700 (PDT)
Received: from COL004-OMC1S13.hotmail.com (col004-omc1s13.hotmail.com [65.55.34.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0137412D673 for ; Tue, 22 Mar 2016 03:47:47 -0700 (PDT)
Received: from COL402-EAS413 ([65.55.34.8]) by COL004-OMC1S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008);  Tue, 22 Mar 2016 03:47:47 -0700
X-TMN: [2uN/qQy87V4URxFWfNtDeUQ4YLNWDCR1]
X-Originating-Email: [joannemaree78@outlook.com]
Message-ID: 
Content-Type: multipart/alternative; boundary="_44fd20dc-c53f-465f-ae62-150d0be0c4af_"
MIME-Version: 1.0
To: 
From: jo turner 
Date: Tue, 22 Mar 2016 10:48:20 +0000
X-OriginalArrivalTime: 22 Mar 2016 10:47:47.0760 (UTC) FILETIME=[45F38300:01D18428]
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 89, Issue 44
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 10:47:51 -0000

--_44fd20dc-c53f-465f-ae62-150d0be0c4af_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hi Sergey=2C
Not sure why I'm on the mailing list have I accidentally accessed this =2Cm=
y phone was hacked a year or so ago but since then I think my data has sync=
ed with it and I have weird search history etc that isn't mine=2Cif I found=
 a flaw in security am I eligible for a reward

Sent from my Windows Phone
________________________________
From: oauth-request@ietf.org
Sent: =E2=80=8E15/=E2=80=8E03/=E2=80=8E2016 13:11
To: oauth@ietf.org
Subject: OAuth Digest=2C Vol 89=2C Issue 44

Send OAuth mailing list submissions to
        oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
        https://www.ietf.org/mailman/listinfo/oauth
or=2C via email=2C send a message with subject or body 'help' to
        oauth-request@ietf.org

You can reach the person managing the list at
        oauth-owner@ietf.org

When replying=2C please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: Client Credentials flow and Client Registrations
      (Justin Richer)
   2. When does RS not require token introspection ? (Sergey Beryozkin)
   3. Re: Client Credentials flow and Client Registrations
      (John Bradley)
   4. Re: When does RS not require token introspection ? (Justin Richer)


----------------------------------------------------------------------

Message: 1
Date: Tue=2C 15 Mar 2016 08:53:12 -0400
From: Justin Richer 
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
        Registrations
Message-ID: <56E805B8.5000305@mit.edu>
Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed

Is Alice the client here (the piece of software)=2C or is Alice the
resource owner? If Alice is the resource owner=2C then you should
absolutely not be using the client credentials flow like this.

The client credentials flow is designed for cases where the client is
acting on its own behalf=2C not on behalf of any particular user. It's an
optimization of the canonical authorization code flow=2C where there is no
interaction with the resource owner because there is no resource owner
as a separate entity. It's most useful for backend systems that would
have traditionally used a developer key to get access to bulk data. If
you're using it for single-user access=2C you're doing it wrong.

Also=2C you should keep in mind that things that seem "simple" on the
surface are often simplified at the cost of making specific security
concessions and assumptions. The authorization code flow is "complex"
for very good reasons=2C all of them security focused. You should never
pick a different OAuth flow just because it looks simpler=2C you should
only pick them if you're within the use case that it was designed for=2C
and therefor the assumptions of its security patterns match.

We've seen a *ton* of problems with people picking the implicit flow in
the real world and using it with clients other than in-browser
applications that it was designed for. If you're not in that specific
space=2C you're taking on huge risks.

  -- Justin

On 3/15/2016 8:37 AM=2C Sergey Beryozkin wrote:
> Hi All
>
> I've alway been thinking of Client Credentials as being the simplest
> flow but now that I'm looking at implementing it myself to be used in
> the real productions=2C I'm realizing that there's something I do not
> understand about it:
>
> Do the clients using Client Credentials flow need to be
> OAuth2-registered=2C even when such clients are already known to the
> authentication system ?
>
> For example=2C there might be some LDAP/etc entry for Alice (name=2C
> password). Now a client is using a client credentials flow to get an
> access token:
>
> POST /token HTTP/1.1
> Host: server.example.com
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
> Content-Type: application/x-www-form-urlencoded
>
> grant_type=3Dclient_credentials
>
> I hope that in this case no explicit registration (the one typically
> required in redirection based flows) is needed=2C the client (Alice) has
> been 'implicitly' registered (as far as the notion of OAuth2 client is
> concerned) in LDAP/etc.
>
> If the explicit registration with OAuth2 AS was still required in the
> case above then it would lead to a fairly massive duplication of
> effort (Alice is registered in Ldap=2C then also with OAuth2 AS)=2C etc
>
> Can someone clarify it please ?
>
> Thanks=2C Sergey
>
>
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



------------------------------

Message: 2
Date: Tue=2C 15 Mar 2016 13:01:16 +0000
From: Sergey Beryozkin 
To: oauth@ietf.org
Subject: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <56E8079C.3010402@gmail.com>
Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed

Hi

After following the recent thread on multiple authorization servers=2C but
also reading some other related threads=2C I have a question related to
when the token introspection can be avoided.

My understanding has been that given that access tokens are opaque the
RS does not know anything about its content=2C hence that was the purpose
of the token introspection spec: provide an interoperable way for RS to
submit a token to AS and get the token data for RS to make a final
decision about this token.

I think if the access tokens are really opaque=2C i.e=2C they are sequences
RS can not look into=2C then having the introspection option is the only
way to check what the token is really about.

But the recent replies with respect to using JWS or JWE tokens have
confused me.

1. AccessToken as JWS JWT Token:

RS can easily look into it=2C but Justin mentioned that in one case they
first validate this JWS token and then forward it for some further
introspection. Why start introspecting if the token has been validated
and its content is visible ?
Perhaps because some token data which are sensitive are only visible in
the introspection response ? If yes then why use a self-contained token
if some more external data are associated with it.

2. AccessToken as JWE JWT Token: this option was mentioned a couple of
times recently=2C Jonh B. suggested in the other thread the introspection
may not be needed (sorry if I misread it).
The question here=2C how can RS deal with a JWE token=2C it would need to
share the decrypting key with AS.

So=2C is introspection needed only for the completely opaque tokens or it
is also needed for JWS and JWE tokens. I'd say it might be reasonable to
skip it in case of JWS=2C depending on the specific requirements (as the
expiry=2C issuer=2C will be typically set in JWS JWT)=2C while with JWE I c=
an
not see how RS can avoid introspecting unless it shares the
secret/private key with AS.


Thanks=2C Sergey







------------------------------

Message: 3
Date: Tue=2C 15 Mar 2016 10:05:07 -0300
From: John Bradley 
To: Sergey Beryozkin 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
        Registrations
Message-ID: 
Content-Type: text/plain=3B charset=3D"us-ascii"

I think you may be confusing Client credentials flow with resource owner cr=
edentials flow.

If there is a resource owner in the flow use code.   The resource owner cre=
dentials flow is a bad idea and only put in for backwards compatibility.

John B.

> On Mar 15=2C 2016=2C at 9:37 AM=2C Sergey Beryozkin  wrote:
>
> Hi All
>
> I've alway been thinking of Client Credentials as being the simplest flow=
 but now that I'm looking at implementing it myself to be used in the real =
productions=2C I'm realizing that there's something I do not understand abo=
ut it:
>
> Do the clients using Client Credentials flow need to be OAuth2-registered=
=2C even when such clients are already known to the authentication system ?
>
> For example=2C there might be some LDAP/etc entry for Alice (name=2C pass=
word). Now a client is using a client credentials flow to get an access tok=
en:
>
> POST /token HTTP/1.1
> Host: server.example.com
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
> Content-Type: application/x-www-form-urlencoded
>
> grant_type=3Dclient_credentials
>
> I hope that in this case no explicit registration (the one typically requ=
ired in redirection based flows) is needed=2C the client (Alice) has been '=
implicitly' registered (as far as the notion of OAuth2 client is concerned)=
 in LDAP/etc.
>
> If the explicit registration with OAuth2 AS was still required in the cas=
e above then it would lead to a fairly massive duplication of effort (Alice=
 is registered in Ldap=2C then also with OAuth2 AS)=2C etc
>
> Can someone clarify it please ?
>
> Thanks=2C Sergey
>
>
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: 

------------------------------

Message: 4
Date: Tue=2C 15 Mar 2016 09:11:30 -0400
From: Justin Richer 
To: Sergey Beryozkin =2C oauth@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <56E80A02.20101@mit.edu>
Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed

The access tokens are opaque to the client=2C not the RS.

  -- Justin

On 3/15/2016 9:01 AM=2C Sergey Beryozkin wrote:
> Hi
>
> After following the recent thread on multiple authorization servers=2C
> but also reading some other related threads=2C I have a question related
> to when the token introspection can be avoided.
>
> My understanding has been that given that access tokens are opaque the
> RS does not know anything about its content=2C hence that was the
> purpose of the token introspection spec: provide an interoperable way
> for RS to submit a token to AS and get the token data for RS to make a
> final decision about this token.
>
> I think if the access tokens are really opaque=2C i.e=2C they are
> sequences RS can not look into=2C then having the introspection option
> is the only way to check what the token is really about.
>
> But the recent replies with respect to using JWS or JWE tokens have
> confused me.
>
> 1. AccessToken as JWS JWT Token:
>
> RS can easily look into it=2C but Justin mentioned that in one case they
> first validate this JWS token and then forward it for some further
> introspection. Why start introspecting if the token has been validated
> and its content is visible ?
> Perhaps because some token data which are sensitive are only visible
> in the introspection response ? If yes then why use a self-contained
> token if some more external data are associated with it.
>
> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of
> times recently=2C Jonh B. suggested in the other thread the
> introspection may not be needed (sorry if I misread it).
> The question here=2C how can RS deal with a JWE token=2C it would need to
> share the decrypting key with AS.
>
> So=2C is introspection needed only for the completely opaque tokens or
> it is also needed for JWS and JWE tokens. I'd say it might be
> reasonable to skip it in case of JWS=2C depending on the specific
> requirements (as the expiry=2C issuer=2C will be typically set in JWS
> JWT)=2C while with JWE I can not see how RS can avoid introspecting
> unless it shares the secret/private key with AS.
>
>
> Thanks=2C Sergey
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest=2C Vol 89=2C Issue 44
*************************************

--_44fd20dc-c53f-465f-ae62-150d0be0c4af_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"







    

    Hi S=
ergey=2C
    
Not sure why I'm on the mailing list have I accidentally accessed this =2Cm=
y phone was hacked a year or so ago but since then I think my data has sync=
ed with it and I have weird search history etc that isn't mine=2Cif I found=
 a flaw in security am I eligible for
 a reward 
    

    
Sent from my Windows Phone
    

    

    

    
From:
oauth-request@ietf.org
    
Sent:
=E2=80=8E15/=E2=80=8E03/=E2=80=8E2016 13:11
    
To:
oauth@ietf.org
    
Subject:
OAuth Digest=2C Vol 89=2C Issue 44
    

    

    

    

    Send OAuth mailing list submissions to
    
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org
    

    
To subscribe or unsubscribe via the World Wide Web=2C visit
    
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo=
/oauth
    
or=2C via email=2C send a message with subject or body 'help' to
    
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf=
.org
    

    
You can reach the person managing the list at
    
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o=
rg
    

    
When replying=2C please edit your Subject line so it is more specific
    
than "=3BRe: Contents of OAuth digest..."=3B
    

    

    
Today's Topics:
    

    
 =3B =3B 1. Re: Client Credentials flow and Client Registrations
 =3B =3B =3B =3B =3B (Justin Richer)
    
 =3B =3B 2. When does RS not require token introspection ? (Sergey =
Beryozkin)
    
 =3B =3B 3. Re: Client Credentials flow and Client Registrations
 =3B =3B =3B =3B =3B (John Bradley)
    
 =3B =3B 4. Re: When does RS not require token introspection ? (Jus=
tin Richer)
    

    

    
----------------------------------------------------------------------
    

    
Message: 1
    
Date: Tue=2C 15 Mar 2016 08:53:12 -0400
    
From: Justin Richer <=3Bjricher@mit.edu>=3B
    
To: oauth@ietf.org
    
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
    
 =3B =3B =3B =3B =3B =3B =3B Registrations
    
Message-ID: <=3B56E805B8.5000305@mit.edu>=3B
    
Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed
    

    
Is Alice the client here (the piece of software)=2C or is Alice the 
    
resource owner? If Alice is the resource owner=2C then you should 
    
absolutely not be using the client credentials flow like this.
    

    
The client credentials flow is designed for cases where the client is 
    
acting on its own behalf=2C not on behalf of any particular user. It's an <=
br>
optimization of the canonical authorization code flow=2C where there is no =

    
interaction with the resource owner because there is no resource owner 
    
as a separate entity. It's most useful for backend systems that would 
    
have traditionally used a developer key to get access to bulk data. If 
    
you're using it for single-user access=2C you're doing it wrong.
    

    
Also=2C you should keep in mind that things that seem "=3Bsimple"=
=3B on the 
    
surface are often simplified at the cost of making specific security 
    
concessions and assumptions. The authorization code flow is "=3Bcomplex=
"=3B 
    
for very good reasons=2C all of them security focused. You should never 
pick a different OAuth flow just because it looks simpler=2C you should 
only pick them if you're within the use case that it was designed for=2C 
and therefor the assumptions of its security patterns match.
    

    
We've seen a *ton* of problems with people picking the implicit flow in 
the real world and using it with clients other than in-browser 
    
applications that it was designed for. If you're not in that specific 
    
space=2C you're taking on huge risks.
    

    
 =3B -- Justin
    

    
On 3/15/2016 8:37 AM=2C Sergey Beryozkin wrote:
    
>=3B Hi All
    
>=3B
    
>=3B I've alway been thinking of Client Credentials as being the simplest=
 
    
>=3B flow but now that I'm looking at implementing it myself to be used i=
n 
    
>=3B the real productions=2C I'm realizing that there's something I do no=
t 
    
>=3B understand about it:
    
>=3B
    
>=3B Do the clients using Client Credentials flow need to be 
    
>=3B OAuth2-registered=2C even when such clients are already known to the=
 
    
>=3B authentication system ?
    
>=3B
    
>=3B For example=2C there might be some LDAP/etc entry for Alice (name=2C=
 
    
>=3B password). Now a client is using a client credentials flow to get an=
 
    
>=3B access token:
    
>=3B
    
>=3B POST /token HTTP/1.1
    
>=3B Host: server.example.com
    
>=3B Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    
>=3B Content-Type: application/x-www-form-urlencoded
    
>=3B
    
>=3B grant_type=3Dclient_credentials
    
>=3B
    
>=3B I hope that in this case no explicit registration (the one typically=
 
    
>=3B required in redirection based flows) is needed=2C the client (Alice)=
 has 
    
>=3B been 'implicitly' registered (as far as the notion of OAuth2 client =
is 
    
>=3B concerned) in LDAP/etc.
    
>=3B
    
>=3B If the explicit registration with OAuth2 AS was still required in th=
e 
    
>=3B case above then it would lead to a fairly massive duplication of 
>=3B effort (Alice is registered in Ldap=2C then also with OAuth2 AS)=2C =
etc
    
>=3B
    
>=3B Can someone clarify it please ?
    
>=3B
    
>=3B Thanks=2C Sergey
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B _______________________________________________
    
>=3B OAuth mailing list
    
>=3B OAuth@ietf.org
    
>=3B https://www.=
ietf.org/mailman/listinfo/oauth
    

    

    

    
------------------------------
    

    
Message: 2
    
Date: Tue=2C 15 Mar 2016 13:01:16 +=3B0000
    
From: Sergey Beryozkin <=3Bsberyozkin@gmail.com>=3B
    
To: oauth@ietf.org
    
Subject: [OAUTH-WG] When does RS not require token introspection ?
    
Message-ID: <=3B56E8079C.3010402@gmail.com>=3B
    
Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed
    

    
Hi
    

    
After following the recent thread on multiple authorization servers=2C but =

    
also reading some other related threads=2C I have a question related to 
when the token introspection can be avoided.
    

    
My understanding has been that given that access tokens are opaque the 
    
RS does not know anything about its content=2C hence that was the purpose <=
br>
of the token introspection spec: provide an interoperable way for RS to 
submit a token to AS and get the token data for RS to make a final 
    
decision about this token.
    

    
I think if the access tokens are really opaque=2C i.e=2C they are sequences=
 
    
RS can not look into=2C then having the introspection option is the only 
way to check what the token is really about.
    

    
But the recent replies with respect to using JWS or JWE tokens have 
    
confused me.
    

    
1. AccessToken as JWS JWT Token:
    

    
RS can easily look into it=2C but Justin mentioned that in one case they 
first validate this JWS token and then forward it for some further 
    
introspection. Why start introspecting if the token has been validated 
    
and its content is visible ?
    
Perhaps because some token data which are sensitive are only visible in 
the introspection response ? If yes then why use a self-contained token 
if some more external data are associated with it.
    

    
2. AccessToken as JWE JWT Token: this option was mentioned a couple of 
    
times recently=2C Jonh B. suggested in the other thread the introspection <=
br>
may not be needed (sorry if I misread it).
    
The question here=2C how can RS deal with a JWE token=2C it would need to <=
br>
share the decrypting key with AS.
    

    
So=2C is introspection needed only for the completely opaque tokens or it <=
br>
is also needed for JWS and JWE tokens. I'd say it might be reasonable to 
skip it in case of JWS=2C depending on the specific requirements (as the 
expiry=2C issuer=2C will be typically set in JWS JWT)=2C while with JWE I c=
an 
    
not see how RS can avoid introspecting unless it shares the 
    
secret/private key with AS.
    

    

    
Thanks=2C Sergey
    

    

    

    

    

    

    

    
------------------------------
    

    
Message: 3
    
Date: Tue=2C 15 Mar 2016 10:05:07 -0300
    
From: John Bradley <=3Bve7jtb@ve7jtb.com>=3B
    
To: Sergey Beryozkin <=3Bsberyozkin@gmail.com>=3B
    
Cc: oauth@ietf.org
    
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
    
 =3B =3B =3B =3B =3B =3B =3B Registrations
    
Message-ID: <=3BC1D353A4-A7C3-4B5F-9DFD-601C2C1FB3F7@ve7jtb.com>=3B
    
Content-Type: text/plain=3B charset=3D"=3Bus-ascii"=3B
    

    
I think you may be confusing Client credentials flow with resource owner cr=
edentials flow.
    

    
If there is a resource owner in the flow use code. =3B =3B The reso=
urce owner credentials flow is a bad idea and only put in for backwards com=
patibility.
    

    
John B.
    

    
>=3B On Mar 15=2C 2016=2C at 9:37 AM=2C Sergey Beryozkin <=3Bsberyozkin=
@gmail.com>=3B wrote:
    
>=3B 
    
>=3B Hi All
    
>=3B 
    
>=3B I've alway been thinking of Client Credentials as being the simplest=
 flow but now that I'm looking at implementing it myself to be used in the =
real productions=2C I'm realizing that there's something I do not understan=
d about it:
    
>=3B 
    
>=3B Do the clients using Client Credentials flow need to be OAuth2-regis=
tered=2C even when such clients are already known to the authentication sys=
tem ?
    
>=3B 
    
>=3B For example=2C there might be some LDAP/etc entry for Alice (name=2C=
 password). Now a client is using a client credentials flow to get an acces=
s token:
    
>=3B 
    
>=3B POST /token HTTP/1.1
    
>=3B Host: server.example.com
    
>=3B Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    
>=3B Content-Type: application/x-www-form-urlencoded
    
>=3B 
    
>=3B grant_type=3Dclient_credentials
    
>=3B 
    
>=3B I hope that in this case no explicit registration (the one typically=
 required in redirection based flows) is needed=2C the client (Alice) has b=
een 'implicitly' registered (as far as the notion of OAuth2 client is conce=
rned) in LDAP/etc.
    
>=3B 
    
>=3B If the explicit registration with OAuth2 AS was still required in th=
e case above then it would lead to a fairly massive duplication of effort (=
Alice is registered in Ldap=2C then also with OAuth2 AS)=2C etc
    
>=3B 
    
>=3B Can someone clarify it please ?
    
>=3B 
    
>=3B Thanks=2C Sergey
    
>=3B 
    
>=3B 
    
>=3B 
    
>=3B 
    
>=3B 
    
>=3B 
    
>=3B 
    
>=3B 
    
>=3B 
    
>=3B _______________________________________________
    
>=3B OAuth mailing list
    
>=3B OAuth@ietf.org
    
>=3B https://www.=
ietf.org/mailman/listinfo/oauth
    

    
-------------- next part --------------
    
A non-text attachment was scrubbed...
    
Name: smime.p7s
    
Type: application/pkcs7-signature
    
Size: 4326 bytes
    
Desc: not available
    
URL: <=3Bhttps://mailarchive.ietf.org/arch/b=
rowse/oauth/attachments/20160315/7d08b4d0/attachment.p7s>=3B
    

    
------------------------------
    

    
Message: 4
    
Date: Tue=2C 15 Mar 2016 09:11:30 -0400
    
From: Justin Richer <=3Bjricher@mit.edu>=3B
    
To: Sergey Beryozkin <=3Bsberyozkin@gmail.com>=3B=2C oauth@ietf.org
    
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
    
Message-ID: <=3B56E80A02.20101@mit.edu>=3B
    
Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed
    

    
The access tokens are opaque to the client=2C not the RS.
    

    
 =3B -- Justin
    

    
On 3/15/2016 9:01 AM=2C Sergey Beryozkin wrote:
    
>=3B Hi
    
>=3B
    
>=3B After following the recent thread on multiple authorization servers=
=2C 
    
>=3B but also reading some other related threads=2C I have a question rel=
ated 
    
>=3B to when the token introspection can be avoided.
    
>=3B
    
>=3B My understanding has been that given that access tokens are opaque t=
he 
    
>=3B RS does not know anything about its content=2C hence that was the 
>=3B purpose of the token introspection spec: provide an interoperable wa=
y 
    
>=3B for RS to submit a token to AS and get the token data for RS to make=
 a 
    
>=3B final decision about this token.
    
>=3B
    
>=3B I think if the access tokens are really opaque=2C i.e=2C they are 
>=3B sequences RS can not look into=2C then having the introspection opti=
on 
    
>=3B is the only way to check what the token is really about.
    
>=3B
    
>=3B But the recent replies with respect to using JWS or JWE tokens have =

    
>=3B confused me.
    
>=3B
    
>=3B 1. AccessToken as JWS JWT Token:
    
>=3B
    
>=3B RS can easily look into it=2C but Justin mentioned that in one case =
they 
    
>=3B first validate this JWS token and then forward it for some further <=
br>
>=3B introspection. Why start introspecting if the token has been validat=
ed 
    
>=3B and its content is visible ?
    
>=3B Perhaps because some token data which are sensitive are only visible=
 
    
>=3B in the introspection response ? If yes then why use a self-contained=
 
    
>=3B token if some more external data are associated with it.
    
>=3B
    
>=3B 2. AccessToken as JWE JWT Token: this option was mentioned a couple =
of 
    
>=3B times recently=2C Jonh B. suggested in the other thread the 
    
>=3B introspection may not be needed (sorry if I misread it).
    
>=3B The question here=2C how can RS deal with a JWE token=2C it would ne=
ed to 
    
>=3B share the decrypting key with AS.
    
>=3B
    
>=3B So=2C is introspection needed only for the completely opaque tokens =
or 
    
>=3B it is also needed for JWS and JWE tokens. I'd say it might be 
    
>=3B reasonable to skip it in case of JWS=2C depending on the specific 
>=3B requirements (as the expiry=2C issuer=2C will be typically set in JW=
S 
    
>=3B JWT)=2C while with JWE I can not see how RS can avoid introspecting =

    
>=3B unless it shares the secret/private key with AS.
    
>=3B
    
>=3B
    
>=3B Thanks=2C Sergey
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B
    
>=3B _______________________________________________
    
>=3B OAuth mailing list
    
>=3B OAuth@ietf.org
    
>=3B https://www.=
ietf.org/mailman/listinfo/oauth
    

    

    

    
------------------------------
    

    
Subject: Digest Footer
    

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

    

    
------------------------------
    

    
End of OAuth Digest=2C Vol 89=2C Issue 44
    
*************************************
    

    

    



--_44fd20dc-c53f-465f-ae62-150d0be0c4af_--


From nobody Tue Mar 22 05:49:27 2016
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 381B912D63E for ; Tue, 22 Mar 2016 05:49:26 -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=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 VsXs6E-65tGi for ; Tue, 22 Mar 2016 05:49:24 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001: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 1539C12D50B for ; Tue, 22 Mar 2016 05:49:24 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id m184so242266200iof.1 for ; Tue, 22 Mar 2016 05:49:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+At5dQfjpGLdJS+YoXiDQCHqFHhsMqNOIeb6QwOG03M=; b=JsfKyr3Str0yomZU+dv+dUhuV1gpNlNs7MWrpsGF5Iso5wiDeo7+yPIa6GLXQxrs3K OOExLUAPl9JzMDhlGIXrAc63dDfrOAv2WKMBoRBE5n+cT/1QR7/IZhLucfGsSBt/3bqp BIcaAp0Xp3RVwimbxrYftfmrLQH7KKgyFinQg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+At5dQfjpGLdJS+YoXiDQCHqFHhsMqNOIeb6QwOG03M=; b=Hw08Y8po0f/x5BSRsASDlsgfz9IcS2llcFJSIWhxcIjhhllUhs0FZwfHPVbNB5WrBI SZBmM4OFKYSuoh25I1KxvpKkzJL3HvlXjXidgIu1gwfg8shwrhE+TEx7UvCwHNrKe9Oi ZCq4rXVVdOZQdGJUSQHUxC/a0Z4PYJR7wG5POO2VuqWLGo3M8AYGeQyvaOBeKV5V0n/B HbjHbUKgZToNOVodP77gyoh8g1Vv72Kf5GL8tuxPTAzReCcqDTi8nOEN0yFfgrZkNaUj RXAIRTEUZKMOmTJhekmij5YXBEowSm4mfdsYHDyXA2gXYqzvHCI9tU7Cmw1crmZP0E1j QnXA==
X-Gm-Message-State: AD7BkJJ23/RDtp38ftuLLLcIMdn7oG3kD7Ct42w7QW704qJsWO0wQxCgWwoFcB6mHLPhpF4MrQ03c0hFNmEP1Kau
X-Received: by 10.107.137.152 with SMTP id t24mr38233785ioi.147.1458650963354;  Tue, 22 Mar 2016 05:49:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 22 Mar 2016 05:48:53 -0700 (PDT)
In-Reply-To: 
References: <20160320201414.8930.5136.idtracker@ietfa.amsl.com> 
From: Brian Campbell 
Date: Tue, 22 Mar 2016 06:48:53 -0600
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a113f902285c42f052ea2a489
Archived-At: 
Cc: Hannes Tschofenig , "" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 12:49:26 -0000

--001a113f902285c42f052ea2a489
Content-Type: text/plain; charset=UTF-8

Indeed, Justin has also suggested a temporal parameter in the past. That's
not captured currently in this draft but that's not intended to preclude
doing so in future revisions, if we can get some more concrete
proposals/discussions around what that would look like.

In our implementation, the temporal nature of tokens and grants is driven
from configuration and policy rather than at the client's request, so I
don't really have experience with how a run-time parameter might look or
work.

On Sun, Mar 20, 2016 at 3:17 PM, John Bradley  wrote:

>
> As Justin pointed out we may also want to separate out offline access and
> some other common things from scope as well.  This is intended to start the
> discussion not preclude other discussions around how to reduce the
> overloading of scope.
>
>

--001a113f902285c42f052ea2a489
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Indeed, Justin has also suggested a  temporal parameter in the past. That's not captured currently i=
n this draft but that's not intended to preclude doing so in future rev=
isions, if we can get some more concrete proposals/discussions around what =
that would look like. 

    In our implementation, the temporal nat=
ure of tokens and grants is driven from configuration and policy rather tha=
n at the client's request, so I don't really have experience with h=
ow a run-time parameter might look or work. =C2=A0 

    On Sun, Mar 20, 2016 a=
t 3:17 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

    As Justin pointed o=
ut we may also want to separate out offline access and some other common th=
ings from scope as well.=C2=A0 This is intended to start the discussion not=
 preclude other discussions around how to reduce the overloading of scope.<=
/div>

    

--001a113f902285c42f052ea2a489--


From nobody Tue Mar 22 06:07:48 2016
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 9387112D734 for ; Tue, 22 Mar 2016 06:07:46 -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=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 gT5_IimZ-jeX for ; Tue, 22 Mar 2016 06:07:44 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 46DAC12D73B for ; Tue, 22 Mar 2016 06:07:36 -0700 (PDT)
Received: by mail-ig0-x229.google.com with SMTP id av4so104822120igc.1 for ; Tue, 22 Mar 2016 06:07:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ugKVGIRGJ88sehG32nQHvAeSrlki9ZQjumz4/ZuIeRw=; b=Srx3pUm/NM3dZ1D0A8zgkkOQipTlA360BPcO16V7AZ+VQpJQoqX6YWM6WCvGtFc2t/ PPXL2caCu6u+/l+eaIpNT3CHiZI2JSBM9Ma2wuIJqZqOazdNnOeX/miS6YoVAhIYm/e9 Kp+EucDR2lqAPSr23tYI2ybVBCpWgj+WCHgtI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ugKVGIRGJ88sehG32nQHvAeSrlki9ZQjumz4/ZuIeRw=; b=ehEb88djJxh893e44/fsI0xUEH0ocnjWvgB6Q7Cp9bAazR8OmAtwMs/jZbZhWqj+K1 Rja6Eyp8YS2uYxlLB5VqvJ7w0PK6mNbEG8Fxm07Py0MOo+qHwM8DWAyxvZ7XunQHRatA Mredq8boglg1GAMa6z1I3HGHyXm3BRaHV92U7a7O0FkECxFJiKhP3ZqE7C/ClbelD/e0 bri9KQkbt8L95VZ7Krt0NUpq4N4jRG7ZeyPIz41rlrBlXhR7vrywIQMRsVLunLB2+hv+ OtgY2db8I2Cf9aHhyzfSXmGtc/ViEbcw+HGB24MMxXgVJrjiT7Z+LWlWe1lWvISO/zgV cJog==
X-Gm-Message-State: AD7BkJJsVoTvuN0XgSsw5mE4Ad7WRrL8eSciatApwdIXqUgCUNRAPF+1hHlGAtNOX5xv8UQQufj9dD0VyKwQF1VA
X-Received: by 10.50.20.129 with SMTP id n1mr18929600ige.77.1458652055365; Tue, 22 Mar 2016 06:07:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 22 Mar 2016 06:07:05 -0700 (PDT)
In-Reply-To: 
References: <20160320201414.8930.5136.idtracker@ietfa.amsl.com>  <56EF9E0E.6010404@gmx.net> <486347F9-07D0-4DB9-84AB-44FFFBCA2705@ve7jtb.com> 
From: Brian Campbell 
Date: Tue, 22 Mar 2016 07:07:05 -0600
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=047d7bd755ae9c863e052ea2e599
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 13:07:46 -0000

--047d7bd755ae9c863e052ea2e599
Content-Type: text/plain; charset=UTF-8

I agree that the in-band approach, and the pieces needed to facilitate it,
probably should have been provided by the OAuth spec from the beginning.
There is both security and basic functional value in it. This draft aims to
close that gap.

There has been, and likely will continue to be, some confusion on the
terms/names. As John said, we elected to use the name 'resource' for the
parameter to try and avoid further overloading the term audience.

FWIW, we currently have support for a similar parameter that enables the
appropriate access token policy to be used based on the target resource
indicated by the client. We went with 'aud' based on hope/expectation that
draft-ietf-oauth-pop-key-distribution's use of the parameter would get
picked up. But 'resource' feels like a more natural name for it. And there
are potential name conflicts with 'aud' and draft-ietf-oauth-jwsreq. So
we'll have some compatibility and migration issues to deal with.




On Mon, Mar 21, 2016 at 2:47 AM, Hannes Tschofenig <
Hannes.Tschofenig@arm.com> wrote:

> Hi John,
>
> We certainly had some confusion about what is the best possible term for
> the client to indicate to the resource server what RS it wants to access
> and for the AS to say what RS the client is allowed to access.
>
> For me the inband approach (either by carrying the information in the AT
> or by obtaining the information via token introspection in those cases
> where the AT is actually a reference rather than a self-contained token) is
> a useful approach that should have actually provided by the OAuth spec from
> the first day onwards.
>
> The reason draft-tschofenig-oauth-audience-00 was not advanced at that
> time was that the group (at the time) wanted to include the functionality
> in the PoP token work, as you are very well aware of. In the meanwhile it
> seems that the group had again changed their mind and wants to rather
> progress the work as an independent doc.
>
> Ciao
> Hannes
>
>
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: 21 March 2016 09:09
> To: Hannes Tschofenig
> Cc: ; Hannes Tschofenig
> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-campbell-oauth-resource-indicators-00.txt
>
> Thanks Hannes
>
> We should merge them they are very similar.
>
> We made a distinction between the resource URI and the audience to try and
> avoid some confusion about overloading the term audience.
>
> We also covered the security considerations around user hosted content and
> being specific about the resource to avoid leakage.
>
> We were less concerned about talking about key material, or the type of
> token.
>
> We wanted to be able to show the WG that audience restricting AT has
> different and I argue better security properties than doing out of band
> discovery of the resource to try and stop AT leakage.
>
> John B.
>
>
>
> > On Mar 21, 2016, at 7:09 AM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
> >
> > FWIW: I also worth I wrote a draft a while ago about this topic:
> > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
> >
> > On 03/20/2016 10:17 PM, John Bradley wrote:
> >> We have had a number of discussions  about splitting the audience part
> >> of PoP key distribution out into it's own draft
> >>
> >> Phil also requested  a draft on how I propose propose that proper
> >> audiencing of access tokens can mitigate against the threat of bearer
> >> access token leakage.
> >>
> >> In response Brian Campbell and I have created a short 00 draft on how
> >> the client can specify the resource that it is requesting a token for
> >> without overloading scopes.
> >>
> >> I hope that this will make some of the issues clearer for our
> discussion.
> >>
> >> As Justin pointed out we may also want to separate out offline access
> >> and some other common things from scope as well.  This is intended to
> >> start the discussion not preclude other discussions around how to reduce
> >> the overloading of scope.
> >>
> >> Regards
> >> John Bradley
> >>
> >>
> >>
> >>> Begin forwarded message:
> >>>
> >>> *From: *internet-drafts@ietf.org 
> >>> *Subject: **New Version Notification for
> >>> draft-campbell-oauth-resource-indicators-00.txt*
> >>> *Date: *March 20, 2016 at 8:14:14 PM GMT
> >>> *To: *"Brian Campbell"  >>> >, "John Bradley"
> >>> >
> >>>
> >>>
> >>> A new version of I-D, draft-campbell-oauth-resource-indicators-00.txt
> >>> has been successfully submitted by Brian Campbell and posted to the
> >>> IETF repository.
> >>>
> >>> Name:draft-campbell-oauth-resource-indicators
> >>> Revision:00
> >>> Title:Resource Indicators for OAuth 2.0
> >>> Document date:2016-03-20
> >>> Group:Individual Submission
> >>> Pages:7
> >>> URL:
> >>>
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-00.txt
> >>> Status:
> >>>
> https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
> >>> Htmlized:
> >>>
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>>
> >>> 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
> >>> .
> >>>
> >>> The IETF Secretariat
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please 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.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--047d7bd755ae9c863e052ea2e599
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I agree that the in-band approach, and the piece=
s needed to facilitate it, probably should have been provided by the OAuth =
spec from the beginning. There is both security and basic functional value =
in it. This draft aims to close that gap.

    There has been, and =
likely will continue to be, some confusion on the terms/names. As John said=
, we elected to use the name 'resource' for the pa=
rameter to try and avoid further overloading the term audience.=C2=
=A0 

    FWIW, we currently have support for a similar parameter t=
hat enables the appropriate access token policy to be used based on the tar=
get resource indicated by the client. We went with 'aud' based on h=
ope/expectation that draft-ietf-oauth-pop-key-distribution's use of the=
 parameter would get picked up. But 'resource' feels like a more na=
tural name for it. And there are potential name conflicts =
with 'aud' and draft-ietf-oauth-jwsreq. So we'll have some comp=
atibility and migration issues to deal with. 


    <=
br> 

    On Mon, Mar 21, 2016 at 2:47 AM, Hannes Tschofenig &=
lt;Hannes.Ts=
chofenig@arm.com> wrote:
    Hi=
 John,
    

    
We certainly had some confusion about what is the best possible term for th=
e client to indicate to the resource server what RS it wants to access and =
for the AS to say what RS the client is allowed to access.
    

    
For me the inband approach (either by carrying the information in the AT or=
 by obtaining the information via token introspection in those cases where =
the AT is actually a reference rather than a self-contained token) is a use=
ful approach that should have actually provided by the OAuth spec from the =
first day onwards.
    

    
The reason draft-tschofenig-oauth-audience-00 was not advanced at that time=
 was that the group (at the time) wanted to include the functionality in th=
e PoP token work, as you are very well aware of. In the meanwhile it seems =
that the group had again changed their mind and wants to rather progress th=
e work as an independent doc.
    

    
Ciao
    
Hannes
    


    

    
-----Original Message-----
    
From: John Bradley [mailto:ve7jtb@ve7j=
tb.com]
    
Sent: 21 March 2016 09:09
    
To: Hannes Tschofenig
    
Cc: <oauth@ietf.org>; Hannes Ts=
chofenig
    
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oa=
uth-resource-indicators-00.txt
    

    
Thanks Hannes
    

    
We should merge them they are very similar.
    

    
We made a distinction between the resource URI and the audience to try and =
avoid some confusion about overloading the term audience.
    

    
We also covered the security considerations around user hosted content and =
being specific about the resource to avoid leakage.
    

    
We were less concerned about talking about key material, or the type of tok=
en.
    

    
We wanted to be able to show the WG that audience restricting AT has differ=
ent and I argue better security properties than doing out of band discovery=
 of the resource to try and stop AT leakage.
    

    
John B.
    

    

    

    
> On Mar 21, 2016, at 7:09 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
    
>
    
> FWIW: I also worth I wrote a draft a while ago about this topic:
    
> https://tools.ietf.org/html/draft=
-tschofenig-oauth-audience-00
    
>
    
> On 03/20/2016 10:17 PM, John Bradley wrote:
    
>> We have had a number of discussions=C2=A0 about splitting the audi=
ence part
    
>> of PoP key distribution out into it's own draft
    
>>
    
>> Phil also requested=C2=A0 a draft on how I propose propose that pr=
oper
    
>> audiencing of access tokens can mitigate against the threat of bea=
rer
    
>> access token leakage.
    
>>
    
>> In response Brian Campbell and I have created a short 00 draft on =
how
    
>> the client can specify the resource that it is requesting a token =
for
    
>> without overloading scopes.
    
>>
    
>> I hope that this will make some of the issues clearer for our disc=
ussion.
    
>>
    
>> As Justin pointed out we may also want to separate out offline acc=
ess
    
>> and some other common things from scope as well.=C2=A0 This is int=
ended to
    
>> start the discussion not preclude other discussions around how to =
reduce
    
>> the overloading of scope.
    
>>
    
>> Regards
    
>> John Bradley
    
>>
    
>>
    
>>
    
>>> Begin forwarded message:
    
>>>
    
>>> *From: *internet-d=
rafts@ietf.org <mailto:i=
nternet-drafts@ietf.org>
    
>>> *Subject: **New Version Notification for
    
>>> draft-campbell-oauth-resource-indicators-00.txt*
    
>>> *Date: *March 20, 2016 at 8:14:14 PM GMT
    
>>> *To: *"Brian Campbell" <brian.d.campbell@gmail.com
    
>>> <mailto:brian=
.d.campbell@gmail.com>>, "John Bradley"
    
>>> <ve7jtb@ve7jtb.com=
 <mailto:ve7jtb@ve7jtb.com>&=
gt;
    
>>>
    
>>>
    
>>> A new version of I-D, draft-campbell-oauth-resource-indicators=
-00.txt
    
>>> has been successfully submitted by Brian Campbell and posted t=
o the
    
>>> IETF repository.
    
>>>
    
>>> Name:draft-campbell-oauth-resource-indicators
    
>>> Revision:00
    
>>> Title:Resource Indicators for OAuth 2.0
    
>>> Document date:2016-03-20
    
>>> Group:Individual Submission
    
>>> Pages:7
    
>>> URL:
    
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/d=
raft-campbell-oauth-resource-indicators-00.txt
    
>>> Status:
    
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-campbell-oauth-resourc=
e-indicators/
    
>>> Htmlized:
    
>>>=C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-00=

    
>>>
    
>>>
    
>>> Abstract:
    
>>>=C2=A0 This straw-man specification defines an extension to The=
 OAuth 2.0
    
>>>=C2=A0 Authorization Framework that enables the client and auth=
orization
    
>>>=C2=A0 server to more explicitly to communicate about the prote=
cted
    
>>>=C2=A0 resource(s) to be accessed.
    
>>>
    
>>>
    
>>>
    
>>>
    
>>> 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
    
>>> <http://tools.ietf.org>.
    
>>>
    
>>> The IETF Secretariat
    
>>>
    
>>
    
>>
    
>>
    
>> _______________________________________________
    
>> OAuth mailing list
    
>> OAuth@ietf.org
    
>> https://www.ietf.org/mailman/listinfo/oauth<=
br>

    

    IMPORTANT NOTICE: The contents of this email and any attachment=
s are confidential and may also be privileged. If you are not the intended =
recipient, please notify the sender immediately and do not disclose the con=
tents to any other person, use it for any purpose, or store or copy the inf=
ormation in any medium. Thank you.
    


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


    

--047d7bd755ae9c863e052ea2e599--


From nobody Tue Mar 22 06:21:06 2016
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 24FE112D5DC for ; Tue, 22 Mar 2016 06:21:06 -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=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 d29JKSA9m8Xl for ; Tue, 22 Mar 2016 06:21:03 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 CD8EB12D7A9 for ; Tue, 22 Mar 2016 06:21:00 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id 124so90814578iov.3 for ; Tue, 22 Mar 2016 06:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dozZV7j6s137dFP6y6lJKzvM85pNbniPdEQ/ONHLLtI=; b=SjZRdk0aCWHsRh/3p49eFK18OCfw2uVyEqdqbYzd+Ny4xqlzmBk2fBhYXm75GdI/E5 9Iy7cY5DZyXK2uzt/t+fY5bMNmv0GCTfsWm2TXQtcFtsuj8gxLbxhPy/uXim4vfij23a bAMZfTWX/bk59/Z1m3YFM+GiVBMPtZA35Dg6w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dozZV7j6s137dFP6y6lJKzvM85pNbniPdEQ/ONHLLtI=; b=Sph/WV1U6iBlcQGVHUen0Ay+9tg4gWZmuDBWpulwMDZrR4328UUZqMoSQar2dFvidR ed+Urb9ZY+esl2fwkEni4n5cVCF1f7k6r7MnyvdBY8cEnRNwH0ehf+YiCObg3JWTAZs0 KSDPG+coHWh5IR/eXp7aekOyuyyjFfhGHtxduQB8IC6fy7cqArTVJXb7TALCZZ3XDVin 4c/t+3/trra5ivk1hQxc0kVNtCw217jr8DrOVUvfgPIWohDFcJr61E6TyhGyHezSyuYv xEXtbwEAKxUHNunHVjQCbvBmD+0sMi74U5BhmkycKB/U7DUDUpsJqvJVKdN31Mtkdgpt XIYQ==
X-Gm-Message-State: AD7BkJLYwP4pnfmv78VGyoXwn3AlmsDtNode1vzqKZ64nxL+7H/kwDsft15l6FUDBdKl6pnw+Cftjx26Tc6Ecd1R
X-Received: by 10.107.137.152 with SMTP id t24mr38436999ioi.147.1458652860139;  Tue, 22 Mar 2016 06:21:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 22 Mar 2016 06:20:30 -0700 (PDT)
In-Reply-To: <56F07654.2070702@gmx.net>
References: <56F05664.1010507@gmx.net> <9AED819A-6392-4115-99CF-D97E93BD0554@oracle.com> <16BDBD68-0851-4650-850E-454EE7D3ABE6@ve7jtb.com> <56F07654.2070702@gmx.net>
From: Brian Campbell 
Date: Tue, 22 Mar 2016 07:20:30 -0600
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a113f9022945f84052ea315e2
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Agenda Proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 13:21:06 -0000

--001a113f9022945f84052ea315e2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'll take Token Exchange. It'll be a status update and quick look at some
open issues. Hope to keep it short.

+1 the characterization of mix-up mitigation.

I can also talk about draft-campbell-oauth-resource-indicators, however,
maybe it should be part of the somewhat larger conversation that John has
kindly volunteered to lead.

I realize we can't cover everything but "OAuth 2.0 Authorization Server
Discovery Metadata" seems conspicuously absent from the agenda.



On Mon, Mar 21, 2016 at 4:31 PM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi John,
>
>
>
> On 03/21/2016 10:47 PM, John Bradley wrote:
> > For mix up we have the mix-up mitigation draft,  and the question of if
> > the mitigation for the cut and paste attack should stay as part of that
> > or be separate.
>
> That's a good summary.
>
> >
> > There are the two drafts that attempt to prevent leakage of bearer AT b=
y
> > the RS.
> >
> > We don=E2=80=99t necessarily have consensus yet on if this is a real pr=
oblem
> > that OAuth needs to solve vs the API/Application using OAuth, as OAuth
> > itself doesn=E2=80=99t say anything about how the client learns about t=
he RS
> > other than developer config out of band.
> >
> > I can try and lead all or part of it.
>
> I think it is fair that this topic is part of a separate discussion item
> on the agenda, as Phil proposed.
>
> Ciao
> Hannes
>
> >
> > John B.
> >
> >> On Mar 21, 2016, at 8:46 PM, Phil Hunt  >> > wrote:
> >>
> >> I=E2=80=99m not sure you intend to discuss it in the Mix-up section, b=
ut I
> >> think we need time to discuss the correct configuration of clients and
> >> the resource/aud relationship issues
> >> (specifically: draft-campbell-oauth-resource-indicators
> >> <
> http://tools.ietf.org/id/draft-campbell-oauth-resource-indicators-01.txt>
> and draft-hunt-oauth-bound-config
> >> ).
> >>
> >> There is apparently overlap with mix-up mitigation (either in reality
> >> or perception), so I think it is important to have a verbal discussion
> >> on this to get to consensus and understanding of the separate issues.
> >>
> >> As for POP-architecture, that has been on hold pending the mix-up
> >> discussions and understanding of dynamic client risks.  So, not much
> >> need to discuss from my perspective.
> >>
> >> Thanks,
> >>
> >> Phil
> >>
> >> @independentid
> >> www.independentid.com 
> >> phil.hunt@oracle.com 
> >>
> >>
> >>
> >>
> >>
> >>> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig
> >>> > wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I need your help creating the agenda for the next meeting. We have a =
2
> >>> 1/2 hour slot and many different topics to discuss. I put a strawman
> >>> proposal together but there are various things missing:
> >>>
> >>> * who volunteers to present and to lead the discussion,
> >>> * what time allocation is appropriate,
> >>> * what you are trying to accomplish during the meeting (goals), and
> >>> * what other items would you like to discuss (I know there are variou=
s
> >>> items missing from the list).
> >>>
> >>> So, you input is needed!
> >>>
> >>> -------
> >>>
> >>> IETF 95 OAuth Meeting Agenda
> >>> Wednesday, 10:00-12:30
> >>> Chairs: Hannes Tschofenig/Derek Atkins
> >>>
> >>> - Status Update (Hannes, 5 min)
> >>>
> >>> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >>>
> >>> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
> >>>
> >>> - Proof-of-Possession (TBD, 35 min)
> >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
> >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
> >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution=
/
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request=
/
> >>>
> >>> - Token Exchange (TBD, 15 min)
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
> >>>
> >>> - OAuth 2.0 for Native Apps (William, 15 min)
> >>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/
> >>>
> >>> - Authentication Method Reference Values (Mike, 15 min)
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/
> >>>
> >>> - Conclusion (Hannes, 5 min)
> >>>
> >>> -------
> >>>
> >>> The latest version can be found at:
> >>> https://www.ietf.org/proceedings/95/agenda/agenda-95-oauth
> >>>
> >>> Ciao
> >>> Hannes & Derek
> >>>
> >>> _______________________________________________
> >>> 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
> >
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a113f9022945f84052ea315e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I'll take Token Exchange. It'll be =
a status update and quick look at some open issues. Hope to keep it short. =


    +1 the characterization of mix-up mitigation.

    I =
can also talk about draft-campbell-oauth-resource-indicators, however, mayb=
e it should be part of the somewhat larger conversation that John has kindl=
y volunteered to lead. 

    I realize we can't cover everythin=
g but "OAuth 2.0 Authorization Server Discovery Metadata" seems c=
onspicuously absent from the agenda. 



    On Mon, Mar 21, 2016 at 4:=
31 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
 wrote:
    Hi John,
    

    

    

    
On 03/21/2016 10:47 PM, John Bradley wrote:
    
> For mix up we have the mix-up mitigation draft,=C2=A0 and the question=
 of if
    
> the mitigation for the cut and paste attack should stay as part of tha=
t
    
> or be separate.
    

    
    That's a good summary.
    

    
>
    
> There are the two drafts that attempt to prevent leakage of bearer AT =
by
    
> the RS.
    
>
    
> We don=E2=80=99t necessarily have consensus yet on if this is a real p=
roblem
    
> that OAuth needs to solve vs the API/Application using OAuth, as OAuth=

    
> itself doesn=E2=80=99t say anything about how the client learns about =
the RS
    
> other than developer config out of band.
    
>
    
> I can try and lead all or part of it.
    

    
    I think it is fair that this topic is part of a separate discussion =
item
    
on the agenda, as Phil proposed.
    

    
Ciao
    
Hannes
    

    
>
    
> John B.
    
>
    
>> On Mar 21, 2016, at 8:46 PM, Phil Hunt <phil.hunt@oracle.com
    
    >> <mailto:phil.hunt@oracle.com>> wrote:
    
>>
    
>> I=E2=80=99m not sure you intend to discuss it in the Mix-up sectio=
n, but I
    
>> think we need time to discuss the correct configuration of clients=
 and
    
>> the resource/aud relationship issues
    
>> (specifically: draft-campbell-oauth-resource-indicators
    
    >> <http://tools.ietf.org/id/draft-campbell-oauth-resource-indicators-=
01.txt> and draft-hunt-oauth-bound-config
    
>> <http://tools.ietf.org/id/d=
raft-hunt-oauth-bound-config-00.txt>).
    
>>
    
    >> There is apparently overlap with mix-up mi=
tigation (either in reality
    
>> or perception), so I think it is important to have a verbal discus=
sion
    
>> on this to get to consensus and understanding of the separate issu=
es.
    
>>
    
>> As for POP-architecture, that has been on hold pending the mix-up<=
br>
>> discussions and understanding of dynamic client risks.=C2=A0 So, n=
ot much
    
>> need to discuss from my perspective.
    
>>
    
>> Thanks,
    
>>
    
>> Phil
    
>>
    
>> @independentid
    
    >> www.independentid.com <http://www.independent=
id.com/>
    
>> phil.hunt@oracle.com &=
lt;mailto:phil.hunt@oracle.com&=
gt;
    
>>
    
>>
    
>>
    
>>
    
>>
    
>>> On Mar 21, 2016, at 1:15 PM, Hannes Tschofenig
    

    >>> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>>>
    
>>> Hi all,
    
>>>
    
>>> I need your help creating the agenda for the next meeting. We =
have a 2
    
>>> 1/2 hour slot and many different topics to discuss. I put a st=
rawman
    
>>> proposal together but there are various things missing:
    
>>>
    
>>> * who volunteers to present and to lead the discussion,
    
>>> * what time allocation is appropriate,
    
>>> * what you are trying to accomplish during the meeting (goals)=
, and
    
>>> * what other items would you like to discuss (I know there are=
 various
    
>>> items missing from the list).
    
>>>
    
>>> So, you input is needed!
    
>>>
    
>>> -------
    
>>>
    
>>> IETF 95 OAuth Meeting Agenda
    
>>> Wednesday, 10:00-12:30
    
>>> Chairs: Hannes Tschofenig/Derek Atkins
    
>>>
    
>>> - Status Update (Hannes, 5 min)
    
>>>
    
>>> - OAuth 2.0 JWT Authorization Request (Nat, 15 min )
    
>>> https://datatracker.ietf.org/d=
oc/draft-ietf-oauth-jwsreq/
    
>>>
    
>>> - OAuth 2.0 Mix-Up Mitigation (TBD, 45 min)
    
>>> https://datatracker=
.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/
    
>>>
    
>>> - Proof-of-Possession (TBD, 35 min)
    
>>> http://datatracker=
.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
    
>>> http://datatracker.ie=
tf.org/doc/draft-ietf-oauth-pop-architecture/
    
>>> http://datatracke=
r.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
    
>>> https://datatrack=
er.ietf.org/doc/draft-ietf-oauth-signed-http-request/
    
>>>
    
>>> - Token Exchange (TBD, 15 min)
    
>>> https://datatracker.ie=
tf.org/doc/draft-ietf-oauth-token-exchange/
    
>>>
    
>>> - OAuth 2.0 for Native Apps (William, 15 min)
    
>>> http://datatracker.iet=
f.org/doc/draft-wdenniss-oauth-native-apps/
    
>>>
    
>>> - Authentication Method Reference Values (Mike, 15 min)
    
>>> https://datatracker.ietf.o=
rg/doc/draft-ietf-oauth-amr-values/
    
>>>
    
>>> - Conclusion (Hannes, 5 min)
    
>>>
    
>>> -------
    
>>>
    
>>> The latest version can be found at:
    
>>> https://www.ietf.org/proceedi=
ngs/95/agenda/agenda-95-oauth
    
>>>
    
>>> Ciao
    
>>> Hannes & Derek
    
>>>
    
>>> _______________________________________________
    
>>> OAuth mailing list
    
>>> OAuth@ietf.org
    
>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>
    
>>
    
>> _______________________________________________
    
>> OAuth mailing list
    

    >> OAuth@ietf.org &=
lt;mailto:OAuth@ietf.org>
    
>> https://www.ietf.org/mailman/listinfo/oauth<=
br>
>
    

    

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


    

--001a113f9022945f84052ea315e2--


From nobody Tue Mar 22 07:51:30 2016
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 47D9712D641 for ; Tue, 22 Mar 2016 07:51:28 -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, FREEMAIL_FROM=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 (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 M8TIt3pZSUmz for ; Tue, 22 Mar 2016 07:51:26 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 CB0CD12D5E0 for ; Tue, 22 Mar 2016 07:51:25 -0700 (PDT)
Received: by mail-lb0-x22b.google.com with SMTP id bc4so165353924lbc.2 for ; Tue, 22 Mar 2016 07:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=GxAFjk6a1NzLfqYuCgR0vRk7LfOWNPJAEFtO5IcCgMo=; b=gmdt8OQu50Am7Az7EQLiYjVBE3pYhwN0iRRwGw+97UjKrrk2u77jCjkAnYg5f6bVlh Lkahp8qWC13fqjixK2kwXOPb2H1pR/p8Nr8Xe92HI/jOiZHfN38fWqCQqxPcmAeghXK7 8m3Qwf6+cC2iBWV9u45CDsQxatzY3r/HCRvA1+x0yghPP/au3bO4Wo7KbK6l4CtrAZki 9u8U/woOj1D5e43TLpm17n4BTw1ppVnxWGI7sDlT1QfG5rpxQBoSe6HPfFn+JUEU+Lw0 EIQd1qdYd6YvBVpCkynXanbCp6xUYucUBRUmx5rA+IYz4DVbL14vaK3y4V0o3juz/5kT g6CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GxAFjk6a1NzLfqYuCgR0vRk7LfOWNPJAEFtO5IcCgMo=; b=cYPwJ3LSeMfbWYUPY6jtuTDWOotHq7lLPcekuY+FGTDAd1TnknhW6Pn2L1dfWV5jG9 hPa2u4eS79dB+0ngdkiGuAb8huzkmqtJWRSXSKJJGeNuj2IYU7XdnR5EJAbOGl50L1c0 pUFhZ10DbFYg7/Qyt4HiOCOAy+3eroDPT0yxV4E6cMHhG9hT5LqeySsmRp+o20RwEe0e tJKdIJuYbZioyHZ/Z0pYaKJpP8z8K5DfBO0vt77og2OCX5ApyuaSe60cW0fdMHrKkWpw qC0Ulv1I4DELwzjkd2+5hsV/RcpcHsqythZ8LMJqGjkxOpzSbVtB0bGfOU+SCVPrUDrn 0EFQ==
X-Gm-Message-State: AD7BkJKG3FNsj9XGTMaHPc80IU0xsTjIuUwCbHWbj9WU5XKCaM5AwgHo4JCcLy6797VEGQ==
X-Received: by 10.112.139.104 with SMTP id qx8mr13160584lbb.88.1458658284005;  Tue, 22 Mar 2016 07:51:24 -0700 (PDT)
Received: from [10.39.0.31] (nat-141-pool-1-ip-6.cosmostv.by. [87.252.225.96]) by smtp.googlemail.com with ESMTPSA id o81sm3148307lfb.44.2016.03.22.07.51.22 for  (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 07:51:23 -0700 (PDT)
To: oauth@ietf.org
References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com>   <0DBACD62-E2FB-43D2-A2F6-F1A16794117A@oracle.com>
From: Sergey Beryozkin 
Message-ID: <56F15BDD.9020005@gmail.com>
Date: Tue, 22 Mar 2016 17:51:09 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <0DBACD62-E2FB-43D2-A2F6-F1A16794117A@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 14:51:28 -0000

Hi

Is there any reason why 'resource' parameter can not be named 'aud' or 
'audience' ?

The text says "AS should audience restrict" the access token and that a 
token 'aud' property may be equal to this "resource" value.

I guess 'audience' is a pure access token property, while as far as 
client is concerned, it is a 'resource', but I wonder if it would be a 
bit simpler if only a single property was used.

It also might make sense to mention that the clients can have 'resource' 
values associated with them at the registration time - this can be done 
by admins, and the client applications will not have to be configured to 
send 'resource' given that AS already knows about the resource restrictions.

Cheers, Sergey



On 21/03/16 23:15, Phil Hunt wrote:
> What about server processing rules and error conditions?  The client
> passes the resource in with every request. What happens if it sends a
> bad URL.  I see the registration for invalid_resource, but I see no
> processing logic for the server that describes when that is returned.
>   I’ll assume that is TBD.
>
> The draft seems more finer grained than with bound configuration
> approach.  It suggests that the client will make a different URL request
> for each resource URL. This could lead to a lot of unnecessary
> authorizations.  I think we still have to resolve the audience to
> resource relationship problem and just how much detail the AS service
> needs to know.
>
> I note that we have a similar issue with bound config on how granular
> resource URL processing is needed.  My main goal is for config to
> validate the domain name only as a major improvement as we just need to
> make sure the client is talking to a valid server and not a MITM proxy.
>
> Finally, there is the question of optionality (in order to have
> backwards compatibility for static clients). If resource is optional,
> than how do we deal with dynamic clients that simply don’t both to use
> the resource parameter?
>
> We’re depending on client developers taking an extra step to provide the
> resource parameter. Maybe optionality for resource url becomes part of
> the client_id registration?  In contrast, config discovery is brand new,
> so making validation required is not such a big deal as static clients
> wouldn’t use discovery.
>
> Another failure condition both drafts should consider:
> * when an authorization, token, or resource endpoint starts to fail,
> should the client fall back to discovery to re-verify configuration?  If
> so, on what errors?  A valid usecase would be a service provider
> deciding to re-configure its services naturally over time.
> * what are the issues when an endpoint that was part of configuration
> issues a re-direct? There are good and bad scenarios (e.g. to a specific
> cluster node), a resource that was relocated, or a hacked service that
> wants to steal tokens.  In these cases, should the client re-validate
> the new resource URI either using this draft or the bound config method?
>
> *On a positive note, unrelated to security, there have been a lot of
> inquiries over the years about how to authorize against on user-owned
> resources.  E.g. How can I ask for authorizations to Brian’s github
> project?  I think this is worth discussing.  Weighing the security and
> functionality needs would be a worthwhile discussion in BA.*
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Mar 21, 2016, at 10:41 AM, Brian Campbell
>> > wrote:
>>
>> Very minor update to this draft before the deadline that moves Hannes
>> from Acknowledgements to Authors in acknowledgment of his similar work
>> a few years ago. Also fleshed out the IANA section with the formal
>> registration requests.
>>
>>
>> ---------- Forwarded message ----------
>> From: ** >
>> Date: Mon, Mar 21, 2016 at 11:31 AM
>> Subject: New Version Notification for
>> draft-campbell-oauth-resource-indicators-01.txt
>> To: Hannes Tschofenig > >, Hannes Tschofenig
>> >, Brian
>> Campbell > >, John Bradley > >
>>
>>
>>
>> A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
>> has been successfully submitted by Brian Campbell and posted to the
>> IETF repository.
>>
>> Name:           draft-campbell-oauth-resource-indicators
>> Revision:       01
>> Title:          Resource Indicators for OAuth 2.0
>> Document date:  2016-03-21
>> Group:          Individual Submission
>> Pages:          8
>> URL:
>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>> Htmlized:
>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01
>>
>> 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.
>>
>>
>>
>>
>> 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
>> .
>>
>> The IETF Secretariat
>>
>>
>>
>> _______________________________________________
>> 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
>


From nobody Tue Mar 22 07:54:36 2016
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 7649F12D847 for ; Tue, 22 Mar 2016 07:54: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, 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=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 VlcGz5uRp3OH for ; Tue, 22 Mar 2016 07:54:31 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 24DE012D6A5 for ; Tue, 22 Mar 2016 07:54:31 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id m184so245777615iof.1 for ; Tue, 22 Mar 2016 07:54:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hPPekvCeAZUEG2+TOe28EmAh14dXckihjmzH8kAD+xM=; b=DmP/2cCTGV/DHtcz32wNxvOVE+qm3Mn8r3N8uDFio9wBG5LbiOuSjozirJn6upOP+r EwFEXKLxuupENDKLRVX8kgyUR6z7SpBgUf6doReSGFRvgc42vcl3aOMDGxFNeWNEc9hB EN4x1De9Po/1t5n7BnxXLugwuv9xswQSz2gtQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hPPekvCeAZUEG2+TOe28EmAh14dXckihjmzH8kAD+xM=; b=KtVcVem8+uf1+gbHsYbhI//pAIs134Ouzq3qK1OqZ9EbaTJBo1z4e2rmZq3WYFfaK1 wDEFPmqdDVT93hnaOlglNR1rWcPPNGzFVC82I8rfQN8Ciq2jUq5VUyp3NQWkUuvw1T0z Ibyfwsp5+ZEp8ZjpLEgD3M3CooyBkrClm93pJTLCi42wqiG+txojR+1/YMmVSYGq4rev jvjjAU/yl4DPiw8qCi7BOMVuNk1FUKcS7qVCyDwtkX9kbSlBc4NqJwQrzeL+LbiZYTQe XjIGVXBHiBiQt490hmgyUDJi4GW/At5W0NzMDLOjwJXKXUdr5sucwkMOCLgka3AxW01w gFTg==
X-Gm-Message-State: AD7BkJKJuiqrXXSVZuTIk6bAMcWnFcyDd0/Ck29f9bmKaYRavgqyfkhWsbSfK89OVRVLLkJQDXpJeNfVwGRxzVA+
X-Received: by 10.107.132.18 with SMTP id g18mr37422903iod.48.1458658470354; Tue, 22 Mar 2016 07:54:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 22 Mar 2016 07:54:00 -0700 (PDT)
In-Reply-To: <0DBACD62-E2FB-43D2-A2F6-F1A16794117A@oracle.com>
References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com>   <0DBACD62-E2FB-43D2-A2F6-F1A16794117A@oracle.com>
From: Brian Campbell 
Date: Tue, 22 Mar 2016 08:54:00 -0600
Message-ID: 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a113ecbe4f97e8c052ea46301
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 14:54:34 -0000

--001a113ecbe4f97e8c052ea46301
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't consider this draft to be a direct alternative to the bound config
thing. It aims to fill a need that the WG has discussed several times
previously. It happens to also facilitate getting audience restrictions
into ATs, which address the concerns about a bad RS using an AT at a good
RS that seem to have surfaced recently (and some have gone so far as to say
isn't a 'real problem' at this time). AFAICT, bound config was put forth as
commentary or an alternative to "OAuth 2.0 Authorization Server Discovery
Metadata" that tries to check the legitimacy of an RS with webfinger.
Though, to be honest, I don't really understand what bound config solves.

The client provides the resource parameter to the token endpoint to
indicate what RS it wants a token for. Or to the authorization endpoint for
implicit (when an AT is returned as an authorization response parameter).
There shouldn't be a a need for unnecessary authorizations in most cases.

The audience to resource relationship is determined by the AS and RSs and
their deployment relationship. Pretty much how it is today. The resource
parameter just gives the client a tool to communicate the RS to the AS.

Backwards compatibility and optionality do need to be taken into account.
It's an extension. How migration and enforcement will be handled will be
policy and implementation decisions. That's just the state of things with
OAuth.

The resource parameter is available to all clients and doesn't rely on
discovery or metadata or registration.

The error condition is described in the draft as follows. Is there
something specific you believe should be addressed?

     '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".'




On Mon, Mar 21, 2016 at 2:15 PM, Phil Hunt  wrote:

> What about server processing rules and error conditions?  The client
> passes the resource in with every request. What happens if it sends a bad
> URL.  I see the registration for invalid_resource, but I see no processin=
g
> logic for the server that describes when that is returned.  I=E2=80=99ll =
assume
> that is TBD.
>
> The draft seems more finer grained than with bound configuration
> approach.  It suggests that the client will make a different URL request
> for each resource URL. This could lead to a lot of unnecessary
> authorizations.  I think we still have to resolve the audience to resourc=
e
> relationship problem and just how much detail the AS service needs to kno=
w.
>
> I note that we have a similar issue with bound config on how granular
> resource URL processing is needed.  My main goal is for config to validat=
e
> the domain name only as a major improvement as we just need to make sure
> the client is talking to a valid server and not a MITM proxy.
>
> Finally, there is the question of optionality (in order to have backwards
> compatibility for static clients). If resource is optional, than how do w=
e
> deal with dynamic clients that simply don=E2=80=99t both to use the resou=
rce
> parameter?
>
> We=E2=80=99re depending on client developers taking an extra step to prov=
ide the
> resource parameter. Maybe optionality for resource url becomes part of th=
e
> client_id registration?  In contrast, config discovery is brand new, so
> making validation required is not such a big deal as static clients
> wouldn=E2=80=99t use discovery.
>
> Another failure condition both drafts should consider:
> * when an authorization, token, or resource endpoint starts to fail,
> should the client fall back to discovery to re-verify configuration?  If
> so, on what errors?  A valid usecase would be a service provider deciding
> to re-configure its services naturally over time.
> * what are the issues when an endpoint that was part of configuration
> issues a re-direct? There are good and bad scenarios (e.g. to a specific
> cluster node), a resource that was relocated, or a hacked service that
> wants to steal tokens.  In these cases, should the client re-validate the
> new resource URI either using this draft or the bound config method?
>
> *On a positive note, unrelated to security, there have been a lot of
> inquiries over the years about how to authorize against on user-owned
> resources.  E.g. How can I ask for authorizations to Brian=E2=80=99s gith=
ub
> project?  I think this is worth discussing.  Weighing the security and
> functionality needs would be a worthwhile discussion in BA.*
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Mar 21, 2016, at 10:41 AM, Brian Campbell 
> wrote:
>
> Very minor update to this draft before the deadline that moves Hannes fro=
m
> Acknowledgements to Authors in acknowledgment of his similar work a few
> years ago. Also fleshed out the IANA section with the formal registration
> requests.
>
>
> ---------- Forwarded message ----------
> From: 
> Date: Mon, Mar 21, 2016 at 11:31 AM
> Subject: New Version Notification for
> draft-campbell-oauth-resource-indicators-01.txt
> To: Hannes Tschofenig , Hannes Tschofenig <
> Hannes.Tschofenig@gmx.net>, Brian Campbell ,
> John Bradley 
>
>
>
> A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name:           draft-campbell-oauth-resource-indicators
> Revision:       01
> Title:          Resource Indicators for OAuth 2.0
> Document date:  2016-03-21
> Group:          Individual Submission
> Pages:          8
> URL:
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indica=
tors-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators=
/
> Htmlized:
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-resource-indicat=
ors-01
>
> 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.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--001a113ecbe4f97e8c052ea46301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    I don't consider this draft to be a direct alternative=
 to the bound config thing. It aims to fill a need that the WG has discusse=
d several times previously. It happens to also facilitate getting audience =
restrictions into ATs, which address the concerns about a bad RS using an A=
T at a good RS that seem to have surfaced recently (and some have gone so f=
ar as to say isn't a 'real problem' at this time). AFAICT, boun=
d config was put forth as commentary or an alternative to "OAuth 2.0 A=
uthorization Server Discovery Metadata" that tries to check the legiti=
macy of an RS with webfinger.=C2=A0 Though, to be honest, I don't reall=
y understand what bound config solves.

    The client provides the =
resource parameter to the token endpoint to indicate what RS it wants a tok=
en for. Or to the authorization endpoint for implicit (when an AT is return=
ed as an authorization response parameter).=C2=A0 There shouldn't be a =
a need for unnecessary authorizations in most cases.

    The audien=
ce to resource relationship is determined by the AS and RSs and their deplo=
yment relationship. Pretty much how it is today. The resource parameter jus=
t gives the client a tool to communicate the RS to the AS. 

    Backward=
s compatibility and optionality do need to be taken into account. It's =
an extension. How migration and enforcement will be handled will be policy =
and implementation decisions. That's just the state of things with OAut=
h.

    The resource parameter is available to all clients and=
 doesn't rely on discovery or metadata or registration.=C2=A0 

    The error condition is described in the draft as follows. Is ther=
e something specific you believe should be addressed? =C2=A0 
         '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".'


    On Mon, Mar 21, =
2016 at 2:15 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<=
br>
    What about server processing rules and error conditions?=C2=
=A0 The client passes the resource in with every request. What happens if i=
t sends a bad URL.=C2=A0 I see the registration for invalid_resource, but I=
 see no processing logic for the server that describes when that is returne=
d.=C2=A0 I=E2=80=99ll assume that is TBD.

    The draft seem=
s more finer grained than with bound configuration approach.=C2=A0 It sugge=
sts that the client will make a different URL request for each resource URL=
. This could lead to a lot of unnecessary authorizations.=C2=A0 I think we =
still have to resolve the audience to resource relationship problem and jus=
t how much detail the AS service needs to know.

    I =
note that we have a similar issue with bound config on how granular resourc=
e URL processing is needed.=C2=A0 My main goal is for config to validate th=
e domain name only as a major improvement as we just need to make sure the =
client is talking to a valid server and not a MITM proxy.

    Finally, there is the question of optionality (in order to have bac=
kwards compatibility for static clients). If resource is optional, than how=
 do we deal with dynamic clients that simply don=E2=80=99t both to use the =
resource parameter? =C2=A0

    We=E2=80=99re depending=
 on client developers taking an extra step to provide the resource paramete=
r. Maybe optionality for resource url becomes part of the client_id registr=
ation?=C2=A0 In contrast, config discovery is brand new, so making validati=
on required is not such a big deal as static clients wouldn=E2=80=99t use d=
iscovery.

    Another failure condition both drafts sh=
ould consider: =C2=A0
    * when an authorization, token, or resource=
 endpoint starts to fail, should the client fall back to discovery to re-ve=
rify configuration?=C2=A0 If so, on what errors?=C2=A0 A valid usecase woul=
d be a service provider deciding to re-configure its services naturally ove=
r time. =C2=A0
    * what are the issues when an endpoint that was pa=
rt of configuration issues a re-direct? There are good and bad scenarios (e=
.g. to a specific cluster node), a resource that was relocated, or a hacked=
 service that wants to steal tokens.=C2=A0 In these cases, should the clien=
t re-validate the new resource URI either using this draft or the bound con=
fig method?

    On a positive note, unrelated =
to security, there have been a lot of inquiries over the years about how to=
 authorize against on user-owned resources.=C2=A0 E.g. How can I ask for au=
thorizations to Brian=E2=80=99s github project?=C2=A0 I think this is worth=
 discussing.=C2=A0 Weighing the security and functionality needs would be a=
 worthwhile discussion in BA.

    

    On Mar 21, 2=
016, at 10:41 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
    Very minor updat=
e to this draft before the deadline that moves Hannes from Acknowledgements=
 to Authors in acknowledgment of his similar work a few years ago. Also fle=
shed out the IANA section with the formal registration requests. 
    <=
br>

    ---------- Forwarded message ----------
    From:  <internet-drafts@ietf.org>
    Date: Mon, =
Mar 21, 2016 at 11:31 AM
    Subject: New Version Notification for draft-cam=
pbell-oauth-resource-indicators-01.txt
    To: Hannes Tschofenig <hannes.tschofenig@g=
mx.net>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Brian Campbell=
 <brian.=
d.campbell@gmail.com>, John Bradley <ve7jtb@ve7jtb.com>



    
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
    
has been successfully submitted by Brian Campbell and posted to the
    
IETF repository.
    

    
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-resource=
-indicators
    
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
    
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resource Indicators for OAuth 2.0<=
br>
Document date:=C2=A0 2016-03-21
    
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
    
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ca=
mpbell-oauth-resource-indicators-01.txt
    
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-campbell-oauth-resour=
ce-indicators/
    
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators=
-01
    
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell=
-oauth-resource-indicators-01
    

    
Abstract:
    
=C2=A0 =C2=A0This straw-man specification defines an extension to The OAuth=
 2.0
    
=C2=A0 =C2=A0Authorization Framework that enables the client and authorizat=
ion
    
=C2=A0 =C2=A0server to more explicitly to communicate about the protected
=C2=A0 =C2=A0resource(s) to be accessed.
    

    

    

    

    
Please note that it may take a couple of minutes from the time of submissio=
n
    
until the htmlized version and diff are available at tools.ietf.org.
    

    
The IETF Secretariat
    

    


    


    
_______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    http=
s://www.ietf.org/mailman/listinfo/oauth

    

--001a113ecbe4f97e8c052ea46301--


From nobody Tue Mar 22 08:08:37 2016
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 977E012D866 for ; Tue, 22 Mar 2016 08:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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] 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 spcsIFby0Yff for ; Tue, 22 Mar 2016 08:08:30 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 B159D12D8A2 for ; Tue, 22 Mar 2016 08:08:29 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id cl4so56915276igb.0 for ; Tue, 22 Mar 2016 08:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NjpYKbRtZeIMy1ZS765JAw4Sw/trNcwGcPftjERDw2A=; b=bwxdPJWeDcMH5PejL18wxYMwpx41ds0KqId0p29Cuv6AK7g72LMTv4yCA28YoUFKPh QogeJRunMlPDgaSz3ebrmuH0S5tXrEB2zp5DImCarbflKkQcy0dUpqRqW0kDdPBPqslZ 0QmQjQUw5iVembIZaTUtwFvj93/uE3fyRQ9no=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NjpYKbRtZeIMy1ZS765JAw4Sw/trNcwGcPftjERDw2A=; b=Ze34I0PH47sVQl760gOXFjT10VzI8tgdFwAeJKtwbZZc8soirldeZ1+N16sDVribEO wtYq9rXpCvogMn2NQpKSc/OxqdMP7mIG5Jfqleje+BusjpDqV3D+HIGoZs9+OAbkJ5v9 Z9GuBDEPdv6mhDkRqewkEUQL3s1ujd/Z6MCN+uADhFEB+oU99lMMizqdd+6r47DNf9w3 IBbcGN2poO8Hl+MTvVeg7c1x9pq5PgEDTExVxHe7rbXodC3KnOqM8m8GCPD2Ki1xWrmG O6W6yfRg6oAh81JY8giDfONJO4nb46DqIp2kww431F7z4G9rxZAKURItTEIgIqcb3f7q AEtQ==
X-Gm-Message-State: AD7BkJIM1cw5Bu2n4YrbPhvt/T3hDaxCgmpbPQDBxC6/Q3vhuGZLRY220uFxwN7XqSMh+GjZoXPtOF0wEWtDjWxh
X-Received: by 10.50.50.198 with SMTP id e6mr18417810igo.57.1458659308968; Tue, 22 Mar 2016 08:08:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.28.196 with HTTP; Tue, 22 Mar 2016 08:07:59 -0700 (PDT)
In-Reply-To: <56F15BDD.9020005@gmail.com>
References: <20160321173103.31961.76817.idtracker@ietfa.amsl.com>   <0DBACD62-E2FB-43D2-A2F6-F1A16794117A@oracle.com> <56F15BDD.9020005@gmail.com>
From: Brian Campbell 
Date: Tue, 22 Mar 2016 09:07:59 -0600
Message-ID: 
To: Sergey Beryozkin 
Content-Type: multipart/alternative; boundary=047d7bd75df2f5dccc052ea495eb
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 15:08:35 -0000

--047d7bd75df2f5dccc052ea495eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

'aud' can't be used b/c it conflicts with the (yet to be registered) 'aud'
claim/parameter in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq and
JWS/E requests in Connect (honestly, I'd like to use aud because we've
already done so in product but I don't think it works given the spec
landscape). Also, as you mention, 'resource' is what the client is
concerned with accessing. So the name is more representative of what it
actually is.

Yes, some more discussion of default or legacy behaviors based on config or
policy or registration is probably warranted. I suppose that begs the
question of if a OAuth Dynamic Client Registration Metadata parameter
should be defined too?



On Tue, Mar 22, 2016 at 8:51 AM, Sergey Beryozkin 
wrote:

> Hi
>
> Is there any reason why 'resource' parameter can not be named 'aud' or
> 'audience' ?
>
> The text says "AS should audience restrict" the access token and that a
> token 'aud' property may be equal to this "resource" value.
>
> I guess 'audience' is a pure access token property, while as far as clien=
t
> is concerned, it is a 'resource', but I wonder if it would be a bit simpl=
er
> if only a single property was used.
>
> It also might make sense to mention that the clients can have 'resource'
> values associated with them at the registration time - this can be done b=
y
> admins, and the client applications will not have to be configured to sen=
d
> 'resource' given that AS already knows about the resource restrictions.
>
> Cheers, Sergey
>
>
>
>
> On 21/03/16 23:15, Phil Hunt wrote:
>
>> What about server processing rules and error conditions?  The client
>> passes the resource in with every request. What happens if it sends a
>> bad URL.  I see the registration for invalid_resource, but I see no
>> processing logic for the server that describes when that is returned.
>>   I=E2=80=99ll assume that is TBD.
>>
>> The draft seems more finer grained than with bound configuration
>> approach.  It suggests that the client will make a different URL request
>> for each resource URL. This could lead to a lot of unnecessary
>> authorizations.  I think we still have to resolve the audience to
>> resource relationship problem and just how much detail the AS service
>> needs to know.
>>
>> I note that we have a similar issue with bound config on how granular
>> resource URL processing is needed.  My main goal is for config to
>> validate the domain name only as a major improvement as we just need to
>> make sure the client is talking to a valid server and not a MITM proxy.
>>
>> Finally, there is the question of optionality (in order to have
>> backwards compatibility for static clients). If resource is optional,
>> than how do we deal with dynamic clients that simply don=E2=80=99t both =
to use
>> the resource parameter?
>>
>> We=E2=80=99re depending on client developers taking an extra step to pro=
vide the
>> resource parameter. Maybe optionality for resource url becomes part of
>> the client_id registration?  In contrast, config discovery is brand new,
>> so making validation required is not such a big deal as static clients
>> wouldn=E2=80=99t use discovery.
>>
>> Another failure condition both drafts should consider:
>> * when an authorization, token, or resource endpoint starts to fail,
>> should the client fall back to discovery to re-verify configuration?  If
>> so, on what errors?  A valid usecase would be a service provider
>> deciding to re-configure its services naturally over time.
>> * what are the issues when an endpoint that was part of configuration
>> issues a re-direct? There are good and bad scenarios (e.g. to a specific
>> cluster node), a resource that was relocated, or a hacked service that
>> wants to steal tokens.  In these cases, should the client re-validate
>> the new resource URI either using this draft or the bound config method?
>>
>> *On a positive note, unrelated to security, there have been a lot of
>> inquiries over the years about how to authorize against on user-owned
>> resources.  E.g. How can I ask for authorizations to Brian=E2=80=99s git=
hub
>> project?  I think this is worth discussing.  Weighing the security and
>> functionality needs would be a worthwhile discussion in BA.*
>>
>> Phil
>>
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>
>>
>>
>>
>>
>> On Mar 21, 2016, at 10:41 AM, Brian Campbell
>>> > wrote:
>>>
>>> Very minor update to this draft before the deadline that moves Hannes
>>> from Acknowledgements to Authors in acknowledgment of his similar work
>>> a few years ago. Also fleshed out the IANA section with the formal
>>> registration requests.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: ** >
>>> Date: Mon, Mar 21, 2016 at 11:31 AM
>>> Subject: New Version Notification for
>>> draft-campbell-oauth-resource-indicators-01.txt
>>> To: Hannes Tschofenig >> >, Hannes Tschofenig
>>> >, Brian
>>> Campbell >> >, John Bradley >> >
>>>
>>>
>>>
>>>
>>> A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
>>> has been successfully submitted by Brian Campbell and posted to the
>>> IETF repository.
>>>
>>> Name:           draft-campbell-oauth-resource-indicators
>>> Revision:       01
>>> Title:          Resource Indicators for OAuth 2.0
>>> Document date:  2016-03-21
>>> Group:          Individual Submission
>>> Pages:          8
>>> URL:
>>>
>>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indi=
cators-01.txt
>>> Status:
>>>
>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicato=
rs/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
>>> Diff:
>>>
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-campbell-oauth-resource-indic=
ators-01
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> 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
>>> .
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--047d7bd75df2f5dccc052ea495eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    'aud' can't be used b/c it conflicts with=
 the (yet to be registered) 'aud' claim/parameter in https://tools.ietf.org/ht=
ml/draft-ietf-oauth-jwsreq and JWS/E requests in Connect (honestly, I&#=
39;d like to use aud because we've already done so in product but I don=
't think it works given the spec landscape). Also, as you mention, '=
;resource' is what the client is concerned with accessing. So the name =
is more representative of what it actually is.

    Yes, some more =
discussion of default or legacy behaviors based on config or policy or regi=
stration is probably warranted. I suppose that begs the question of if a OA=
uth Dynamic Client Registration Metadata parameter should be defined too?=
=C2=A0 



    On Tue, Mar 22, 2016 at 8:51 AM, Sergey Beryozkin <s=
beryozkin@gmail.com> wrote:
    Hi
    

    
Is there any reason why 'resource' parameter can not be named '=
aud' or 'audience' ?
    

    
The text says "AS should audience restrict" the access token and =
that a token 'aud' property may be equal to this "resource&quo=
t; value.
    

    
I guess 'audience' is a pure access token property, while as far as=
 client is concerned, it is a 'resource', but I wonder if it would =
be a bit simpler if only a single property was used.
    

    
It also might make sense to mention that the clients can have 'resource=
' values associated with them at the registration time - this can be do=
ne by admins, and the client applications will not have to be configured to=
 send 'resource' given that AS already knows about the resource res=
trictions.
    

    
Cheers, Sergey

    

    

    

    
On 21/03/16 23:15, Phil Hunt wrote:
    

    
What about server processing rules and error conditions?=C2=A0 The client
passes the resource in with every request. What happens if it sends a
    
bad URL.=C2=A0 I see the registration for invalid_resource, but I see no
processing logic for the server that describes when that is returned.
    
=C2=A0 I=E2=80=99ll assume that is TBD.
    

    
The draft seems more finer grained than with bound configuration
    
approach.=C2=A0 It suggests that the client will make a different URL reque=
st
    
for each resource URL. This could lead to a lot of unnecessary
    
authorizations.=C2=A0 I think we still have to resolve the audience to
    
resource relationship problem and just how much detail the AS service
    
needs to know.
    

    
I note that we have a similar issue with bound config on how granular
    
resource URL processing is needed.=C2=A0 My main goal is for config to
    
validate the domain name only as a major improvement as we just need to
    
make sure the client is talking to a valid server and not a MITM proxy.
    

    
Finally, there is the question of optionality (in order to have
    
backwards compatibility for static clients). If resource is optional,
    
than how do we deal with dynamic clients that simply don=E2=80=99t both to =
use
    
the resource parameter?
    

    
We=E2=80=99re depending on client developers taking an extra step to provid=
e the
    
resource parameter. Maybe optionality for resource url becomes part of
    
the client_id registration?=C2=A0 In contrast, config discovery is brand ne=
w,
    
so making validation required is not such a big deal as static clients
    
wouldn=E2=80=99t use discovery.
    

    
Another failure condition both drafts should consider:
    
* when an authorization, token, or resource endpoint starts to fail,
    
should the client fall back to discovery to re-verify configuration?=C2=A0 =
If
    
so, on what errors?=C2=A0 A valid usecase would be a service provider
    
deciding to re-configure its services naturally over time.
    
* what are the issues when an endpoint that was part of configuration
    
issues a re-direct? There are good and bad scenarios (e.g. to a specific
cluster node), a resource that was relocated, or a hacked service that
    
wants to steal tokens.=C2=A0 In these cases, should the client re-validate<=
br>
the new resource URI either using this draft or the bound config method?

    
*On a positive note, unrelated to security, there have been a lot of
    
inquiries over the years about how to authorize against on user-owned
    
resources.=C2=A0 E.g. How can I ask for authorizations to Brian=E2=80=99s g=
ithub
    
project?=C2=A0 I think this is worth discussing.=C2=A0 Weighing the securit=
y and
    
functionality needs would be a worthwhile discussion in BA.*
    

    
Phil
    

    
@independentid
    
www.independentid.com <http://www.independentid.com>
phil.hunt@oracle.=
com <mailto:phil.hunt@oracle.com>
    

    

    

    

    

    

    
On Mar 21, 2016, at 10:41 AM, Brian Campbell
    
<bcampbe=
ll@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
    

    
Very minor update to this draft before the deadline that moves Hannes
    
from Acknowledgements to Authors in acknowledgment of his similar work
    
a few years ago. Also fleshed out the IANA section with the formal
    
registration requests.
    

    

    
---------- Forwarded message ----------
    
From: ** <=
internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
    
Date: Mon, Mar 21, 2016 at 11:31 AM
    
Subject: New Version Notification for
    
draft-campbell-oauth-resource-indicators-01.txt
    
To: Hannes Tschofenig <hannes.tschofenig@gmx.net
    
<mailto:h=
annes.tschofenig@gmx.net>>, Hannes Tschofenig
    
<Hannes.T=
schofenig@gmx.net <mailto:Hannes.Tschofenig@gmx.net>>, Brian
    
Campbell <brian.d.campbell@gmail.com
    
<mailto:=
brian.d.campbell@gmail.com>>, John Bradley <ve7jtb@ve7jtb.com
    
<mailto:ve7jtb@ve=
7jtb.com>>

    

    

    

    
A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
    
has been successfully submitted by Brian Campbell and posted to the
    
IETF repository.
    

    
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-campbell-oauth-resource=
-indicators
    
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
    
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resource Indicators for OAuth 2.0<=
br>
Document date:=C2=A0 2016-03-21
    
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
    
URL:
    
https://www.ietf=
.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
Status:
    
https://datatracker.ietf.o=
rg/doc/draft-campbell-oauth-resource-indicators/
    
Htmlized:
    
https://tools.ietf.org/html/d=
raft-campbell-oauth-resource-indicators-01
    
Diff:
    
https://www.ietf.org/=
rfcdiff?url2=3Ddraft-campbell-oauth-resource-indicators-01
    

    
Abstract:
    
=C2=A0 =C2=A0This straw-man specification defines an extension to The OAuth=
 2.0
    
=C2=A0 =C2=A0Authorization Framework that enables the client and authorizat=
ion
    
=C2=A0 =C2=A0server to more explicitly to communicate about the protected
=C2=A0 =C2=A0resource(s) to be accessed.
    

    

    

    

    
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
    
<http://tools.ietf.org/>.
    

    
The IETF Secretariat
    

    

    

    
_______________________________________________
    
OAuth mailing list
    
    OAuth@ietf.org <mailto:OAuth@iet=
f.org>
    
https://www.ietf.org/mailman/listinfo/oauth
    

    

    

    

    
_______________________________________________
    
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
    


    

--047d7bd75df2f5dccc052ea495eb--


From nobody Wed Mar 23 08:07:54 2016
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 9A7AC12D1EB for ; Wed, 23 Mar 2016 08:07:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160323150752.2489.4043.idtracker@ietfa.amsl.com>
Date: Wed, 23 Mar 2016 08:07:52 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [OAUTH-WG] Milestones changed for oauth WG
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 15:07:52 -0000

Changed milestone "Submit 'Request by JWS ver.1.0 for OAuth 2.0' to
the IESG for consideration as a Proposed Standard", set due date to
April 2016 from February 2016.

Changed milestone "Submit 'Proof-of-Possession OAuth Security'
document bundle for consideration as a Proposed Standard", set due
date to June 2016 from April 2016.

URL: https://datatracker.ietf.org/wg/oauth/charter/


From nobody Wed Mar 23 08:19:50 2016
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 ED43112D5C1 for ; Wed, 23 Mar 2016 08:19:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160323151948.2522.49513.idtracker@ietfa.amsl.com>
Date: Wed, 23 Mar 2016 08:19:48 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [OAUTH-WG] Milestones changed for oauth WG
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 15:19:49 -0000

Deleted milestone "Submit 'Proof-of-Possession OAuth Security'
document bundle for consideration as a Proposed Standard".

URL: https://datatracker.ietf.org/wg/oauth/charter/


From nobody Thu Mar 24 01:22:03 2016
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 ECF9C12D14B for ; Thu, 24 Mar 2016 01:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EY5s1YuyVcNb for ; Thu, 24 Mar 2016 01:22:00 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56F712D107 for ; Thu, 24 Mar 2016 01:21:59 -0700 (PDT)
Received: from [192.168.10.140] ([47.73.229.30]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MhRI2-1aMXjT0Sn4-00Mclg for ; Thu, 24 Mar 2016 09:21:57 +0100
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56F3A3A6.1070308@gmx.net>
Date: Thu, 24 Mar 2016 09:21:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Mbm51fPKWsm91KQN7TbH1TOcg0ApLKRdN"
X-Provags-ID: V03:K0:QhpFFckJBDDi3BedYuhWAYjqOmk37EUJcJdqKv6z6xqSSPMPY7F wJCrEdyON1/PXAL0afSlyTdXo0qHECxMlP5/KU/u7VwivE7QJsmRWO7x7btYiDEFB7PlhWo AL7IgPnG1C79xfJogjCnqwVrBK59Ueue38D3OCXG7WanIb5hv40gOcvp8GjKpInjmNfM4FT ZIkieEqQTY3rXx3+TyQ8A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Ard+IXQp+eE=:35Jz4Y8VrqPS9nYvnAfe3I Vq0yTd+4/kcV5PJ8c+bsrgYz3Miz34RuYfSKYP1tN/XwcAfUYxyci4G9/LnXVqV1OqUGATF3H 7Pxru6/IxMXxmkwYFKjnA1PSlFoMxALbEOfNyx0cGCkoibTGzYZJW00OZbrXJcUsh8DmuDd3r 4+DIeotv6Zc0GXMY1oivzRHFHwAOfZhZftwCzskHy0sx3EbrL3i7SmFYIFCzyrR/RK5OXmgoY hegTKNuLVQCQQgjXerpTKL9SOpbm/xLBOKL3w6wdZ2364bJt7crT+o47jm2u3QwnXBVWcQOHO QRfKMifjm0uEBgRlhz7JvJK+QHzfhxLTeOLFD6fo7waYjpqaMR5BmbU1ZB9B3wmDMANcBktKQ f15YnllRFD5dkZawoR3tAYwUPzY2aJa4GX5sCu7qmQxG23QmpZq7Y/4NKsKN8Bnx+DTItPzIK 8WwdR+b0o8aNL26qeGsomxWpJLRVJl+7GnPcIL+fGPcMOX6jfrE9Y2bibh0LczNJqHnf3CdZ2 QzYzZsmevREEWbOP9/4chB37Jrs7Fpnql0hoIXUW1emm3hh49z8TxWcQxuxfO2y/yjx26Fx4s PgV6JVcyi/Qu2X7OK7fDL/NXd9bEWvVQum2Xq5tCXT/IxhY6O4wh4aP3NHgMpJ6yR4vAChNzH F+Nzhy7ikeQf+rH+D/oihfMXWWzCsXESavBpDqgotqbVIjxRF35AHCeb0MhsCBuvj5SDBaO2P ZZfjVrsKNgUs3huh696wkZ/O3CRcWTWmqDqzNPdgEs0WSPlYOR3rSCVZx2g=
Archived-At: 
Subject: [OAUTH-WG] Milestone Updates
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 08:22:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Mbm51fPKWsm91KQN7TbH1TOcg0ApLKRdN
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

I made a couple of changes to the milestones to adjust the dates for
some items and to add new milestones for the recently adopted drafts.

The new items still need to be approved by the AD. I also added separate
items for the PoP drafts (instead of having a single item) for better
visibility and tracking of the completion dates.

Here is how this looks like for me:
---------


Done	Submit 'OAuth 2.0 Proof-of-Possession (PoP) Security Architecture'
to the IESG Awaiting accept

Done	Submit 'Proof-of-Possession Key Semantics for JSON Web Tokens
(JWTs)' to the IESG Awaiting accept

Apr 2016	Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for
consideration as a Proposed Standard

Apr 2016	Submit 'OAuth 2.0 Authorization Server Discovery Metadata' to
the IESG Awaiting accept

May 2016	Submit 'Authentication Method Reference Values' to the IESG
Awaiting accept

Jun 2016	Submit 'OAuth 2.0 Mix-Up Mitigation'to the IESG Awaiting accept

Jul 2016	Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration
as a Proposed Standard

Jul 2016	Submit 'OAuth 2.0 Security: Closing Open Redirectors in OAuth'
to the IESG Awaiting accept

Jul 2016	Submit 'OAuth 2.0 Proof-of-Possession: Authorization Server to
Client Key Distribution' to the IESG Awaiting accept

Jul 2016	Submit 'A Method for Signing HTTP Requests for OAuth' to IESG
Awaiting accept

Oct 2016	Submit 'OAuth 2.0 Device Flow' to the IESG Awaiting accept

Nov 2016	Submit 'OAuth 2.0 for Native Apps' to the IESG Awaiting accept

---------


We have to discuss the completion dates of the items; I tentatively
proposed dates but I need to get a better understanding of the expected
actions that have to be done before the documents get finalized.

Ciao
Hannes & Derek


--Mbm51fPKWsm91KQN7TbH1TOcg0ApLKRdN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJW86OmAAoJEGhJURNOOiAtB64H/0kLFaDZwqX4TF4MWAfdAPpI
/qPfq6MiD5UJMw9xM7CqJfd5YpMH2mUbVxXcCEHsYJC4XyTFpvIyY0IgLcYa+G+K
HowXI90Embaodj8UFcTvtVipXc3NSXuBv8Y5DmTlwukHTWJ3nJWKt7DiQ+0BhYjw
1LG3VSazy8RnXrtsrcWgOg0LWwAMHpHx+zdCIsgJfCKiSkY6rj8zw6YhVLMcQ4pe
f3BdLLfhBm6F9FGmecONl9wpfOePO1XeXLGqzKOak+gIX8GYe3DFjErbVJ2kr6Ih
nh5vdLTS9fAmccOndCYAsY/6JxLrT5+Mfrh6wYsVmkPsgv4dAp6XCrb6JmYdOtQ=
=CPTz
-----END PGP SIGNATURE-----

--Mbm51fPKWsm91KQN7TbH1TOcg0ApLKRdN--


From nobody Thu Mar 24 03:40:09 2016
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 2E3EA12D6D1 for ; Thu, 24 Mar 2016 03:40:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160324104008.3890.99863.idtracker@ietfa.amsl.com>
Date: Thu, 24 Mar 2016 03:40:08 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [OAUTH-WG] Milestones changed for oauth WG
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 10:40:08 -0000

Changed milestone "Submit 'OAuth 2.0 Proof-of-Possession (PoP)
Security Architecture' to the IESG", set state to active from review,
accepting new milestone.

Changed milestone "Submit 'Proof-of-Possession Key Semantics for JSON
Web Tokens (JWTs)' to the IESG", set state to active from review,
accepting new milestone.

Changed milestone "Submit 'OAuth 2.0 Authorization Server Discovery
Metadata' to the IESG", set state to active from review, accepting new
milestone.

Changed milestone "Submit 'Authentication Method Reference Values' to
the IESG", set state to active from review, accepting new milestone.

Changed milestone "Submit 'OAuth 2.0 Mix-Up Mitigation'to the IESG",
set state to active from review, accepting new milestone.

Changed milestone "Submit 'OAuth 2.0 Security: Closing Open
Redirectors in OAuth' to the IESG", set state to active from review,
accepting new milestone.

Changed milestone "Submit 'OAuth 2.0 Proof-of-Possession:
Authorization Server to Client Key Distribution' to the IESG", set
state to active from review, accepting new milestone.

Changed milestone "Submit 'A Method for Signing HTTP Requests for
OAuth' to IESG", set state to active from review, accepting new
milestone.

Changed milestone "Submit 'OAuth 2.0 Device Flow' to the IESG", set
state to active from review, accepting new milestone.

Changed milestone "Submit 'OAuth 2.0 for Native Apps' to the IESG",
set state to active from review, accepting new milestone.

URL: https://datatracker.ietf.org/wg/oauth/charter/


From nobody Thu Mar 31 15:46:01 2016
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 2B77612D8D1 for ; Thu, 31 Mar 2016 15:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=jive-com.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 hPmq70TO6gMe for ; Thu, 31 Mar 2016 15:45:56 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 030AC12D8CD for ; Thu, 31 Mar 2016 15:45:56 -0700 (PDT)
Received: by mail-pa0-x233.google.com with SMTP id zm5so75786966pac.0 for ; Thu, 31 Mar 2016 15:45:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NB3I6XbJIjVslTca+f/ojsqJNezAvw7QhAWda7/Kk5E=; b=O7uA+v4jD1CU3nvUjuL0UhrakJ1EpaVcVnD6G4i6IVKvXz+ygU/veuaId1fAIwOB2E xmWf0qLk3Ep7H9sQF1Jj0FtBAC8HK14Ur3+a4sEbLJup1sJUVR2y3Z9/5/p4BErJl9Xq 7pnrGDyahj+UvIV/r3/HUfd7/MrTWaAFBCj6C4X/LXfxyr0v+CAoBvNA6ccXeLpwRVXi XAHWnXrHrLu+UPOD0SKdRlZo0kOHDs9mWi8DqlcYo9AunlCTH5gnu8p9kXW060mM0TRu Ol92Srtf4aweXZ/UScXDkedF3TLrnEIMbxbtMVNQ3ycXzkC9QlUgnSYERF98pbV6mBEN /oHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NB3I6XbJIjVslTca+f/ojsqJNezAvw7QhAWda7/Kk5E=; b=ISCffjTRW+JutPZsruOGD+96zCVVenNg9PFfeSdgvXDm8G23GKk2YWUkJcEXJ+A+Yw jArQ+/n/x0dzIgYuPqq8LMbtqSUIQAGJyw9LOMQJXT/sX0/fkOpkexN6oLGRyIEShQ1I awM+ssnu+YQ7Q8al+/K9xWUaGtaJksus7yfV7VAqZS2Th3EYTieccx964bfvDnaL1n9B 8XlYw23bUmblgjaf1E3w7WcEbmO6888jsnhw35UqtHXKESxCRt/s880J4229JtkyFtlJ niRzM/VUSn4zJdgA9KmJnHB6EHE+Nv08lsC5PdfRGRhZIaUEW2BcSmQTgXa6hrOMRFnx x6Mw==
X-Gm-Message-State: AD7BkJIB9JpljkqK0T7LWZHOkPHOfIvrug7bcenyYKtraFXDu/+J84W64D/gGGtdwXVyhWaKEbB8bFVZWfQQcSZPICGArSRRqsD6Y91PZAK7kVFrUJzvS9tM
X-Received: by 10.67.21.231 with SMTP id hn7mr25722657pad.150.1459464355562; Thu, 31 Mar 2016 15:45:55 -0700 (PDT)
Received: from jivecommunications.com ([199.87.120.129]) by smtp.gmail.com with ESMTPSA id 8sm15702753pfk.69.2016.03.31.15.45.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 15:45:54 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Eduardo Gueiros 
In-Reply-To: 
Date: Thu, 31 Mar 2016 16:45:53 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <765CA63F-AC28-4BF7-BB63-3583383BF08F@jive.com>
References: 
To: William Denniss 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries for Android and iOS now available
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 22:45:59 -0000

Any plan to bring the libraries to more =E2=80=9Cyoung=E2=80=9D =
languages like Swift in iOS and Kotlin in Android?

> On Feb 26, 2016, at 12:30 PM, William Denniss  =
wrote:
>=20
>=20


From nobody Thu Mar 31 22:06:13 2016
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 97EBB12D120 for ; Thu, 31 Mar 2016 22:06:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=leastprivilege-com.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 WKVas43AZjdv for ; Thu, 31 Mar 2016 22:06:10 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 9114C12D0BA for ; Thu, 31 Mar 2016 22:06:10 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id 20so8017674wmh.1 for ; Thu, 31 Mar 2016 22:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=3KyIeK4eE3CUmS8DwT4/VJM00FofmF8iftf5y1eq+h8=; b=1M9XevRmGFSVPyLuX6y4wGMniS0lUKJKNszvR6Ty4z/dKt0wuqEsUDLLVXbg7v+v+J aJjg5OdT7xridBtXjx5R6b3dDvHx9kuzN8u3GTvf5kmWXP+DLOJ4GSUNuyRHxtct5CpW 11FQF9NVN4twXfMoCP2o0mgUe0t5K8fRwFt4FQWbr1UP6M5Ep96s+O4mGgls4bfh6NG9 rJvLNhhJmcJj6Jb1QjB+n99mBHpCd3zhqI1C+btIYYHRgXorA5nyM6r52KyWsSuYGns3 OXEBEzKGUxt3E6NcLoowqCQVrnpMJOKgl3T5AAFru7B4Riv0vOJAtvz1qL4J53o/Jy4W UgQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=3KyIeK4eE3CUmS8DwT4/VJM00FofmF8iftf5y1eq+h8=; b=ZdENon4oUhv/TGF/bm1QnIsvd7yGpf30SXSrkLCKBTtR5Qyd/ziPsDDLL9JjKnsLmT bkJJB5cK+D8iyJJNssHd3klXSI0yTLMFx4sPT4/qR0VnpJDkkNhdzqZ1NQBWLU5xADDF hV4IbaKla95fO7ZLizHwc1ks72FrWXpBrWqdE0Ufaa/7cPJtE5f+7SWxRIAALknqYULo CAmGfEi0LyFF/mgwAsSfcTECMCEU2UnQ9eTj3D0TTmrwF930BFii9ENR2sgKG+3ly3G2 uuomXaxluNfAzUuXoHoMWJCWjkrlbEI2vHd1SchwhBYNlXOFeoQ2pHslEg0zVUcGZsuY KpSQ==
X-Gm-Message-State: AD7BkJKuhkuqBjgXOVXH4zMArloVh3NW3wjOxvmItdDzNjfLZcxrsf/iRPExeJ/xDp/xuQ==
X-Received: by 10.28.10.18 with SMTP id 18mr1386490wmk.64.1459487169133; Thu, 31 Mar 2016 22:06:09 -0700 (PDT)
Received: from dombp.fritz.box (HSI-KBW-078-042-013-201.hsi3.kabel-badenwuerttemberg.de. [78.42.13.201]) by smtp.gmail.com with ESMTPSA id jf6sm12174249wjb.2.2016.03.31.22.06.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2016 22:06:08 -0700 (PDT)
Date: Fri, 1 Apr 2016 07:06:07 +0200
From: Dominick Baier 
To: Eduardo Gueiros , William Denniss 
Message-ID: 
In-Reply-To: <765CA63F-AC28-4BF7-BB63-3583383BF08F@jive.com>
References:  <765CA63F-AC28-4BF7-BB63-3583383BF08F@jive.com>
X-Mailer: Airmail (351)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="56fe01bf_665fce6a_217"
Archived-At: 
Cc: "=?utf-8?Q?oauth=40ietf.org?=" 
Subject: Re: [OAUTH-WG] OAuth 2.0 for Native Apps: open source client libraries for Android and iOS now available
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2016 05:06:12 -0000

--56fe01bf_665fce6a_217
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I am working on a xplat library for .net/xamarin iOS, Android, WinPhone, =
Windows written in C=23.

https://github.com/IdentityModel/IdentityModel.OidcClient

We are making good progress, but the xplat crypto story is the hardest pa=
rt here.

If anybody wants to contribute, contact me via github.

=E2=80=94=C2=A0
cheers
Dominick Baier

On 1 April 2016 at 00:46:03, Eduardo Gueiros (egueiros=40jive.com) wrote:=


Any plan to bring the libraries to more =E2=80=9Cyoung=E2=80=9D languages=
 like Swift in iOS and Kotlin in Android=3F

> On =46eb 26, 2016, at 12:30 PM, William Denniss =
 wrote:
> =20
> =20

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--56fe01bf_665fce6a_217
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


    On Mar 13, 2016, at 8:12 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

    This draft is =
a proposed alternate proposal for draft-ietf-oauth-discovery.  As =
such, it contains the same registry for OAuth Config Metadata as the =
authors believe that both solutions are not required, or depending on WG =
discussion they will be merged. The intent is to provide a simple =
complete draft for consideration.

    How it works...
    Given that a client has =
previously discovered an OAuth protected resource, the bound =
configuration method allows a client to return the configuration for an =
oauth authorization server that can issue tokens for the resource URI =
specified by the client.  The AS is not required to be in the same =
domain.  The AS is however required to know if it can issue tokens =
for a resource service (which presumes some agreement exists on tokens =
etc).

    The =
draft does not require that the resource exist (e.g. for unconfigured or =
new user based resources). It only requires that the AS service provider =
agrees it can issue tokens.

    =46rom a security perspective, returning the OAuth service =
configuration for a specified resource URI serves to confirm the client =
is in possession of a valid resource URI ensuring the client has =
received a valid set of endpoints for the resource and the associated =
oauth services.

    I propose that the WG consider the alternate draft carefully =
as well as other submissions and evaluate the broader discovery problem =
before proceeding with WGLC on OAuth Discovery.

    Thanks!

    

    

    



    Begin forwarded message:

    From: internet-drafts@ietf.org
    Subject: New Version Notification for =
draft-hunt-oauth-bound-config-00.txt
    Date: March 13, 2016 at 3:53:37 PM PDT
    To: "Phil Hunt" <phil.hunt@yahoo.com>, "Anthony Nadalin" <tonynad@microsoft.com>, "Tony Nadalin" <tonynad@microsoft.com>


    A new version =
of I-D, draft-hunt-oauth-bound-config-00.txt
    has been =
successfully submitted by Phil Hunt and posted to the
    IETF =
repository.

    Name:		=
draft-hunt-oauth-bound-config
    Revision:	00
    Title:=
		=
OAuth 2.0 Bound Configuration Lookup
    Document =
date:	=
2016-03-13
    Group:		Individual Submission
    Pages:=
		=
22
    URL: =
           https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-con=
fig-00.txt
    Status: =
        https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/=

    Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


    Abstract:
     =
  This specification defines a mechanism for the client of an =
OAuth 2.0
       protected resource service to =
obtain the configuration details of an
       OAuth =
2.0 authorization server that is capable of authorizing access
       to a specific resource service.  The =
information includes the OAuth
       2.0 component =
endpoint location URIs and as well as authorization
     =
  server capabilities.




    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.

    The IETF Secretariat


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