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

[Fabien Imbault <[e-mail]>]

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

I don't think the abstract flow deals with those privacy concerns.

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
>