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

[Francis Pouatcha <[e-mail]>]

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.

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.

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.


>
>
>>
>>> 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.

>
> 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.


> 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.


> 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.

>
> 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.

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/