Re: [GNAP] Will GNAP support Zero Trust Architecture?

[Fabien Imbault <[e-mail]>]

Indeed I was asking because it's easy to get it wrong, so the feedback of
higher authorities (Mark or Alan) is most welcome!

In the flow I was indeed expecting bearer tokens.

Fabien

Le sam. 20 mars 2021 à 13:03, Adrian Gropper <[e-mail]> a
écrit :

> Fabien, that is not the way I think of capabilities working. I would
> prefer to leave the explanation to experts that have tried to teach me over
> the years. That’s, in part, why I recommended Alan’s 40 minute talk at the
> beginning of this thread.
>
> To hold us over until one of them responds, I think of capabilities as a
> token that is signed by the issuer so no trust is involved. If the RS
> issues a capability to the RO signed by the RS, then it’s a pure bearer
> token and any client that appears at the RS API with that capability will
> access the resource. That’s option 1.
>
> Option 2 is not based on capabilities. The RS stores a public key and
> trusts any token signed to that public key. The public key represents the
> identity of the RO or the AS that the RO delegated to. That’s opaque to the
> RS.
>
> So the difference between the two options is in who signed the access
> token. The RS can offer both options to the RO if they’re nice.
>
> Adrian
>
> On Sat, Mar 20, 2021 at 6:52 AM Fabien Imbault <[e-mail]>
> wrote:
>
>> Thanks for the description.
>>
>> Trying to summarize what a capability  flow would look like following
>> those ideas:
>>
>> 1) RS issues a capability for the RO. For instance "view and download
>> photo".
>>
>> 2) RO can delegate that capability (or an attenuated version) to the AS.
>> Say "view photo", possibly with some ambient conditions.
>> If the RO further wants to choose between a list of possible ASs, the RO
>> would have to signal its choice to the RS, which would then have to signal
>> it to the client (what we had called RS preflight in some discussions). So
>> the AS-RS relationship would be mediated via the RO (or more precisely its
>> agent).
>>
>> 3) a core GNAP negociation takes place with the AS (traditional photo
>> example).
>>
>> Is that correct? Do not hesitate to correct me if I didn't accurately
>> capture what you said.
>> (I volontarily put DID aside for now)
>>
>> Steps occurring before 3 are optional (for reasons discussed before and
>> also because we can't assume all RSs would be able to support that).
>>
>> Fabien
>>
>> Le sam. 20 mars 2021 à 10:49, Adrian Gropper <[e-mail]> a
>> écrit :
>>
>>> Hi Fabien,
>>>
>>> Yes, it’s optional and adding meaningful options is one way to consider
>>> the ethical imperative http://www.cybsoc.org/heinz.htm
>>>
>>> If I understand Alan’s teachings, the RS has the option to either issue
>>> one or more capabilities to the RO or to store some identity-related
>>> information about the RO such as the DID of the RO and, by reference, the
>>> AS service endpoint controlled by that DID.
>>>
>>> Given some capabilities, the RO can either deal with them manually or
>>> hand them to an AS. Either way, the RS has no idea of the RO’s choice until
>>> it receives a token from some end user. This seems to be what the Letters
>>> of Transit in Casablanca were all about.
>>>
>>> If, on the other hand, the RO chooses to give 5e RS a DID, a
>>> self-sovereign identifier, instead of taking some capabilities, then the RS
>>> has the expectation  to trust tokens signed by that DID.
>>>
>>> It’s my hope that GNAP can allow an ethical RS to offer both choices to
>>> the RO.
>>>
>>> Adrian
>>>
>>>
>>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>>> Hi Adrian,
>>>>
>>>> Calling to one AS per persona can only be optional, as we have no way,
>>>> and no wish, of knowing all the identities used by the RO.
>>>>
>>>> I think this relates to the idea of the RO having its own distinct
>>>> agent, but I still don't understand how that would work (even re-reading
>>>> the thread in issue 145). Could you elaborate?
>>>>
>>>> Thxs
>>>> Fabien
>>>>
>>>>
>>>> Le sam. 20 mars 2021 à 06:08, Adrian Gropper <[e-mail]>
>>>> a écrit :
>>>>
>>>>> @Alan Karp <[e-mail]> shared a talk about the Principle Of
>>>>> Least Authority (POLA) in a recent comment
>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
>>>>> I recommend it.
>>>>>
>>>>> We might expect a protocol with authorization in the title to use
>>>>> authority as a core principle. I advocate for a GNAP design that maximizes
>>>>> the power of the RO, to be seen as a human rights issue when the RO is a
>>>>> human. This causes me to ask how to combine better security with better
>>>>> human rights in GNAP.
>>>>>
>>>>> Who should have the least authority in the GNAP design?
>>>>>
>>>>> The AS derives authority as a delegate of the RO. If we ask the RO to
>>>>> partition limited authority across dozens of different ASs by domain and
>>>>> function, then we are not using technology to empower the individual.
>>>>> Probably the opposite, as we introduce consent fatigue and burden normal
>>>>> people to partition their lives into non-overlapping domains.
>>>>>
>>>>> My experience says we should aim for one AS per persona because that
>>>>> maps into the way we manage our public and private identities. POLA would
>>>>> then teach care in keeping ASs and RSs related to work / public separate
>>>>> from ASs and RSs related to private life so that a policy vulnerability in
>>>>> our delegation to an AS would have the least likelihood of harm.
>>>>>
>>>>> Beyond that fairly obvious principle, we could spread our interactions
>>>>> among as many services as possible. We already do this when we spread
>>>>> assets across multiple banks, internet services across redundant platforms,
>>>>> or we use LinkedIn, Twitter, and Facebook with limited overlap in social
>>>>> graphs.
>>>>>
>>>>> At the next level down, we want to manage resources at each RS using
>>>>> least authority in order to make AS policy vulnerabilities easier to spot
>>>>> and debug. My AS might get multiple capabilities or access to scopes from
>>>>> an RS, each one carefully labeled with its intended uses so that the policy
>>>>> engine of my AS could be structured to consider requests relative to only
>>>>> one capability or scope family at a time. For example, in issuing health
>>>>> record authorizations, I might separate the behavioral health capabilities
>>>>> from capabilities to access the physical parts of my record at a given
>>>>> hospital's GNAP RS API.
>>>>>
>>>>> Lastly, at the level of attenuation, I would choose a relationship
>>>>> with RSs that issue to me capabilities that can be attenuated not only by
>>>>> my AS but also by the requesting parties that receive them as part of an
>>>>> access token.
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>> --
>>>>> TXAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>