Re: [GNAP] Should access tokens be opaque or not for the clients ?
Adrian Gropper <agropper@healthurl.com> Fri, 19 March 2021 01:04 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 B9BE93A1165 for <txauth@ietfa.amsl.com>; Thu, 18 Mar 2021 18:04:09 -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 qiL7NZNPTjlk for <txauth@ietfa.amsl.com>; Thu, 18 Mar 2021 18:04:04 -0700 (PDT)
Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 336E83A114D for <txauth@ietf.org>; Thu, 18 Mar 2021 18:04:04 -0700 (PDT)
Received: by mail-vs1-f41.google.com with SMTP id s25so2600275vsa.1 for <txauth@ietf.org>; Thu, 18 Mar 2021 18:04:04 -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=8fVsPDCtbE3F+WR9Xj38dDNkW7iUWeGfA9X81LzOjI0=; b=SbuV6wQM8ystvFW3DLAc3qTaLDzh4vUGWiNTXEsySw9fiEYDju2lvdS5eU+qYkOKAr u8ftSgsm0eOEP5yVVFti1Z56uwxye+x+rHhA4hEBFfWY70fTwmAY5KtbqiAiR4OwFEVy zp1yI0Fc1mt1K5ZxqC9JRS+MCNONQmAiopo+DscWYu6z2W9JNyfYI52af/vzCYnzqFWr Bna5r0qWImGdoz1BBZpbfOcsCpOvyRzM3WLBnDwQjJLzspcmYo6zyxMnF3Dq/VyLbLcC dwY6u1KWmgBiglv69SDf8zaVl57e/7jcsmazByCk977fbuNaR6cmKKzndHN0kElOaARo AnZQ==
X-Gm-Message-State: AOAM532Bx0NWIOziDt6GsMNRjTeDeREidoByKKSt7s1wgnQSa6dwN2TN DfY6vCMdF5DXxxoKMcK6/aV2Ulg1+9sD3zr0k/qz75KUYNg=
X-Google-Smtp-Source: ABdhPJy7bS6S5NdpzR6ZuYhvvvcRFA7MfYMjlFMtSs98MD/Q4qU6fS9pkOK3ME2ZKvQdpzHfQNPtvDYivLa2Z2vmS9Y=
X-Received: by 2002:a05:6102:24a:: with SMTP id a10mr1323769vsq.39.1616115843013; Thu, 18 Mar 2021 18:04:03 -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>
In-Reply-To: <CAM1Hn1XxtdXV0cWOo7TYQUPRZ4t0eo8eU+mJCxgw9_W0jPnijA@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Thu, 18 Mar 2021 21:03:51 -0400
Message-ID: <CANYRo8gY-aGhKB3RMUPJ9PEoBR6Qr122bzJsZnePytMQ=+heYA@mail.gmail.com>
To: Alejandro Iacobelli <aiacobelli.sec@gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, txauth gnap <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Steve Moore <srmoore@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000bd202405bdd94abc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/Zm7X7hW5gz8DyNLmu352rpDI5bw>
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 01:04:11 -0000
I'm not a security person. I do, however, have a lot of experience with regulatory practices as relates to safety in medical devices and business. I see the security struggles of today as being an over-reliance on institutional trust and a lack of effective audit and individual accountability. I see great promise in moving advanced crypto to the individual through DIDs and VCs and then using these identity-based components in protocols like GNAP that are directly in the security, audit, and accountability role. DIDs, VCs, and capabilities, to me, are just data models. I know that's a very vague and philosophical answer to give to architects like the folks in this group. Sorry. >From this perspective, GNAP is where we get to introduce individual accountability, resilience against single points of failure, practical audit mechanisms, and the benefit of a decade of blockchain-driven cryptography advances. I don't see GNAP as complicated, but what do I know? Adrian On Thu, Mar 18, 2021 at 8:24 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! > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >
- [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Tobias Looker
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Tobias Looker
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Denis
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Tobias Looker
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Tobias Looker
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Alan Karp
- Re: [GNAP] DID as sub_id or assertion? Alan Karp
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Denis
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] DID as sub_id or assertion? Adrian Gropper
- Re: [GNAP] DID as sub_id or assertion? Alan Karp
- Re: [GNAP] DID as sub_id or assertion? Alan Karp
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- [GNAP] Should access tokens be opaque or not for … Denis
- Re: [GNAP] DID as sub_id or assertion? Justin Richer
- Re: [GNAP] DID as sub_id or assertion? Fabien Imbault
- Re: [GNAP] Should access tokens be opaque or not … Stephen Moore
- Re: [GNAP] Should access tokens be opaque or not … Justin Richer
- Re: [GNAP] Should access tokens be opaque or not … Stephen Moore
- Re: [GNAP] Should access tokens be opaque or not … Justin Richer
- Re: [GNAP] Should access tokens be opaque or not … Adrian Gropper
- Re: [GNAP] Should access tokens be opaque or not … Fabien Imbault
- Re: [GNAP] Should access tokens be opaque or not … Alejandro Iacobelli
- Re: [GNAP] Should access tokens be opaque or not … Adrian Gropper
- Re: [GNAP] Should access tokens be opaque or not … Justin Richer
- Re: [GNAP] Should access tokens be opaque or not … Alejandro Iacobelli
- Re: [GNAP] Should access tokens be opaque or not … Justin Richer
- Re: [GNAP] Should access tokens be opaque or not … Adrian Gropper
- Re: [GNAP] Should access tokens be opaque or not … Justin Richer
- Re: [GNAP] Should access tokens be opaque or not … Adrian Gropper
- Re: [GNAP] Should access tokens be opaque or not … Justin Richer
- Re: [GNAP] Should access tokens be opaque or not … Fabien Imbault
- Re: [GNAP] Should access tokens be opaque or not … Adrian Gropper