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

[Tom Jones <[e-mail]>]

"The token request must not mention any reference of the RS."
this cannot be an absolute rule. I have cases were the client needs to tell
the user which they are coming back for additional grants.
The reason is typically because a request by the client for data/access
from the rs was rejected. The reason for the rejection is important for the
client to make the case to the user for additional permissions.
Peace ..tom



On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha <fpo=
[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.
>
>
>> 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/
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>