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, 01 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 >> > >
- [OAUTH-WG] Followup on draft-ietf-oauth-token-exc… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Denis
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Bill Burke
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Rob Otto
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Mike Jones
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Bill Burke
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Bill Burke
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… George Fletcher
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla