Re: [GNAP] Should access tokens be opaque or not for the clients ?

Adrian Gropper <agropper@healthurl.com> Fri, 19 March 2021 17:26 UTC

Return-Path: <agropper@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652583A1AD9 for <txauth@ietfa.amsl.com>; Fri, 19 Mar 2021 10:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 LllbeiExI0ni for <txauth@ietfa.amsl.com>; Fri, 19 Mar 2021 10:26:51 -0700 (PDT)
Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 404643A1B2B for <txauth@ietf.org>; Fri, 19 Mar 2021 10:26:47 -0700 (PDT)
Received: by mail-ua1-f45.google.com with SMTP id 97so3279239uav.7 for <txauth@ietf.org>; Fri, 19 Mar 2021 10:26:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HrvMJAPyZJ+W0Vrn/wUpHL4RqY4XSFTSXGhWFBR6zxA=; b=gs1wv00hsQuHU3BWNnQu81NmrVDHThplmcX75q9cL6uD4ktCvK5vTHA8vioUgXjxW6 utKSA57nlPkHg03rkrtnyMwwR9/RMt4Msf+WQLOjeZKAefSeb88/sZGrrm6ZPDD9tlTP rHhJqxMS1YXsJ9JjM5pBRTumLL/1GO4lzpPEW1xR8pF3N30AYxRYIMJuBfMJPcYXfxB7 akg/QLy8aE1hTp49o4lQ9fqKMsz/XvzVWsDalzDX3mBi4uxXzTLnemWiHysQp3eV2v0N jmbpjtnr6CQ8D3lazo8m3ThjaQV9ytKXF0xZATgvDSGOA9T1LVfF2+Ke4Kjv2Pnu5BuP c/Ew==
X-Gm-Message-State: AOAM532SzFFv3ft5KkXExooesS8i4/e6zsdGVyOx8WTkfG9M6RO9APix AMmGnb2JmXzhuu0ouwAbSFxb7BR2NgDITDQv3LQ=
X-Google-Smtp-Source: ABdhPJzGfZxl1M7k6xoR8cjxLgRutHO+DBLFgNBOevG5FTZCtcuS3EWSNbiMn8o/ApOxOT9MNtVxYQXgI2YAzhJbG1c=
X-Received: by 2002:a9f:3766:: with SMTP id a35mr2948203uae.128.1616174806014; Fri, 19 Mar 2021 10:26:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAM8feuQ5Q1LrGtniCH3WN5gyf6QhBa-9e+2kzaV0fxzA5D5m7w@mail.gmail.com> <CAM8feuQEQyCEOErds8rpcipaqyPm3L3XMdrbQ6X2t3y9xcO4dQ@mail.gmail.com> <CAJmmfSQKZWm=YsjBVV8O+vU9zzC+eka0CCaQO-xFP-GcWzEigw@mail.gmail.com> <CANYRo8jw9gHQESDk__aKM3jK-C9FvYTFYOzb-8iYzbc_hVjMPA@mail.gmail.com> <EDB79C39-D706-43B2-B7D6-234CB32F7411@mit.edu> <CANYRo8inRJa0bAe6gqOkLKqHnt-qxPrzhDufBLwXd-S4wfjdxg@mail.gmail.com> <CAM8feuS98hqZ36hjCHg_=wpueDyXHb7t156OXnL_8MXtzpiyjA@mail.gmail.com> <CANYRo8i4gVpV5Fv7Yr9AFLNSq658EayHK5yJ+vp2ecUaRJ6fYw@mail.gmail.com> <CAM8feuSC2EDHbVHXjHAkgV8jfYP9+gQ_ZV-+y=aoEjf97Rbyqg@mail.gmail.com> <CANYRo8hdA0vLRXwOMDDg99qQHWC=DAzk+ht=ykjZ42bPmUxdPA@mail.gmail.com> <CANpA1Z2jv1ye234SKXa3n=z1yoVY5nW72Xqzj2bk_+_KjnK-+g@mail.gmail.com> <C4DC413B-32C7-432C-AE14-FC743D45319A@mit.edu> <CANpA1Z1b8FVXNgJKbv9wDyWsuva5PRrWvrgsoymCK9bj_Zt1wg@mail.gmail.com> <43447446-4061-49F2-8486-5A196C3C75E2@mit.edu> <CAM8feuSncUCkqWAA975kCTUdv69VG41a9s7HYD2LP5xCVmkkiQ@mail.gmail.com> <37a04505-84ef-aecf-6913-5aad8330c97c@free.fr> <CAK5Vu_DOFm8LM82AiYi52p9MQikevJZuv5NrBj9K2KRZixhr0g@mail.gmail.com> <B7746C38-DCF4-4795-ACD4-3FABC536A952@mit.edu> <CAK5Vu_BUmKeWK4yQ-tmKsnJG=8KkM1C93LXfYfLyfpfOCF8Ghw@mail.gmail.com> <B2292C04-9580-403A-BFC1-5212335F8BFC@mit.edu> <CANYRo8jDqEdk9VsUnSsCufHn0MhRmqP+ArgxQ5q0WEJgje+6GQ@mail.gmail.com> <CAM8feuTC0nY6kUq_NtRAn_n6PVs1BK+4KNBsQ=ELqavTJC_wBA@mail.gmail.com> <CAM1Hn1XxtdXV0cWOo7TYQUPRZ4t0eo8eU+mJCxgw9_W0jPnijA@mail.gmail.com> <3FE214B6-CF96-472D-853B-C7C5AC7A73AE@mit.edu> <CAM1Hn1UDLXPfuVSuzyfUf1z-ocy-SSKZUjn2UVEqZ-64kzEJcQ@mail.gmail.com> <A337051B-701F-4CFD-989D-7412469619D4@mit.edu> <CANYRo8hiu74EkpENjsPO-bRJqaVFtH9Ev9o4Ex2GSTKqw1S=OQ@mail.gmail.com> <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu>
In-Reply-To: <8DF709AE-B17D-4B53-92FC-723F2C8C2503@mit.edu>
From: Adrian Gropper <agropper@healthurl.com>
Date: Fri, 19 Mar 2021 13:26:34 -0400
Message-ID: <CANYRo8gzaCdHaqYXe7hAawe0_tOz=3tnULpgRjspbhA-9xAV-A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Alejandro Iacobelli <aiacobelli.sec@gmail.com>, Fabien Imbault <fabien.imbault@gmail.com>, Steve Moore <srmoore@gmail.com>, txauth gnap <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000351fc205bde70583"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/zfasZbQiVCUk7n5LaLoGXwvVk7g>
Subject: Re: [GNAP] Should access tokens be opaque or not for the clients ?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2021 17:26:56 -0000

