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

Adrian Gropper <agropper@healthurl.com> Fri, 19 March 2021 18:23 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 1D88A3A0883 for <txauth@ietfa.amsl.com>; Fri, 19 Mar 2021 11:23:34 -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 SOaK3Ebie8V0 for <txauth@ietfa.amsl.com>; Fri, 19 Mar 2021 11:23:29 -0700 (PDT)
Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (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 6E1693A086E for <txauth@ietf.org>; Fri, 19 Mar 2021 11:23:29 -0700 (PDT)
Received: by mail-vk1-f169.google.com with SMTP id o4so2304081vka.12 for <txauth@ietf.org>; Fri, 19 Mar 2021 11:23:29 -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=97SihIWrdW4PIU+DQpC3jvUPLRhtlpYbt8vnAPH3QH8=; b=j1vGV/XwW8cJl5zjnnnAoxVcL64RSJV4QpxYjXiZ8AdJ5PmlP4/ns6rkLY5zXiiEex 8kK+xBKBtxPFlxdxAtA8AlqsTXRlL/lm5v7ZvJiMH6Yet07eiMP8cojPeoNAZXhTTu3A M9G0RjtV4GxLl+VLABJ/hfz/MOLuUcRPWn8i92GRpBbmcmiiXQ/g3QQuwP9fn0/rYOhc heoYdillMEKq0I54mOaZZEruilvqzGWez7QiYDRog6B5cKrAwuWlvsI8DECBLiv4/Tq7 EYWvOrxJ3QV6Sqt8LsI5C4d+NE+fw5cDlO9mtq8dhe0SGD6b3A1nJfMdEQbFhJP97PKA f5Uw==
X-Gm-Message-State: AOAM533pDAtmqjqaKpEsZTVPMDmTln69u/1KUw1shRg174+aemsvUP4P KKiWa1xI8uDKqgBJACLt/JJGB5tnFPLQP24eELQ=
X-Google-Smtp-Source: ABdhPJxDphF/3WVgNN04JHjLJ+6b/L8ogN7PM6nbXABESy64Aa3IOCwL+LkBacK5d4+xejN2x5sZzRBRG10lGUb3Oh0=
X-Received: by 2002:a1f:914c:: with SMTP id t73mr3808317vkd.7.1616178208152; Fri, 19 Mar 2021 11:23:28 -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> <CANYRo8gzaCdHaqYXe7hAawe0_tOz=3tnULpgRjspbhA-9xAV-A@mail.gmail.com> <48B35DA4-9B92-493B-B2CC-C03544A1707D@mit.edu> <CAM8feuSFCLUFEKVdq=2ywjkCNpb+rKJJb8hPL=UdZRMvFFj36A@mail.gmail.com>
In-Reply-To: <CAM8feuSFCLUFEKVdq=2ywjkCNpb+rKJJb8hPL=UdZRMvFFj36A@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Fri, 19 Mar 2021 14:23:15 -0400
Message-ID: <CANYRo8iOg=efR_tr9+iFf3L-NyyUWYULj1cm_v=svAj+DVOM+Q@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Alejandro Iacobelli <aiacobelli.sec@gmail.com>, txauth gnap <txauth@ietf.org>, Steve Moore <srmoore@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fd9eed05bde7cf6b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/HSRE7kb_yBOxPOp_3Swit1CcNkk>
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 18:23:34 -0000

I'm not disagreeing, just reserving judgement until I see a PR about this
AS-RS idea.

My mention of the Capcha was a shortcut and a bad example. What I meant to
say is that relying parties, the RS in this case, can make demands. FIDO,
for example, can demand a certificate signed by some trusted entity and
that a person touch a thing.

As Justin says, the RO could be a person - but it could also be a thing or
an entity or software. So, I'm not sure where we're headed and look forward
to a proposal.

Adrian



On Fri, Mar 19, 2021 at 1:38 PM Fabien Imbault <fabien.imbault@gmail.com>
wrote:

> Oh I thought capchas were mostly a way to train your AI for free ;-)
>
> Joke aside, I support Justin's view of what goes into core versus what the
> kind of modularity we might bring in addition to that.
>
> Fabien
>
> On Fri, Mar 19, 2021 at 6:32 PM Justin Richer <jricher@mit.edu> wrote:
>
>> The only way for the RS operator could introduce a captcha, within the
>> definitions of the GNAP protocol, is through an AS. Or more properly,
>> through this yes-unnamed aspect of “interacting with the RO” that the AS is
>> in charge of coordinating the results of. The RS is not an end-user-facing
>> service, it is an API, software meant to be called by other software. The
>> defined way for the “RS” to interact with a person, issue tokens, or
>> anything of the sort is through an AS.
>>
>> In OAuth 1, the AS and RS were just called the “authorization server” or
>> even just “server", and it seems like a lot of the discussion on this
>> thread is collapsing that same set of roles back but instead calling it the
>> “RS”. I think this is problematic both in terms of the flexibility of the
>> protocol and also in terms of clarity in what we’re describing and
>> discussing.
>>
>>  — Justin
>>
>> On Mar 19, 2021, at 1:26 PM, Adrian Gropper <agropper@healthurl.com>
>> wrote:
>>
>> 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!
>>>>
>>>>
>>>>
>>>
>> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>