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 315CD130E3C for ; Sun, 22 Jul 2018 15:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X1nDDTbatye for ; Sun, 22 Jul 2018 15:53:12 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 E5F9B12426A for ; Sun, 22 Jul 2018 15:53:11 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id a26-v6so532558pfo.4 for ; Sun, 22 Jul 2018 15:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B6H7jkXjfqctHtXhUtBs+wlTUU6RfJcykkIIipZEtas=; b=kdN05g4l6AkNLfViIm6RiGxMpA+FBP782yQ9QhArN5AwWNEr3gLhNeIBEDqHF6Jp12 COFMvaBkwx8JMUsUpHpZjxaTtkD8yfOFZNeLeqHiEiW4vXRVCsVinFXdJzWddLpUmFCb K0AqKNmB5WR0IVxlmRy5f2mzhlETI71mqeRBxO0+0Lhl53tD830iG0AASe4uVjOqoYPL 8IRIHQD4IwCgIzvpz7vPJQ2s4d5KxbTilITdR03gDjk3YW0Mxrxt0D3q+exiXD83V8Kg +FwiqZTgyLJADmrR1jSS3wKdxXVb8oGRceFpa/dn6n8vcleNW4NYqqflSOEP8R3hZwsv j+9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B6H7jkXjfqctHtXhUtBs+wlTUU6RfJcykkIIipZEtas=; b=E+OuIRyknO5tTFL0t9VyQHFmiaOrnRx8Qqh8i5CGv0mlEcHhQoeC289VYMupH5ZVIL ZQNnPG+/5hOgR/s4ffIryn4Lacwe98w4H8AgeyFdilMbSE4R4B8dBjokDZGVKg+t2A8d Mvg28oKh4wMjXB23un3ZOkdeVtjl0DcLd1C+8rN1WoJLj+K7E08u+cVf5pV1vVacNMbl FmocV7jlG9Obb7wVuIZdwrxk6AW6diZmNLcDcACp3DZX42Gyu3v+radsLqHmKbBxDqjd uKHLAWQjmX50L7Bx7DnS0TDI2I1uQQ+/I7JIuDj6edwTwlZUP2IGeew8AsW7RqzKA0tM H7tw== X-Gm-Message-State: AOUpUlEY49S5wqrrqjVZjkyvCjbZFKYa+dN6W6Jy1pdFOA1C3PobMIsf s4x9KI0fkuXjCORbsDi+2QOv/eTVU+BVmgvdaP2pJg== X-Google-Smtp-Source: AAOMgpc6icko4HZLhuk3jA9Q66dig4AjCZEKXWDmBqyDXubiv1q/OIXrACyZGegHI7oTGhK1Pvp/iY/zx5H19pL4/nc= X-Received: by 2002:a63:6243:: with SMTP id w64-v6mr9906239pgb.179.1532299991468; Sun, 22 Jul 2018 15:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Sun, 22 Jul 2018 15:52:50 -0700 (PDT) In-Reply-To: <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> From: Dick Hardt Date: Sun, 22 Jul 2018 18:52:50 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ae506b05719e64cc" 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: Sun, 22 Jul 2018 22:53:14 -0000 --000000000000ae506b05719e64cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dick, > > Am 19.07.2018 um 15:46 schrieb Dick Hardt : > > I think any scenario with multiple resource servers relying on the same A= S >> for authorization where the client acts on behalf of the resource owner >> qualifies for grant type code and distributed OAuth. >> >> Let=E2=80=99s assume a user wants to authorize a client for access to he= r cloud >> storage, email account and contacts when setting app the respective app. >> > > Would you walk me through the user experience that happened for the clien= t > to do discovery on these three resources? In other words, what did the us= er > do to get the client to call the resource and get back the 401 response? > > > I would assume the user enters the URLs or identifies the respective > service providers in the app (e.g. by entering her email address). The > client then sends an initial request as described in your draft and gets > back the 401. > Entering in an email address that resolves to a resource makes sense. It would seem that even if this was email, calendar etc. -- that those would be different scopes for the same AS, not even different resources. That is how all of Google, Microsoft work today. It seems improbable that an end user is going to post multiple resource end points. But I'm interested if you can present such a use case. > > Doing so for several resources will give the client the AS URL for all > involved resources. If the client compares the iss claims it will figure > our all resources are protected by the same AS and can authorize access v= ia > a single authz code grant flow. > Today, if you had a Google hosted email and a Microsoft hosted email, you would have different AS. Do you have another example? > > kind regards, > Torsten. > --000000000000ae506b05719e64cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt <torsten@l= odderstedt.net> wrote:
Hi Dick,

Am 19= .07.2018 um 15:46 schrieb Dick Hardt <dick.hardt@gmail.com>:

I t= hink any scenario with multiple resource servers relying on the same AS for= authorization where the client acts on behalf of the resource owner qualif= ies for grant type code and distributed OAuth.=C2=A0

Let= =E2=80=99s assume a user wants to authorize a client for access to her clou= d storage, email account and contacts when setting app the respective app.<= /div>

Would you walk me through the u= ser experience that happened for the client to do discovery on these three = resources? In other words, what did the user do to get the client to call t= he resource and get back the 401 response?

I would assume the user enters the URLs or identifies th= e respective service providers in the app (e.g. by entering her email addre= ss). The client then sends an initial request as described in your draft an= d gets back the 401.

Entering i= n an email address that resolves to a resource makes sense. It would seem t= hat even if this was email, calendar etc. -- that those would be different = scopes for the same AS, not even different resources. That is how all of Go= ogle, Microsoft work today.

It seems improbable th= at an end user is going to post multiple resource end points. But I'm i= nterested if you can present such a use case.

=C2= =A0

Doing so for several resources will give the client the AS URL for all i= nvolved resources. If the client compares the iss claims it will figure our= all resources are protected by the same AS and can authorize access via a = single authz code grant flow.

T= oday, if you had a Google hosted email and a Microsoft hosted email, you wo= uld have different AS.=C2=A0

Do you have another e= xample?

=C2=A0

kind regards,
Torsten.

--000000000000ae506b05719e64cc--