Re: [OAUTH-WG] updated Distributed OAuth ID

Dick Hardt <> Sun, 22 July 2018 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 315CD130E3C for <>; Sun, 22 Jul 2018 15:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8X1nDDTbatye for <>; Sun, 22 Jul 2018 15:53:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5F9B12426A for <>; Sun, 22 Jul 2018 15:53:11 -0700 (PDT)
Received: by 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;; 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;; 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: <>
References: <> <> <> <> <> <>
From: Dick Hardt <>
Date: Sun, 22 Jul 2018 18:52:50 -0400
Message-ID: <>
To: Torsten Lodderstedt <>
Content-Type: multipart/alternative; boundary="000000000000ae506b05719e64cc"
Archived-At: <>
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
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

On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt <> wrote:

> Hi Dick,
> Am 19.07.2018 um 15:46 schrieb Dick Hardt <>om>:
> I think any scenario with multiple resource servers relying on the same AS
>> for authorization where the client acts on behalf of the resource owner
>> qualifies for grant type code and distributed OAuth.
>> Let’s assume a user wants to authorize a client for access to her cloud
>> storage, email account and contacts when setting app the respective app.
> Would you walk me through the user 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 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 via
> 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.