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

[Francis Pouatcha <[e-mail]>]

+1 for temporary_id. Solves the privacy issue, but requires Step (2).

On Wed, Aug 12, 2020 at 10:13 AM Fabien Imbault <[e-mail]>
wrote:

> Thanks Denis.
>
> A few questions to clarify:
> - "the field included into the access token will look like a random number
> to the RS." - you mean AS?
> - "It should have two parts : a signed part and an unsigned part." -
> Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with
> short expiry) between the temporary_id and the url, on the RS side?
>
> Then the algorithm would be :
> 1. Client contacts the RS, which sends a resource description
> (temporary_id)
> 2. The flow continues and a token is generated, using the temporary_id
> 3. Client makes the call to the RS, using the token. The RS verifies the
> signature + it also verifies that the mapping is the one expected.
>
> BTW, it makes the RS decide the maximum token expiry.
> The issue is that it requires more work on the RS side, compared to a
> stateless JWT.
>
> Is that correct?
>
> Fabien
>
>
> On Wed, Aug 12, 2020 at 3:24 PM Denis <[e-mail]> wrote:
>
>> With so many messages in the last 24 hours, I can't respond to all of
>> them at once.
>> I picked the last one first.
>>
>> Inline too :-)
>>
>> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <[e-mail]> wrote:
>>
>>> Hello Fabian, inline
>>>
>>> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <[e-mail]>
>>> wrote:
>>>
>>>> Hi Francis,
>>>>
>>>> My comments are embedded into your email with FI.
>>>>
>>>> You're saying in a follow-up message:
>>>> "- 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...."
>>>> While that may seem a reasonable dichotomy at first sight, I believe
>>>> the reality is actually more nuanced and depends on how we end up designing
>>>> the system.
>>>>
>>> [Denis] This is in fact more nuanced. It is possible to prevent the AS
>> to know who the RS is by hiding the true identifier of the RS to the AS.
>>
>> This means that for security reasons the access token is still targeted
>> but that the field included into the access token will look like a random
>> number to the RS.
>> That random number will change for every access token.
>>
>> In order for the RS to make sure that the access token is indeed intended
>> for itself, it will need to combine the field included into the access
>> token
>> with an unsigned field external to the access token.
>>
>> This would have a major consequence for the structure of a GNAP access
>> token that will be rather different from an OAuth 2.0 access token.
>> It should have two parts : a signed part and an unsigned part.
>>
>>
>>>> Cheers,
>>>> Fabien
>>>>
>>>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <[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.
>>>>>
>>>>
>>>> FI : yes we can do that, but as Tom commented, it's not a general rule.
>>>> And for instance in XYZ you do describe the URL of the resource. See also
>>>> the use case on directed tokens, which is an interesting topic which makes
>>>> sense in many scenarios.
>>>>
>>> Yes. But disclosing the protected resource discloses the RS.
>>>
>>
>> FI : yes of course. Which is why RS hiding may be a solution.
>>
>>>
>>> But as soon as you include that possibility, it's fair to think that
>>>> this capability could be used for surveillance purposes in some cases,
>>>> unless you found a privacy by design scheme that applies by default.
>>>>
>>> Yes. THen default shall be using URI of resource description and not URL
>>> to indicate resource location.
>>>
>>
>> FI : yes
>>
>>>
>>> Again this doesn't mean that transparency requirements aren't important
>>>> too, but I think there are other ways it can be achieved (for instance, an
>>>> inspiration is the certificate transparency project). Could be an extension
>>>> to the protocol I believe.
>>>>
>>> The certificate transparency deals with something else. Does not fit in
>>> this context at all.
>>>
>>>
>> FI : It does, and has already been implemented by some projects in
>> relationship with OAuth2, as an additional component.
>>
>>>
>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>
>>>> FI : I disagree. It does change the privacy context, if as Denis
>>>> suggested, the consent is made outside of the AS and if you don't send to
>>>> the AS the information on the RS when it needs to issue the token.
>>>> Correlation on StudentId is limited as long as it's a local identifier,
>>>> i.e. not a public DID.
>>>>
>>> How local can the StudentId be? It is known to both universities and to
>>> the AS. Without a public reference, you can not link information between
>>> unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then
>>> you do not need central AS anymore.
>>>
>>
>> FI : see keri or peer DID for instance, as examples of local ID.
>> Again SSI/DID/VC doesn't mean you don't need AS, those technologies can
>> be complementary.
>>
>>
>>>
>>>> As a concrete example: a user may want to use an application to access
>>>> rs_domain/directory1 and rs_domain/directory2 in read and write, which are
>>>> managed by a RO.
>>>> What I suggested is that the Client may (optionally) carry out its
>>>> consent through a decoupled IS server (separated from the AS), that
>>>> displays the UI based on the RS requirements => the IS knows what
>>>> information is used, but the IS may be chosen by the IS independently from
>>>> the AS or even run by the Client itself.
>>>>
>>> What do you need an AS for? Then it can sign the claim to present to RS.
>>>
>>
>> FI : to be sure, what is "it"?
>>
>>
>>>
>>>
>>>> In this case, suppose the RO only provided consent for
>>>> rs_domain/directory1 for read.
>>>> We now need to get back to the AS to mint the access token.
>>>>
>>> If AS mint access token, AS will be able to correlate. Unless start
>>> applying intransparent complex reference mapping techniques, wich might
>>> even open room for new attack vectors.
>>>
>>
>> FI : not necessarily with respect to correlation, see above.
>> As for mapping techniques, this is the very reason of my question to
>> Denis.
>>
>>>
>>>
>>>> If we want the AS to not know about the RS, we either :
>>>> - don't supply the rs_domain at all -> the JWT says that directory1 in
>>>> read access is authorized. The downside is that we actually cannot control
>>>> to which URL the authorization applies. In that case I agree with your
>>>> either or statement.
>>>>
>>> Yes
>>>
>>>> - or find a way to hide it (not sure if that's practical, hence my
>>>> questions on RS hiding). This would have the benefit of still allowing
>>>> directed tokens -> the JWT says that rs_petname/directory1 in read access
>>>> is authorized.
>>>>
>>> More complexity.
>>>
>>
>> FI : yes
>>
>> [Denis] As indicated at the top of this email, it is possible to always
>> hide the identifier of the RS while still targetting every access token.
>>
>> BTW, I have expanded the notion of targetting by allowing to place into a
>> target field of an access token either or both a RS identifier and
>> a Service Name (SN) identifier to which the RS belongs.
>>
>> Two targetting fields should hence be possible: a RS identifier and a SN
>> identifier.
>>
>> This is also a difference with an OAuth 2.0 access token.
>>
>> Either way, the AS has not been provided any information as to where this
>>>> token will effectively be used.
>>>>
>>>
>>>>>
>>>>>> 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.
>>>>>
>>>> [Denis] This is a complete redesign of my example and hence this
>> redesign has no relationship with my example.
>>
>>
>>>> FI : That may be useful but it's not enough. What you describe only
>>>> works because you take a very specific use case, aka registration. This
>>>> fits well into DID/VC without requiring authorization per say. However
>>>> grant negotiation is still required for more general settings of
>>>> authorization.
>>>>
>>> Please drop the next use case in the repo, so we can dive deeper into it
>>> and see how to provide both central grant negotiation and privacy.
>>>
>>
>> FI : will do.
>>
>>>
>>> I've added a DID example to my implementation, will publish it soon.
>>>>
>>>>
>>>>> 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:
>>>>>>>
>>>>>> [Denis] The redesign below has no relationship with my use case.
>>
>> A key element of my design is the User, i.e. a physical person which
>> initiates the exchanges. In the example below the User has disappeared.
>>
>> A User is not a role, but an entity.
>>
>> BTW, I can't understand the role of an "Orchestrator" (which is left
>> undefined).
>>
>>
>>>>>>> +-----------+      +--------------+  +-----------+  +----+
>>>>>>>  +---------------------+
>>>>>>> | 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?
>>>>>>>
>>>>>> [Denis] The User, a physical person which initiates the exchanges has
>> disappeared.
>> No more user, no more privacy issues ? :-)
>>
>> Denis
>>
>>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>> 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/