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

[Tom Jones <[e-mail]>]

I guess I need to ask the group as a whole then.
Will GNAP support self-issued Identifiers?
If so then the AS is on the user's device.
I need to understand that SII are in-scope.
Peace ..tom


On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha <[e-mail]> wrote:

> On Tue, Aug 11, 2020 at 6:27 PM Tom Jones <[e-mail]>
> wrote:
>
>> "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
>>
> - 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....
> /Francis
>
>>
>>
>>
>> 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
>>>
>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>