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

[Fabien Imbault <[e-mail]>]

+1 on support for SSI, which I believe the charter includes (e.g. "Verified
Credentials").
Maybe not in the core (?) but at least as an extension.

Also interested in how you imagine the AS on the user's device, which I
believe is yet a separated topic from SSI (even is that could be an
enabler).

Cheers,
Fabien

On Wed, Aug 12, 2020 at 12:47 AM Francis Pouatcha <[e-mail]> wrote:

> Hello Tom,
>
> On Tue, Aug 11, 2020 at 6:42 PM Tom Jones <[e-mail]>
> wrote:
>
>> 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
>>
> I hope GNAP will be designed to support SII. If you could drop some use
> cases here: https://github.com/ietf-wg-gnap/general/wiki
>
>>
>>
>> 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/
>>>
>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>