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 4A8D0130DEA for ; Tue, 24 Jul 2018 13:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9p03Vo5o4lF for ; Tue, 24 Jul 2018 13:47:11 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) (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 8EE4D1277C8 for ; Tue, 24 Jul 2018 13:47:11 -0700 (PDT) Received: from [84.158.238.150] (helo=[192.168.71.112]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fi4D6-0004iB-Nh; Tue, 24 Jul 2018 22:47:08 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Tue, 24 Jul 2018 22:47:07 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:47:16 -0000 --Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970 Content-Type: multipart/alternative; boundary=Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A Content-Transfer-Encoding: 7bit --Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For every bank (and their customers) there is a set of services run by the b= ank or other entities, which rely on the AS of the particular bank for autho= rization. In some cases, a service may bring its own AS to the party (due to= technical restrictionions). So an RP binding to a certain bank-specific ser= vice ecosystem needs to determine which AS every RS relies on. Authorization= requests for RS relying on the same AS (the bank) can be combined into s si= ngle request/flow resulting in an optimized UX. > Am 24.07.2018 um 22:21 schrieb Dick Hardt : >=20 > I'm trying to understand the use case.=20 >=20 > It still is vague. Are you saying that each of these is run by a different= entity, but all trust the bank as the authorization server to manage if the= user has granted permission to use the resource rather than managing it the= mselves?=20 >=20 > account information, payment initiation, identity, and electronic signatur= e=20 >=20 >> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt wrote: >>=20 >>> And who is the AS? >>=20 >> In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom, it i= s the central AS/IDP.=20 >>=20 >> Why are you asking? >>=20 >>>=20 >>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt wrote: >>>>=20 >>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >>>>>=20 >>>>> In your examples, are these the same AS? >>>>=20 >>>> yes >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: >>>>>> Hi Dick, >>>>>>=20 >>>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >>>>>> >=20 >>>>>> > Entering in an email address that resolves to a resource makes sens= e. It would seem that even if this was email, calendar etc. -- that those wo= uld be different scopes for the same AS, not even different resources. That i= s how all of Google, Microsoft work today. >>>>>>=20 >>>>>> I don=E2=80=99t know how those services work re OAuth resources. To m= e it=E2=80=99s not obvious why one should make all those services a single O= Auth resource. I assume the fact OAuth as it is specified today has no conce= pt of identifying a resource and audience restrict an access token led to de= signs not utilizing audience restriction.=20 >>>>>>=20 >>>>>> Can any of the Google or Microsoft on this list representatives pleas= e comment? >>>>>>=20 >>>>>> In deployments I=E2=80=98m familiar with email, calendar, contacts, c= loud and further services were treated as different resources and clients ne= eded different (audience restricted) access tokens to use it. >>>>>>=20 >>>>>> In case of YES, the locations of a user=E2=80=99s services for accoun= t information, payment initiation, identity, and electronic signature are de= termined based on her bank affiliation (bank identification code). In genera= l, each of these services may be provided/operated by a different entity and= exposed at completely different endpoints (even different DNS domains). >>>>>>=20 >>>>>> kind regards, >>>>>> Torsten. >>>=20 >=20 --Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For every bank (and their c= ustomers) there is a set of services run by the bank or other entities, whic= h rely on the AS of the particular bank for authorization. In some cases, a s= ervice may bring its own AS to the party (due to technical restrictionions).= So an RP binding to a certain bank-specific service ecosystem needs to dete= rmine which AS every RS relies on. Authorization requests for RS relying on t= he same AS (the bank) can be combined into s single request/flow resulting i= n an optimized UX.

Am 24.07.2018 um 22:21 schrieb Dick Hardt &= lt;dick.hardt@gmail.com>:
=
I'm trying to unde= rstand the use case. 

It still is vague. Are you say= ing that each of these is run by a different entity, but all trust the bank as the authorization s= erver to manage if the user has granted permission to use the resource rathe= r than managing it themselves? 

account information, payment initiation, identity, and electronic signature=  

O= n Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt <torsten@lodderste= dt.net> wrote:

And who is the AS?

In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom= , it is the central AS/IDP. 

Why are you asking?


On Mon, Jul 23, 2018 at 12:50 PM= , Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=
Am 23.07.2018 um 13:58 schrieb Dick Hardt <dick.hardt@gmail.com>:

=
In your examples= , are these the same AS?

yes



On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <torsten@lodderstedt.ne= t> wrote:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. I= t would seem that even if this was email, calendar etc. -- that those would b= e different scopes for the same AS, not even different resources. That is ho= w all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it=E2= =80=99s not obvious why one should make all those services a single OAuth re= source. I assume the fact OAuth as it is specified today has no concept of i= dentifying a resource and audience restrict an access token led to designs n= ot utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comme= nt?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud an= d further services were treated as different resources and clients needed di= fferent (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account infor= mation, payment initiation, identity, and electronic signature are determine= d based on her bank affiliation (bank identification code). In general, each= of these services may be provided/operated by a different entity and expose= d at completely different endpoints (even different DNS domains).

kind regards,
Torsten.


= --Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A-- --Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyNDIwNDcwN1owIwYJKoZIhvcNAQkEMRYE FMHCsumItFgxSvSmSk/xKSj5DhyeMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQAhSKmmmN4ehkBBfbFnw5AzinN8Vurj JXOjoF5s/4tsGWy8Tvp7NTMLeAwhlbsyq+yzFs6JRlLF05THi/lrYpY22QTjwFeIaKpZW1Lvj4sL o05IoflkSOIjt0QLPbOJjSQt+ZM3UGOGPz1UK5kHt2vClE0lRzYE1dMx19jq0bDvxSDSYY+32xRd uWs1nZBAYYJSKnHLwUSkBh7JDdeYu43DNshOitEuSG1BUwHyzrRERDhZbSO6pprb2eR43QJcxYMD X4BRoZlG7wCD5BVF4QNCcx/E/6XfNRADC4HTApxHJKYk9qs7dQrNdkKNEFz3JqVJXy4pcP7VfoTm P+q7EJwMAAAAAAAA --Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970--