Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD)

[Fabien Imbault <[e-mail]>]

Inline too :-)

On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <[e-mail]> wrote:

> Hello Fabian, inline
>
> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <[e-mail]>
> wrote:
>
>> Hi Francis,
>>
>> My comments are embedded into your email with FI.
>>
>> You're saying in a follow-up message:
>> "- If you want privacy, *don't* expose RS identity to AS.
>> - If you want transparency, expose RS identity to AS.
>> You can't have both...."
>> While that may seem a reasonable dichotomy at first sight, I believe the
>> reality is actually more nuanced and depends on how we end up designing the
>> system.
>>
>> Cheers,
>> Fabien
>>
>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <[e-mail]> wrote:
>>
>>> Hello Fabian,
>>>
>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>>> Hi Francis,
>>>>
>>>> I think Denis points to the fact that, in the current situation, the AS
>>>> receives the resource request from the Client and therefore knows what
>>>> tokens are asked.
>>>>
>>> The token request must not mention any reference of the RS.
>>>
>>
>> FI : yes we can do that, but as Tom commented, it's not a general rule.
>> And for instance in XYZ you do describe the URL of the resource. See also
>> the use case on directed tokens, which is an interesting topic which makes
>> sense in many scenarios.
>>
> Yes. But disclosing the protected resource discloses the RS.
>

FI : yes of course. Which is why RS hiding may be a solution.

>
> But as soon as you include that possibility, it's fair to think that this
>> capability could be used for surveillance purposes in some cases, unless
>> you found a privacy by design scheme that applies by default.
>>
> Yes. THen default shall be using URI of resource description and not URL
> to indicate resource location.
>

FI : yes

>
> Again this doesn't mean that transparency requirements aren't important
>> too, but I think there are other ways it can be achieved (for instance, an
>> inspiration is the certificate transparency project). Could be an extension
>> to the protocol I believe.
>>
> The certificate transparency deals with something else. Does not fit in
> this context at all.
>
>
FI : It does, and has already been implemented by some projects in
relationship with OAuth2, as an additional component.

>
>>
>>>
>>>> Then it also implements the consent interface (and possibly the login
>>>> too) and so it also knows who validates and what is accepted or not.
>>>>
>>> Decoupling this does not change the privacy context, as the AS issues
>>> the Token. AS needs to add a reference to the RC in the token. SO AS can
>>> correlate on StudentId anyway.
>>>
>>
>> FI : I disagree. It does change the privacy context, if as Denis
>> suggested, the consent is made outside of the AS and if you don't send to
>> the AS the information on the RS when it needs to issue the token.
>> Correlation on StudentId is limited as long as it's a local identifier,
>> i.e. not a public DID.
>>
> How local can the StudentId be? It is known to both universities and to
> the AS. Without a public reference, you can not link information between
> unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then
> you do not need central AS anymore.
>

FI : see keri or peer DID for instance, as examples of local ID.
Again SSI/DID/VC doesn't mean you don't need AS, those technologies can be
complementary.


>
>> As a concrete example: a user may want to use an application to access
>> rs_domain/directory1 and rs_domain/directory2 in read and write, which are
>> managed by a RO.
>> What I suggested is that the Client may (optionally) carry out its
>> consent through a decoupled IS server (separated from the AS), that
>> displays the UI based on the RS requirements => the IS knows what
>> information is used, but the IS may be chosen by the IS independently from
>> the AS or even run by the Client itself.
>>
> What do you need an AS for? Then it can sign the claim to present to RS.
>

FI : to be sure, what is "it"?


>
>
>> In this case, suppose the RO only provided consent for
>> rs_domain/directory1 for read.
>> We now need to get back to the AS to mint the access token.
>>
> If AS mint access token, AS will be able to correlate. Unless start
> applying intransparent complex reference mapping techniques, wich might
> even open room for new attack vectors.
>

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis.

>
>
>> If we want the AS to not know about the RS, we either :
>> - don't supply the rs_domain at all -> the JWT says that directory1 in
>> read access is authorized. The downside is that we actually cannot control
>> to which URL the authorization applies. In that case I agree with your
>> either or statement.
>>
> Yes
>
>> - or find a way to hide it (not sure if that's practical, hence my
>> questions on RS hiding). This would have the benefit of still allowing
>> directed tokens -> the JWT says that rs_petname/directory1 in read access
>> is authorized.
>>
> More complexity.
>

FI : yes


