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

[Francis Pouatcha <[e-mail]>]

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.


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


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

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/