Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

Eric Rescorla <ekr@rtfm.com> Sun, 22 July 2018 22:02 UTC

Return-Path: <ekr@rtfm.com>
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 9E072131030 for <oauth@ietfa.amsl.com>; Sun, 22 Jul 2018 15:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 LDofixxpaE-L for <oauth@ietfa.amsl.com>; Sun, 22 Jul 2018 15:02:36 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 8DEE313104C for <oauth@ietf.org>; Sun, 22 Jul 2018 15:02:35 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id a134-v6so5064211lfe.6 for <oauth@ietf.org>; Sun, 22 Jul 2018 15:02:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3WNjvG/kgFdLrwWLnW3xOKC36mY3Fjkn4lflLZtfwao=; b=AkxwgUfKKMExGTplVQERsXXIrHPnx8kPuV1f2bklgDoJ63/fgAUcW2qPGFKlNgmIBU cB/hTJXi+9DwM8Gvia4zBTXO/K3QMS3wFrNP7dldRgM5F2mJlSEBAhzWkVkusVnV3Vd0 Ol+V5KmpzojKqWmwqClSf+PoOH2mvcPnFrzsVR1rWHQg4dpilqgu0HUqODnBC/26vaV5 PXOJT9vR6Gzn93SNV1Exu3TqIILD4NlivAIetTZVQSY6qTWMQeGxDOAsBCM2bvFzsVeI nKj4SO3GiRNLW8eisWfEFydn7Hfu3//aHD0TKAJsCdWqEi6YGyqHft1kKQS9elnCF1r0 xpgA==
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=3WNjvG/kgFdLrwWLnW3xOKC36mY3Fjkn4lflLZtfwao=; b=ZQ0mIPtc8VY6ZraLRg9h0xVLkAaeUOLV6KoJwVRvw8xBz/8MnaKD3HJX+dT6mHa256 9hZnHe1YKwflFBA2QsIwDRavUkogNJXkfPEE4P2sJBhfG/gVEttAnGO9NatTuUGthVVb RCcVevgfzNhmzx3p2l2Ej357w8+g52ICgGALCWgdLMQ+GgEHnxEKFMY+c09iCPXUx47G 8/oSjHmbF37B/wZ9DSKRApbnKsX4ZOo3q9+aXPAWZm3kZQXngF2hByPtGkMHLekLdNaX U+JizdnqOO0OLva0sRucKwXmdHwEk7EZnLW0vkBdjszczXgIa3kKgHWtBM9Y114ut5Em 674g==
X-Gm-Message-State: AOUpUlHPJx6HaZBixZq4JMtNXcFuqU1GwOpcAVC7L1BEdp63JYan0smn P0uNVNRlSjKOIqUkS6kIuDZYAA0CsxwejwCGjrXvJA==
X-Google-Smtp-Source: AAOMgpfawHP6sHN5Tfg+kqvt96EVXBiI0UBMfd10+GTgYbzx4smVbb3eQp/+hpvtlPO8OUGr8TFo8qvoui8mql1Vnxk=
X-Received: by 2002:a19:c403:: with SMTP id u3-v6mr5654883lff.87.1532296953675; Sun, 22 Jul 2018 15:02:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 15:01:52 -0700 (PDT)
In-Reply-To: <CA+k3eCTn_5KHF6CT=9OeEiUmU-HENqee3jQ89OscTO9vgMuJfw@mail.gmail.com>
References: <CABcZeBNQaqg3wFuo=w3h4k+bB44pEPnoR-zZYM+AR7YDA=O8Gg@mail.gmail.com> <CA+k3eCRDyn7-1KEVYai8b-G_bLQZGTgiS2VFG9W3NWy2Ttu-nw@mail.gmail.com> <ef06d115-b178-16c3-76ca-4693d273ae41@free.fr> <CA+k3eCTeBqPHTs_vUrFOcEOT3CHJptJN8m3_M3LDYyL=WrL5BA@mail.gmail.com> <CABRXCmxSY75_tSA6uE4jtMMeX4aXOGEzWBLhkKXOOgg9ZUNNuA@mail.gmail.com> <SN6PR00MB03015D1AAF670587060EE199F5910@SN6PR00MB0301.namprd00.prod.outlook.com> <CABRXCmy8WnhSYGSz+wu2NQvz1E2Jr_Jx-=cH=tM_xVT0UaQp6g@mail.gmail.com> <CA+k3eCQdyuFA6FKUg4onMPhQ6VxfcOQ6vLSW_GijLsF+NOBaSg@mail.gmail.com> <CABcZeBNReOvd-FFiEwf-M_zXoiKYTT2pcSGfyjVEYe4E6adMCw@mail.gmail.com> <CA+k3eCRBahGR2N6rUNtZrYASQhjNUU4-_HVCZp_XAKv70zkpTA@mail.gmail.com> <CABcZeBOk4haUG_omN-ED_WwpAmY2G5jW2O6MPfhGLojw9bQ2kQ@mail.gmail.com> <CA+k3eCSzRHuNsb=kDTLk1Y_o0NYRMgu5XxN+Ow1xjS9mMBm+NQ@mail.gmail.com> <CABcZeBMLAoMNLhSEoXRAvJVLcYajueL+zfLtNz+cAzk+EtoHCQ@mail.gmail.com> <CA+k3eCTn_5KHF6CT=9OeEiUmU-HENqee3jQ89OscTO9vgMuJfw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 22 Jul 2018 15:01:52 -0700
Message-ID: <CABcZeBPaK0zXBxfXF9zWdp3TMY-r9nuWQbOpE3KzS=n8=kY=Yg@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d52f305719dafbe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zMyXo_cFuI4XMi2RxhhKRnXgDCw>
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Jul 2018 22:02:42 -0000

