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

[Fabien Imbault <[e-mail]>]

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


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

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

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.
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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>
>>> --
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead
>>> adorsys GmbH & Co. KG
>>> https://adorsys-platform.de/solutions/
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>