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

Brian Campbell <bcampbell@pingidentity.com> Wed, 16 May 2018 22:11 UTC

Return-Path: <bcampbell@pingidentity.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 5280212DA40 for <oauth@ietfa.amsl.com>; Wed, 16 May 2018 15:11:48 -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, HTML_MESSAGE=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 (1024-bit key) header.d=pingidentity.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 mTqN3YWaJjJ2 for <oauth@ietfa.amsl.com>; Wed, 16 May 2018 15:11:45 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 935BD126D05 for <oauth@ietf.org>; Wed, 16 May 2018 15:11:44 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id z6-v6so5982921iti.4 for <oauth@ietf.org>; Wed, 16 May 2018 15:11:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yxJLkbey7H4LM8Jdgmj6Wj6G9ZFCuwmg2WU8TFM8/D0=; b=HdonXuxYUO7+8BQ1ZciGIGgT2n1+N4GinkjO7d1EyVOFRXiKvJHSz2X7AgXMDZex6m suDPp803bE586PaKbTN2wPyCWeL2vA82LUXEcduKCJdm5oi/Dbus3PwgUpDqIdv4QkCF Jb0fnuuKNL1mYeRYGQKnXGwapX//CsHI7Zyx4=
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=yxJLkbey7H4LM8Jdgmj6Wj6G9ZFCuwmg2WU8TFM8/D0=; b=ssOfrtpOxfdDvCheXEszaVFDUzC7K3V2nRUCdjjqTjPTPFZwld4c9dRx7mXyALEcCm EEwVnmjSm1beIQ0cy9hQqio7elwoQIZf8u2S5aIum0/I9+CHeZkr8JsOL4xykwDefNd3 jLzbTFQZVlNcP2QMEwONBHHbIsNqhfQqQtL40MwODg77DwzWOJnWkz7Tul+mDGUu9yL1 6noB7WdL2r3Sgy+aFXjQG1vreZZurIe3ZErWtv6xAAn5ufxGGz/I+NeuOKie4fBNa/VT 0HSAlQns7vkQDPV3ilPof6ouy3EKTT7LC/mntuWyyge0P0f8fHztLz3Wlw3jFFRWyeX3 APMg==
X-Gm-Message-State: ALKqPwcR7PsUYYN1uiPT7ao1IKdGbo5qbuf0QpEXMBzA7aNM7+7akt72 Z55kwpZ08IiCCFD7Kno6kV/r7G1Iichvq9Ebri4AcI9u5BW2IcusGM4u0s/0nBYdrHjGa6Napzv os5yCzJxuvG+TEA==
X-Google-Smtp-Source: AB8JxZrZI1rJ9GUQOzthpKXCtIDzRgTYDUMUY2zGVhnuKlxJAZyD4dk0L+9ip9Sl9l9rK2InBOOmkxmvKcaIbctNhgA=
X-Received: by 2002:a24:1f4a:: with SMTP id d71-v6mr153034itd.53.1526508703678; Wed, 16 May 2018 15:11:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Wed, 16 May 2018 15:11:13 -0700 (PDT)
In-Reply-To: <ef06d115-b178-16c3-76ca-4693d273ae41@free.fr>
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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 16 May 2018 16:11:13 -0600
Message-ID: <CA+k3eCTeBqPHTs_vUrFOcEOT3CHJptJN8m3_M3LDYyL=WrL5BA@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000079a12056c5a0170"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7Wyu4cZ9Rag8Z7CzMoAnfKEYYwc>
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: Wed, 16 May 2018 22:11:48 -0000

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
> <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1600> 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 listOAuth@ietf.orghttps://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._