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

George Fletcher <gffletch@aol.com> Fri, 01 June 2018 15:04 UTC

Return-Path: <gffletch@aol.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 57A8D12D88A for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 08:04:24 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HcGCjze8ns2h for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 08:04:21 -0700 (PDT)
Received: from sonic316-13.consmr.mail.bf2.yahoo.com (sonic316-13.consmr.mail.bf2.yahoo.com [74.6.130.123]) (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 2AB0212D892 for <oauth@ietf.org>; Fri, 1 Jun 2018 08:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527865460; bh=4UR6GSkvxds0PLxk60or+dikclX1Gf/d7O8ZXdETWDQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=LTWKjb5L/LZD2nEzH43lve0xFWZVCr8FE1Q+ige4zGdfXU0d96z034Nq3SS2AYKu95eEVFsKT2BJD2/5mmqp/v2d+JiGQVSlaRGAr3AUA8p7X5QIkSuwc6s7qqOAe8nnhq67xg/+WBadhPgiVmsACn1DbJnRIqid23EWVPqX82pta6Kg7Q0rjIQ2J4/zvCpoAhe/VO4UFkJf527JPg/pI+CpWUIhGkdvE/sigcslzL6QfDGRUkSvim2Rl3CZhwBLJp0wJ3LG3DmaGkGJVA8HuZOeR2tv9Oc8Yr6zjRxDKHbYCG6RuGASHAQHLSd7SOW5M9DbaKCoBtGiPur7x4F3ig==
X-YMail-OSG: C1JzXLIVM1mN34Sjkle8B9nxEg0DzJEIttMpASr7X5cDFiSDO2KIXyVk7VKSX2U Ss3hkryFz90v18Aje8kuMPt_mIyaK8_ksYEuJUhq_OELcn9ZiGdc3YVCAevZ8g7mZ0aBH4Lw_vwK 8BXIhotpkn2BoEm5_ewv8BJftMsbwDWwaaxae8plbJuwHEgGey7r2mWExAief1BPlwmDqUydt4r8 B7Vz3c0YAJOdDmbMksN7N2LWhUxHCCUvXvBJAIB3pyn194oa676HX9wziIAtpn2gbl6rZib3el0r x8Www6kiLtj0grtDXGYAxuamVdlhamoXNdoo0dpbT_i.PIyszuXGSJsAhPMOBC03Zjp7IkaDVUR1 kc8RwhJQ7Y1G12dqO9AwCF0I7L0x58U5GQccceBQNleiQC8tRbGU_RVsPYmElzfokTWWpwtChRhY aCAqykeGO4oRUEhSQumLlCKqthMD2ht34NmZPLXfXwiwuY4grZgVlYREfWQCCiD5FvDnFixca.TN quxDa4dIAYyrJ8LfITXZ5AK4flDdvCSM6qVW955CIWIK_pDaQXB.fn5Ge_0aOMHdzkL3Mevp4UmH NSWFDDW.TUTG6hul7JV2pL0ffszEVp4WpSzdCY9jUCpb_8ACPn67ieF29qngkpgHL5ZFrLlFL.F4 CH6JYONcr5t0Jw3ZGJTqX6kqulcBmd31A.kFX
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Jun 2018 15:04:20 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a7599839fa5bc309bf66b2680291a5ca; Fri, 01 Jun 2018 15:04:16 +0000 (UTC)
To: Bill Burke <bburke@redhat.com>, Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <0e12c6a8-4733-e4a2-e8c8-863d4a3b2a0e@aol.com>
Date: Fri, 1 Jun 2018 11:04:15 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CABRXCmxSY75_tSA6uE4jtMMeX4aXOGEzWBLhkKXOOgg9ZUNNuA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/H3zTPuxUbE_X-LSsdFIQG2lZ9Dg>
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 01 Jun 2018 15:04:25 -0000

I'm fine with it being optional but I don't think it should be removed. 
I have a use case where the actor_token is being used. In my use case 
the "actor" represents a device making a token exchange between two 
applications running on the device. It allows the AS to enforce a 
binding such that only apps on the same device can exchange tokens.

Full details can be found on the OpenID Connect working group mailing list:
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180430/006733.html

Thanks,
George

On 5/17/18 8:10 AM, Bill Burke wrote:
> 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
>>
>
>