This text is fine. I have issued IETF-LC.

On Mon, Jun 4, 2018 at 1:45 PM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

> Thanks Eric, I've added text in the just submitted -14 saying that only
> the two ends of the chain are to be considered in access control policy
> decisions.
>
> diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-14
>
> htmlized:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14
>
>
> On Fri, Jun 1, 2018 at 10:02 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> OK, well, it seems like it ought to say that that generator of the token
>> can expect that the RP will apply an access control policy that s the union
>> of the capabilities of the two ends of the chain -- and that while it might
>> be less it won't be more.
>>
>> -Ekr
>>
>>
>> On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell <
>> bcampbell@pingidentity.com> wrote:
>>
>>> I suspect that the vast majority of time C's permissions won't matter at
>>> all. But I do think there are legitimate cases where they might be
>>> considered in the policy decision. One general example I can think of is a
>>> customer service rep or administrator taking override type corrective
>>> action on an end-user's account or transaction information (A is the
>>> end-user and C is the customer service rep) that the user on their own
>>> wouldn't have permission to change.
>>>
>>> On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>> That would go a long way, I think. Do you think that C's permissions
>>>> matter at all? So, say that the resource is accessible to C but not A?
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <
>>>> bcampbell@pingidentity.com> wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Apologies for my somewhat slow response. I've honestly been unsure of
>>>>> how else to try and address the comment/question. But will continue
>>>>> trying...
>>>>>
>>>>> My expectation would be that access control decisions would be made
>>>>> based on the subject of the token itself or on the current actor. And maybe
>>>>> a combination of both in some situations (like, for example, the actor is
>>>>> an administrator and the token allows admin level access to the stuff the
>>>>> token subject would normally have access to).  However, I don't believe
>>>>> that nested prior actors would or should be considered in access control
>>>>> decisions. The nesting is more just to express what has happened for
>>>>> auditing or tracking or the like. To be honest, the nesting was added in
>>>>> the draft largely because the structure naturally and easily allowed for it
>>>>> and it seemed like it might be useful information to convey in some cases.
>>>>>
>>>>> So in that A->B->C case (the claims of such a token would, I think,
>>>>> look like the JSON below), B *is not* giving C his authority. B is
>>>>> just noted in the token as having been involved previously.  While A is
>>>>> identified as the subject of the token and C is the current actor.
>>>>>
>>>>>     {
>>>>>       "aud":"... ,"iss":... , "exp":..., etc. etc. ...
>>>>>       "sub":"A",
>>>>>       "act":
>>>>>       {
>>>>>         "sub":"C",
>>>>>         "act":
>>>>>         {
>>>>>           "sub":"B"
>>>>>         }
>>>>>       }
>>>>>     }
>>>>>
>>>>>
>>>>> Would some text explicitly saying that only the token subject (top
>>>>> level sub and claims) and the party identified by the outermost "act" claim
>>>>> (the current actor) are to be considered in access control decisions
>>>>> address your concern?
>>>>>
>>>>>
>>>>> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> To be clear, I'm not opposing Delegation. My concern here is that we
>>>>>> have a chain of signed assertions and I'm trying to understand how I as a
>>>>>> consumer of those assertions am supposed to evaluate it.
>>>>>>
>>>>>> I don't think it's sufficient to just say that that the access
>>>>>> control rules are local policy, because then the entity generating the
>>>>>> signature has no way of knowing how its signature will be used.
>>>>>>
>>>>>> To go back to the case I gave in my initial e-mail, say we have a
>>>>>> chain A->B->C and a resource that A and C could ordinarily not access, but
>>>>>> B can. If C has this delegation, can C access the resource? I.e., is B
>>>>>> giving C his authority or just passing on A's authority? It seems pretty
>>>>>> important for B to know that before he gives the token to C.
>>>>>>
>>>>>> -Ekr
>>>>>>
>>>>>>
>>>>>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <
>>>>>> bcampbell@pingidentity.com> wrote:
>>>>>>
>>>>>>> Delegation has been in the document since its inception and
>>>>>>> throughout the three and a half years as a working group document.
>>>>>>>
>>>>>>> From a process point of view, the document is now in AD Evaluation.
>>>>>>> I worked through a number of questions and clarifications with Eric (said
>>>>>>> AD), however he raised the particular questions that started this thread on
>>>>>>> the WG list. And I responded with an attempt at addressing those questions.
>>>>>>> That was about a month ago.
>>>>>>>
>>>>>>> Eric, was my explanation helpful in clarify anything for you? Is
>>>>>>> there some text that you'd like to see added? Something else? I'm unsure
>>>>>>> how to proceed but would like to move things forward.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke <bburke@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This is an honest question: How important is the actor stuff to the
>>>>>>>> players involved?  Are people going to use it?  IMO, its an edge
>>>>>>>> case
>>>>>>>> and I think more important areas, like external token exchange
>>>>>>>> (realm
>>>>>>>> to realm, domain to domain) are being neglected.  I'm quite
>>>>>>>> unfamiliar
>>>>>>>> how consensus is reached in this WG or the IETF, so I hope I'm not
>>>>>>>> sounding rude.  Just trying to provide some constructive feedback.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones <
>>>>>>>> Michael.Jones@microsoft.com> wrote:
>>>>>>>> > Moving the actor claim to a separate specification would only
>>>>>>>> make things more complicated for developers.  There already plenty of OAuth
>>>>>>>> specs.  Needlessly adding another one will only make related things harder
>>>>>>>> to find.
>>>>>>>> >
>>>>>>>> > Just like in the JWT [RFC 7519] spec itself in which use of all
>>>>>>>> the claims is optional, use of the actor claim in this spec.  If you don't
>>>>>>>> need it, don't use it.  Just because some won't use it is no better an
>>>>>>>> argument for moving it to a different spec than the argument that JWT
>>>>>>>> should have defined each of its claims in different specs.  That would have
>>>>>>>> made things harder, not easier.
>>>>>>>> >
>>>>>>>> >                                 -- Mike
>>>>>>>> >
>>>>>>>> > -----Original Message-----
>>>>>>>> > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
>>>>>>>> > Sent: Thursday, May 17, 2018 2:11 PM
>>>>>>>> > To: Brian Campbell <bcampbell@pingidentity.com>
>>>>>>>> > Cc: oauth <oauth@ietf.org>
>>>>>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang
>>>>>>>> e-12.txt
>>>>>>>> >
>>>>>>>> > My personal opinion is that I'm glad this actor stuff is optional.
>>>>>>>> > For one, none of our users have asked for it and really only do
>>>>>>>> simple exchanges.  Secondly, the rules for who can exchange what for what
>>>>>>>> is controlled and defined within our AS.  Makes things a lot simpler on the
>>>>>>>> client.  I kind of wish the actor stuff would be defined in a separate
>>>>>>>> specification.  I don't see us implementing it unless users start asking us
>>>>>>>> to.
>>>>>>>> >
>>>>>>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <
>>>>>>>> bcampbell@pingidentity.com> wrote:
>>>>>>>> >> Well, it's already called the "actor claim" so the claimed part
>>>>>>>> is
>>>>>>>> >> kind of implied. And "claimed actor claim" is a rather awkward.
>>>>>>>> >> Really, all JWT claims are "claimed something" but they don't
>>>>>>>> include
>>>>>>>> >> the "claimed" bit in the name. RFC 7519, for example, defines the
>>>>>>>> >> subject claim but not the claimed subject claim.
>>>>>>>> >>
>>>>>>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr>
>>>>>>>> wrote:
>>>>>>>> >>>
>>>>>>>> >>> Brian,
>>>>>>>> >>>
>>>>>>>> >>> Eric said: "what is the RP supposed to do when they encounter
>>>>>>>> it?
>>>>>>>> >>> This seems kind of under specified".
>>>>>>>> >>>
>>>>>>>> >>> After reading your explanations below, it looks like the RP can
>>>>>>>> do
>>>>>>>> >>> anything he wants with the "actor".
>>>>>>>> >>> It is a "claimed actor" and, if we keep the concept, it should
>>>>>>>> be
>>>>>>>> >>> called as such. Such a claim cannot be verified.
>>>>>>>> >>> A RP could copy and paste that claim in an audit log. No
>>>>>>>> standard
>>>>>>>> >>> action related to the content of such a claim can be specified
>>>>>>>> in the
>>>>>>>> >>> spec. If the content of a "claimed actor" is used by the RP, it
>>>>>>>> >>> should be only used as an hint and thus be subject to other
>>>>>>>> >>> verifications which are not specified in this specification.
>>>>>>>> >>>
>>>>>>>> >>> Denis
>>>>>>>> >>>
>>>>>>>> >>> Eric, I realize you weren't particularly impressed by my prior
>>>>>>>> >>> statements about the actor claim but, for lack of knowing what
>>>>>>>> else
>>>>>>>> >>> to say, I'm going to kind of repeat what I said about it over
>>>>>>>> in the
>>>>>>>> >>> Phabricator tool and add a little color.
>>>>>>>> >>>
>>>>>>>> >>> The actor claim is intended as a way to express that delegation
>>>>>>>> has
>>>>>>>> >>> happened and identify the entities involved. Access control or
>>>>>>>> other
>>>>>>>> >>> decisions based on it are at the discretion of the consumer of
>>>>>>>> the
>>>>>>>> >>> token based on whatever policy might be in place.
>>>>>>>> >>>
>>>>>>>> >>> There are JWT claims that have concise processing rules with
>>>>>>>> respect
>>>>>>>> >>> to whether or not the JWT can be accepted as valid. Some
>>>>>>>> examples are "aud"
>>>>>>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before)
>>>>>>>> from RFC 7519.
>>>>>>>> >>> E.g. if the token is expired or was intended for someone or
>>>>>>>> something
>>>>>>>> >>> else, reject it.
>>>>>>>> >>>
>>>>>>>> >>> And there are JWT claims that appropriately don't specify such
>>>>>>>> >>> processing rules and are solely statements of fact or
>>>>>>>> circumstance.
>>>>>>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At)
>>>>>>>> claims are good examples of such.
>>>>>>>> >>> There might be application or policy specific rules applied to
>>>>>>>> the
>>>>>>>> >>> content of those kinds of claims (e.g. only subjects from a
>>>>>>>> >>> particular organization are able to access tenant specific data
>>>>>>>> or,
>>>>>>>> >>> less realistic but still possible, disallow access for tokens
>>>>>>>> issued
>>>>>>>> >>> outside of regular business
>>>>>>>> >>> hours) but that's all outside the scope of a specification's
>>>>>>>> >>> definition of the claim.
>>>>>>>> >>>
>>>>>>>> >>> The actor claim falls into the latter category. It's a way for
>>>>>>>> the
>>>>>>>> >>> issuer of the token to tell the consumer of the token what is
>>>>>>>> going
>>>>>>>> >>> on. But any action to take (or not) based on that information
>>>>>>>> is at
>>>>>>>> >>> the discretion of the token consumer. I honestly don't know it
>>>>>>>> could
>>>>>>>> >>> be anything more. And don't think it should be.
>>>>>>>> >>>
>>>>>>>> >>> There are two main expected uses of the actor claim (that I'm
>>>>>>>> aware
>>>>>>>> >>> of
>>>>>>>> >>> anyway) that describing here might help. Maybe. One is a human
>>>>>>>> to
>>>>>>>> >>> human delegation case like a customer service rep doing
>>>>>>>> something on
>>>>>>>> >>> behalf of an end user. The subject would be that user and the
>>>>>>>> actor
>>>>>>>> >>> would be the customer service rep. And there wouldn't be any
>>>>>>>> chaining
>>>>>>>> >>> or nesting of the actor. The other case is so called service
>>>>>>>> chaining
>>>>>>>> >>> where a system might exchange a token it receives for a new
>>>>>>>> token
>>>>>>>> >>> that it can use to call a downstream service. And that service
>>>>>>>> in
>>>>>>>> >>> turn might do another exchange to get a new token suitable to
>>>>>>>> call
>>>>>>>> >>> yet another downstream service. And again and so on and turtles
>>>>>>>> all
>>>>>>>> >>> the way. I'm not necessarily endorsing that level of
>>>>>>>> granularity in
>>>>>>>> >>> chaining but it's bound to happen somewhere/sometime. The nested
>>>>>>>> >>> actor claim is able to express that all that has happened with
>>>>>>>> the
>>>>>>>> >>> top level or outermost one being the system currently using the
>>>>>>>> token
>>>>>>>> >>> and prior systems being nested.. What actually gets done with
>>>>>>>> that
>>>>>>>> >>> information is up to the respective systems involved. There
>>>>>>>> might be
>>>>>>>> >>> policy about what system is allowed to call what other system
>>>>>>>> that is
>>>>>>>> >>> enforced. Or maybe the info is just written to an audit log
>>>>>>>> >>> somewhere. Or something else. I don't know. But whatever it is
>>>>>>>> application/deployment/policy dependent and not specifiable by a spec.
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com>
>>>>>>>> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> Hi folks,
>>>>>>>> >>>>
>>>>>>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things
>>>>>>>> seem
>>>>>>>> >>>> generally OK. I do still have one remaining concern, which is
>>>>>>>> about
>>>>>>>> >>>> the actor claim. Specifically, what is the RP supposed to do
>>>>>>>> when
>>>>>>>> >>>> they encounter it? This seems kind of underspecified.
>>>>>>>> >>>>
>>>>>>>> >>>> In particular:
>>>>>>>> >>>>
>>>>>>>> >>>> 1. What facts am I supposed to know here? Merely that everyone
>>>>>>>> in
>>>>>>>> >>>>    the chain signed off on the next person in the chain acting
>>>>>>>> as them?
>>>>>>>> >>>>
>>>>>>>> >>>> 2. Am I just supposed to pretend that the person presenting
>>>>>>>> the token
>>>>>>>> >>>>    is the identity at the top of the chain? Say I have the
>>>>>>>> >>>>    delegation A -> B -> C, and there is some resource which
>>>>>>>> >>>>    B can access but A and C cannot, should I give access?
>>>>>>>> >>>>
>>>>>>>> >>>> I think the first question definitely needs an answer. The
>>>>>>>> second
>>>>>>>> >>>> question I guess we could make not answer, but it's pretty
>>>>>>>> hard to
>>>>>>>> >>>> know how to make a system with this left open..
>>>>>>>> >>>>
>>>>>>>> >>>> -Ekr
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> _______________________________________________
>>>>>>>> >>>> OAuth mailing list
>>>>>>>> >>>> OAuth@ietf.org
>>>>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> >>>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>>>>> >>> privileged material for the sole use of the intended
>>>>>>>> recipient(s).
>>>>>>>> >>> Any review, use, distribution or disclosure by others is
>>>>>>>> strictly
>>>>>>>> >>> prohibited..  If you have received this communication in error,
>>>>>>>> >>> please notify the sender immediately by e-mail and delete the
>>>>>>>> message
>>>>>>>> >>> and any file attachments from your computer. Thank you.
>>>>>>>> >>>
>>>>>>>> >>> _______________________________________________
>>>>>>>> >>> 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
>>>>>>>> >>>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>>>>> >> privileged material for the sole use of the intended
>>>>>>>> recipient(s). Any
>>>>>>>> >> review, use, distribution or disclosure by others is strictly
>>>>>>>> >> prohibited..  If you have received this communication in error,
>>>>>>>> please
>>>>>>>> >> notify the sender immediately by e-mail and delete the message
>>>>>>>> and any
>>>>>>>> >> file attachments from your computer. Thank you.
>>>>>>>> >> _______________________________________________
>>>>>>>> >> OAuth mailing list
>>>>>>>> >> OAuth@ietf.org
>>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > Bill Burke
>>>>>>>> > Red Hat
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > OAuth mailing list
>>>>>>>> > OAuth@ietf.org
>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> Red Hat
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>>>> privileged material for the sole use of the intended recipient(s). Any
>>>>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>>>>> If you have received this communication in error, please notify the sender
>>>>>>> immediately by e-mail and delete the message and any file attachments from
>>>>>>> your computer. Thank you.*
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged material for the sole use of the intended recipient(s). Any
>>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>>> If you have received this communication in error, please notify the sender
>>>>> immediately by e-mail and delete the message and any file attachments from
>>>>> your computer. Thank you.*
>>>>>
>>>>
>>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>>
>>
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>