>
>> Either way, the AS has not been provided any information as to where this
>> token will effectively be used.
>>
>
>>>
>>>> I don't think the abstract flow deals with those privacy concerns.
>>>>
>>> To solve the privacy problem addressed in this thread, we need to go the
>>> (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC
>>> (Verifiable Credential) to the Student (in his role of RC). The Student
>>> will then present this claim to UNIV-1 during his registration. In this
>>> case we need no Grant negotiation and no AS.
>>>
>>
>> FI : That may be useful but it's not enough. What you describe only works
>> because you take a very specific use case, aka registration. This fits well
>> into DID/VC without requiring authorization per say. However grant
>> negotiation is still required for more general settings of authorization.
>>
> Please drop the next use case in the repo, so we can dive deeper into it
> and see how to provide both central grant negotiation and privacy.
>

FI : will do.

>
> I've added a DID example to my implementation, will publish it soon.
>>
>>
>>> Best regards.
>>> /Francis
>>>
>>>>
>>>
>>>>
>>>> Then I agree with you on the audience field of the token, if left empty
>>>> it simplifies part of the problem, although it removes a big part of the
>>>> control you may want from directed tokens. That's why I'm willing to better
>>>> develop the RS hiding idea.
>>>>
>>>> Fabien
>>>>
>>>> Le mar. 11 août 2020 à 05:58, Francis Pouatcha <fpo=
>>>> [e-mail]> a écrit :
>>>>
>>>>> Hello Denis,
>>>>>
>>>>> what you describe in the use case seems to be the default behavior of
>>>>> the protocol. Let me map it with this abstract protocol flow:
>>>>>
>>>>> +-----------+      +--------------+  +-----------+  +----+
>>>>>  +---------------------+
>>>>> | Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource
>>>>> Controller |
>>>>> | is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |
>>>>>  is          |
>>>>> |   Staff   |      | Registr. App |  | Server    |  | AS |  |
>>>>>  Student       |
>>>>> +-----------+      +--------------+  +-----------+  +----+
>>>>>  +---------------------+
>>>>>   |(1) RegisterStudent    |                |           |
>>>>>   |
>>>>>   |---------------------->|                |           |
>>>>>   |
>>>>>   |                       |(2)
>>>>> RequestRecordIntent(RecordType,StudentId,
>>>>>   |                       |
>>>>>  OrchestratorId):AuthRequest[RecordType,StudentId]
>>>>>   |                       |<-------------->|           |
>>>>>   |
>>>>>   |                       |                |           |
>>>>>   |
>>>>>   |                       |(3)
>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId)
>>>>>   |                       |--------------------------->|
>>>>>   |
>>>>>   |                       |                |           |(4)
>>>>> ConsentRequest(RecordType,
>>>>>   |                       |                |           |
>>>>>  OrchestratorId):Consent
>>>>>   |                       |                |
>>>>>  |<-------------->|
>>>>>   |
>>>>>  |(5) AuthZ[RecordType,StudentId,OrchestratorId]
>>>>>   |                       |<---------------------------|
>>>>>   |
>>>>>   |                       |                |           |
>>>>>   |
>>>>>   |                       |(2)
>>>>> RequestRecord(RecordType,StudentId,OrchestratorId)
>>>>>   |                       |     :RecordOf[StudentId]   |
>>>>>   |
>>>>>   |                       |<-------------->|           |
>>>>>   |
>>>>>   |(7) Registered         |                |           |
>>>>>   |
>>>>>   |<----------------------|                |           |
>>>>>   |
>>>>>   +                       +                +           +
>>>>>   +
>>>>>
>>>>> we assume the authz request sent by "Client" to "AS" describes the
>>>>> protected resource without referring to the authz server. An AS can issue
>>>>> the authz to release the graduation record  of a student
>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to
>>>>> the target university.
>>>>>
>>>>> What matters for this authz object is:
>>>>> - StudentId: a reference to the student as known to the resource
>>>>> server.
>>>>> - RecordType: a reference to a resource of type graduation record as
>>>>> understandable  by the resource server.
>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind
>>>>> authz to Orchestrator.
>>>>>
>>>>> But:
>>>>> - RS must trust AS issued token.
>>>>> - StudentId must be known to RS, AS and Orchestrator.
>>>>>
>>>>> Therefore, the AS does not need to know the RS. Keep the audience
>>>>> field empty.
>>>>>
>>>>> Same principle applies for the second use case.
>>>>>
>>>>> What privacy problem do you see here?
>>>>>
>>>>> Best regards.
>>>>> /Francis
>>>>>
>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis <[e-mail]> wrote:
>>>>>
>>>>>> I tried my best twice to download three use cases in the Use cases
>>>>>> directory, but I failed.
>>>>>>
>>>>>> Rather than failing a third time, here is the direct link of the
>>>>>> second try:
>>>>>>
>>>>>>
>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD)
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>>
>>>>>> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>