I agree. The problem is that powerful RS operators introduce things like
Capchas that hassle the RO. Sometimes this is justified but often it
reflects an inadequate protocol.

Adrian

On Fri, Mar 19, 2021 at 1:22 PM Justin Richer <jricher@mit.edu> wrote:

> There’s an important difference here:
>
> The AS is software. Always. It plays a specific role within the protocol.
>
> The RO could be a person. It could be an agency. It could be a policy.
> They don’t take part in the protocol directly but are involved in decisions
> made in the course of the protocol.
>
> These are two very, very different things, and they can’t be conflated.
>
> I like the idea of talking in terms of relationships, such as AS-RS (a
> protocol relationship) and AS-RO (a trust relationship).
>
>  — Justin
>
> On Mar 19, 2021, at 12:37 PM, Adrian Gropper <agropper@healthurl.com>
> wrote:
>
> It might be a good idea to keep the RS to AS relationship out of the GNAP
> spec but I’m having a hard time analyzing it in the abstract.
>
> My starting perspective is that the RS should not know or care whether it
> is dealing with the AS or the RO. This is super important because it gives
> the RO unlimited delegation power.
>
> Cases where the RO wants to give the RS a separate endpoint or other
> identity should be allowed by GNAP but might be out of band. This is the
> HIPAA API Task Force use case that I have referenced in another thread. The
> issue here is that the RS has the option of reaching out to the RO and
> requesting confirmation.
>
> Adrian
>
> On Fri, Mar 19, 2021 at 11:37 AM Justin Richer <jricher@mit.edu> wrote:
>
>> My proposal is that the client instance shouldn’t care what’s in the
>> token, what format it is, etc.
>>
>> The RS can care and there should be choices that include random, sealed,
>> and even plainly signed tokens. That choice is part of the relationship
>> between the RS and AS, which the core GNAP protocol doesn’t specify.
>>
>> This is why I propose that we extract what’s now section 10 in the draft
>> and put it into a new document that can more directly discuss that
>> relationship. These different relationships should be modular.
>>
>>  — Justin
>>
>> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli <
>> aiacobelli.sec@gmail.com> wrote:
>>
>> Agree! So what are you saying the proposal should be? Random or sealed
>> tokens?
>>
>> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer <jricher@mit.edu>
>> escribió:
>>
>>> One of the best ways to protect information in the token is to not put
>>> it in the token in the first place. This is why a some highly-sensitive
>>> application profiles and deployments us randomized values as tokens. The RS
>>> has a way to dereference it, which is important.
>>>
>>> For downstream delegation, like one micro service calling another, we’re
>>> no longer talking about the client knowing the access token, we’re talking
>>> about an RS at the first step. This is where non-opaque, or encrypted, or
>>> other kinds of recoverable data structures come into play more directly.
>>>
>>> To Adrian’s point, sharing the QR code should be up to the AS’s policy.
>>> If Steve gives me a bearer artifact that isn’t attached to anything that
>>> identifies me, then it’s easy for me to share because the artifact is the
>>> identity and proof all in one. The strawman description below sounds like
>>> that. But it’s important in this design that the AS can also require me to
>>> log in with a specific account, plus present a token, plus type in a secret
>>> code, plus present a hardware key that completes a circuit in the right way
>>> (seems like something Steve would build, tbh), etc. But all of these aren’t
>>> a client talking to a resource, they’re the end-user  presenting things to
>>> the AS so that the AS can make a policy decision to issue a token and allow
>>> access.
>>>
>>>  — Justin
>>>
>>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli <
>>> aiacobelli.sec@gmail.com> wrote:
>>>
>>> The decision about "opaque" vs "sealed but recoverable" or "signed"
>>> access_token goes way back on the stateless protocols session management.
>>>
>>> In my opinion, the software design principle that we must apply here is
>>> the "need to know" principle. This means, the less information an attacker
>>> could get, the better. One thing that JWS explse is all the context
>>> information about a token, so an attacker can get lots of information just
>>> with a look.
>>>
>>> The next discussion will be what ways of generating opaque tokens are
>>> there and which must we choose (Encrypted vs CSPRNG based).
>>>
>>> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault <fabien.imbault@gmail.com>
>>> wrote:
>>>
>>>> Hi Adrian,
>>>>
>>>> I'm really not sure I understand here.
>>>>
>>>> I get the idea of putting a policy engine in front of your services to
>>>> implement ZTA. But I'm not sure I get this way of framing things. It blurs
>>>> functional roles and actual services, and most importantly if everything
>>>> gets its own AS, it also gets by transitivity its RO'/RQ' (and then its
>>>> AS-RO' etc) and so the complexity becomes staggering.
>>>> Why do we need that?
>>>>
>>>> Fabien
>>>>
>>>> Le ven. 19 mars 2021 à 00:55, Adrian Gropper <agropper@healthurl.com>
>>>> a écrit :
>>>>
>>>>> +1 This aligns with my healthcare use-case to the extent that Justin
>>>>> can transfer the capability granted by that QR code to Adrian who happens
>>>>> to be nearby Steve's house.
>>>>>
>>>>> I've tried to capture some of this in my comment to #145
>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-802388458
>>>>>
>>>>> - Adrian
>>>>>
>>>>> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <jricher@mit.edu> wrote:
>>>>>
>>>>>> Right, and in the GNAP model this becomes something my client
>>>>>> instance presents to the AS when I show up. The AS can validate my
>>>>>> presentation of this item and give my client instance a token to call
>>>>>> Steve’s RS. Or if you wanted to get super fancy Steve’s AS could even
>>>>>> challenge my client instance and get a cryptographic response to prove I
>>>>>> have the thing Steve had me scan. But in both cases it’s part of things
>>>>>> that the AS collects in order to create the access token.
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>> On Mar 18, 2021, at 2:26 PM, Stephen Moore <srmoore@gmail.com> wrote:
>>>>>>
>>>>>> That in my mind works out great... Say I'm logged into my home
>>>>>> hub/AS. Justin is over and agrees to cat sit, I pull up my client app, and
>>>>>> generate a QR code that has maybe The AS URI, the HomeHub API URL, and the
>>>>>> 'special token to present to AS for a real token'. Justin scans that QR
>>>>>> code with his home controller app, and BAM, he's onboarded as a guest
>>>>>> without even logging into my AS or me dealing with his Auth provider.
>>>>>> -steve
>>>>>>
>>>>>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <jricher@mit.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> I think Steve’s use case gives an interesting example of something
>>>>>>> that I believe Adrian’s been talking about as well — delegating to another
>>>>>>> person.
>>>>>>>
>>>>>>> We traditionally think of delegation at the AS to mean “a different
>>>>>>> user account logs in to the AS”, and it’s important to know that this does
>>>>>>> in fact work. But this could just as easily be “Steve sends his friend an
>>>>>>> artifact to present to the AS to get access”. This isn’t Steve (or Steve’s
>>>>>>> client software) getting and sending an access token, this is sending some
>>>>>>> other set of rights credential to his friend, or his friend’s software. So
>>>>>>> then Steve’s AS can have policy that says “when I see this rights
>>>>>>> credential, give an access token for the following attenuated things,
>>>>>>> because Steve said so”. The AS doesn’t even ever need to know who Steve’s
>>>>>>> friend is!
>>>>>>>
>>>>>>> And importantly here, we don’t expect Steve’s friend to bring their
>>>>>>> own AS to the party. Steve’s RS has no reason to trust his friend’s AS, let
>>>>>>> alone his friend’s client. But Steve’s AS is in a position to know more
>>>>>>> about the rights policies that Steve wants to apply, and so it can use
>>>>>>> other technologies like VC’s, DIDs, OIDC, or any number of other things to
>>>>>>> let things go through. This pattern is exactly why I think we need to think
>>>>>>> of this in terms of what’s currently called “interaction” at the AS. It’s
>>>>>>> not really just about how the end-user interacts, it’s about how the AS
>>>>>>> gathers all the consent and authorization information. I plan to rewrite
>>>>>>> section 4 to that effect.
>>>>>>>
>>>>>>>  — Justin
>>>>>>>
>>>>>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore <srmoore@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm having some concerns with the way you're flipping the trust here
>>>>>>> Denis. You seem to indicate that the user has trust in the RS and the
>>>>>>> Client and has to gain the trust of the AS. I feel like the least
>>>>>>> trustworthy portion of the architecture is the client, because that seems
>>>>>>> like it is the most interchangeable component.
>>>>>>>  Let me explain by way of a use case I have in mind.
>>>>>>> Let's say I have a smart home. I have devices and data storage and
>>>>>>> rule engines that are parts of sensors and hubs I buy for the house. I have
>>>>>>> a trust in those devices, because it's hardware, if the company is leaking
>>>>>>> data at the hardware level there isn't much I can do other than buy
>>>>>>> different sensors.
>>>>>>> In this case, the primary home hub, which is under control of the
>>>>>>> homeowner, would also be the AS, as well as a policy agent.  Authentication
>>>>>>> in the example is outsourced to whatever auth providers you want. I set up
>>>>>>> my home using a google account, a friend is staying and wants access and
>>>>>>> uses FB for auth... whatever.
>>>>>>> The part that I have little control over is the client my friend
>>>>>>> uses on his phone. Or if I change the client on the tablet in the kitchen
>>>>>>> to try out something new. These pieces might be single page web apps, they
>>>>>>> might be downloaded apps, etc. I do not want them having any additional
>>>>>>> information than is necessary. If I give my friend permission to unlock the
>>>>>>> door, and control the lights because they are feeding my cats while I'm
>>>>>>> away, the client doesn't need to know anything beyond, I see this home
>>>>>>> controller, and I have access to these lights and that door lock.
>>>>>>>
>>>>>>> In your scenarios, the client is spy by design, and if it is a web
>>>>>>> app, I don't trust them to not grab my user email address from the AS and
>>>>>>> put it on a mailing list it sells to some sketchy company, when the only
>>>>>>> other component that needs that information is the RS.
>>>>>>>
>>>>>>> -steve
>>>>>>>
>>>>>>> On Thu, Mar 18, 2021 at 1:21 PM Denis <denis.ietf@free.fr> wrote:
>>>>>>>
>>>>>>>> I have changed the title of this thread, since the original topic
>>>>>>>> has been closed.
>>>>>>>>
>>>>>>>> Justin, you are raising the following question:
>>>>>>>>
>>>>>>>> The question I have is — why does the client need to know what’s in
>>>>>>>> the token?
>>>>>>>> Not if they could possibly know, but why would we expect a client
>>>>>>>> to know and manage the contents of the token?
>>>>>>>>
>>>>>>>> The answer is quite simple: so that the end-user may have
>>>>>>>> confidence into the architecture.
>>>>>>>> The seventh of the eleven privacy principles from ISO 29100 (page
>>>>>>>> 14) is:
>>>>>>>>
>>>>>>>> *7. Openness, transparency and notice *
>>>>>>>>
>>>>>>>> If the access token is considered as a black box for the end-user,
>>>>>>>> it cannot be confident about the content of the access token.
>>>>>>>> Such access token may disclose some private information without the
>>>>>>>> consent of the end-user. If the access token that it has obtained
>>>>>>>> does not match with what has been requested, the client will first
>>>>>>>> not forward the access token to the RS and then will complain about the AS.
>>>>>>>>
>>>>>>>> Denis
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Justin,
>>>>>>>>
>>>>>>>> "The access token is fundamentally a conversational artifact
>>>>>>>> between the AS and the RS which the client is the carrier of."
>>>>>>>> That's right, and a good opportunity to distinguish between the
>>>>>>>> need for token inspection (i.e. a runtime verification, wherever that may
>>>>>>>> be)
>>>>>>>> and the need to negotiate the token format (a discovery). That last
>>>>>>>> part could very well be an extension, as a way to open up the ecosystem
>>>>>>>>
>>>>>>>> beyond JWTs (which are fine, but come with their own limitations).
>>>>>>>>
>>>>>>>> Fabien
>>>>>>>>
>>>>>>>> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <jricher@mit.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp <alanhkarp@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Justin Richer <jricher@mit.edu> wrote:
>>>>>>>>>
>>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Adrian Gropper <agropper@healthurl.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is there an AS involved in the delegation? How and where in the
>>>>>>>>>>> lifecycle of the protected resource?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If tokens are certificates, the AS need not be involved in
>>>>>>>>>> subsequent delegations.  The AS must be involved if the tokens are opaque.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Tokens are opaque to the client instance. They are not opaque to
>>>>>>>>>> the AS. They might be opaque to the RS, but that depends on the kind of
>>>>>>>>>> relationship the RS and AS have. GNAP should allow different options here
>>>>>>>>>> as there are different use cases for that.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's
>>>>>>>>> implementation with VCs, or our Zebra Copy work.  Why must they be in GNAP?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The existence of the AS is exactly the reason for this. The AS is
>>>>>>>>> the role that “knowledge about the token contents” has been outsourced to
>>>>>>>>> in the GNAP model (which is based on the OAuth model).
>>>>>>>>>
>>>>>>>>> It brings significant simplicity for the client developer. The
>>>>>>>>> question I have is — why does the client need to know what’s in the token?
>>>>>>>>> Not if they could possibly know, but why would we expect a client to know
>>>>>>>>> and manage the contents of the token?
>>>>>>>>>
>>>>>>>>> The access token is fundamentally a conversational artifact
>>>>>>>>> between the AS and the RS which the client is the carrier of. The client is
>>>>>>>>> not the audience of the token, nor the creator of the token, nor even the
>>>>>>>>> manager of the token and the rights it represents. The client as a simple
>>>>>>>>> carrier is a powerful model that allows the security layer to get out of
>>>>>>>>> the way of the actual application logic that developers want to do.
>>>>>>>>>
>>>>>>>>>  — Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------
>>>>>>>>> Alan Karp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <jricher@mit.edu>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp <alanhkarp@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Adrian Gropper <agropper@healthurl.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is there an AS involved in the delegation? How and where in the
>>>>>>>>>>> lifecycle of the protected resource?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If tokens are certificates, the AS need not be involved in
>>>>>>>>>> subsequent delegations.  The AS must be involved if the tokens are opaque.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Tokens are opaque to the client instance. They are not opaque to
>>>>>>>>>> the AS. They might be opaque to the RS, but that depends on the kind of
>>>>>>>>>> relationship the RS and AS have. GNAP should allow different options here
>>>>>>>>>> as there are different use cases for that.
>>>>>>>>>>
>>>>>>>>>> It would probably be worthwhile to separate the portions of the
>>>>>>>>>> spec that talk about the RS-AS relationship into its own standalone
>>>>>>>>>> document. A similar approach was taken in UMA2 and it was helpful. (Though
>>>>>>>>>> admittedly, as with anything, there are missteps there that we can
>>>>>>>>>> hopefully learn from.)
>>>>>>>>>>
>>>>>>>>>>  — Justin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --------------
>>>>>>>>>> Alan Karp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <
>>>>>>>>>> agropper@healthurl.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Sure!
>>>>>>>>>>>
>>>>>>>>>>> Is there an AS involved in the delegation? How and where in the
>>>>>>>>>>> lifecycle of the protected resource?
>>>>>>>>>>>
>>>>>>>>>>> Also your use of "the client" seems to imply that either there
>>>>>>>>>>> is only one client or the client doesn't matter. Which is it?
>>>>>>>>>>>
>>>>>>>>>>> Adrian
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <
>>>>>>>>>>> fabien.imbault@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for that.
>>>>>>>>>>>>
>>>>>>>>>>>> Trying to reframe it:
>>>>>>>>>>>> GNAP is defined as a delegation protocol so the main intent is
>>>>>>>>>>>> related to a delegate of the RO (i.e. the end user) that wishes to access
>>>>>>>>>>>> the RO's protected resources, through the client.
>>>>>>>>>>>>
>>>>>>>>>>>> Fabien
>>>>>>>>>>>>
>>>>>>>>>>>> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <
>>>>>>>>>>>> agropper@healthurl.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> At various points in the lifecycle of the protected resource
>>>>>>>>>>>>> the client at the resource server (RS) might be:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - The RO (subject) user agent trading payment for a
>>>>>>>>>>>>>    service promise
>>>>>>>>>>>>>    - The RO user agent using the promise to access the
>>>>>>>>>>>>>    protected resource
>>>>>>>>>>>>>    - A delegate of the RO user agent using a different client
>>>>>>>>>>>>>
>>>>>>>>>>>>> What's vague is where the GNAP AS enters the picture as
>>>>>>>>>>>>> described above. How would you describe it?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Adrian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <
>>>>>>>>>>>>> fabien.imbault@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Adrian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm still confused why you're saying the terminology is
>>>>>>>>>>>>>> vague.
>>>>>>>>>>>>>> I get the "power" neutrality is not to your liking, but RQ /
>>>>>>>>>>>>>> user agent is no better in my view.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you elaborate?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Fabien
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <
>>>>>>>>>>>>>> agropper@healthurl.com> a écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm sure you're right. Our vague terminology around
>>>>>>>>>>>>>>> client and end-user leads to my confusion. If GNAP is primarily about
>>>>>>>>>>>>>>> delegation then, of course, we should avoid any incentives to impersonate
>>>>>>>>>>>>>>> or we're wasting our time. This is partly why I'm trying to study up on
>>>>>>>>>>>>>>> capabilities and asking for expert advice from folks like Alan Karp and
>>>>>>>>>>>>>>> Mark Miller (cc'd)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As best I can understand it, the RS has only two choices, it
>>>>>>>>>>>>>>> can:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    - store an attribute of the RO a [DID, email address,
>>>>>>>>>>>>>>>    GNAP AS URL], or
>>>>>>>>>>>>>>>    - hand the RO a capability as a sort-of promise and
>>>>>>>>>>>>>>>    avoid making any entries in an ACL or equivalent.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When a token comes back to the RS, it will either be:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    - validated according to something associated with the
>>>>>>>>>>>>>>>    stored RO attribute, or
>>>>>>>>>>>>>>>    - signed by the RS itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Either way, trust in the client seems moot.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <
>>>>>>>>>>>>>>> jricher@mit.edu> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper <
>>>>>>>>>>>>>>>> agropper@healthurl.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <
>>>>>>>>>>>>>>>> tobias.looker@mattr.global> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <snip>
>>>>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC as
>>>>>>>>>>>>>>>>> a certificate of authenticity linked to some audit mechanism.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that
>>>>>>>>>>>>>>>>> is to say a VC could be one type of valid assertion). The client may
>>>>>>>>>>>>>>>>> possess or been presented with a VC that it could include in its request to
>>>>>>>>>>>>>>>>> the AS as a way to identify the subject and perhaps prove authentication
>>>>>>>>>>>>>>>>> and authorization.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I do not assume that the client that interacts with the AS
>>>>>>>>>>>>>>>> to make a request and receive a token is the same as the client that will
>>>>>>>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for example, the
>>>>>>>>>>>>>>>> root of trust is a contract between the patient-subject and the
>>>>>>>>>>>>>>>> doctor-requesting party but the doctor workflow is expected to delegate the
>>>>>>>>>>>>>>>> token to some other end-user that may be using a totally different client
>>>>>>>>>>>>>>>> such as an EHR.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If the client that gets the token is not same as the client
>>>>>>>>>>>>>>>> that uses the token, that is a violation of core security principles as it
>>>>>>>>>>>>>>>> allows for (and really designs for) impersonation by client software. I
>>>>>>>>>>>>>>>> would have no reason to trust client software that would hand its
>>>>>>>>>>>>>>>> credentials over to another piece of software, and in fact I shouldn’t
>>>>>>>>>>>>>>>> trust it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think you may be conflating several different kinds of
>>>>>>>>>>>>>>>> parties under the “client” umbrella here, though. It’s entirely possible
>>>>>>>>>>>>>>>> that one client might call an RS that in turn acts as a client for
>>>>>>>>>>>>>>>> something else down stream. But each of those hops is different from the
>>>>>>>>>>>>>>>> last.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  — Justin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> TXAuth mailing list
>>>>>>>> TXAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>
>>>>>>> --
>>>>>>> TXAuth mailing list
>>>>>>> TXAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> TXAuth mailing list
>>>>>> TXAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>
>>>>> --
>>>>> TXAuth mailing list
>>>>> TXAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>> --
>>>> TXAuth mailing list
>>>> TXAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>
>>> --
>>> You know nothing Jon Snow!
>>>
>>>
>>> --
>> You know nothing Jon Snow!
>>
>>
>>
>