Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11

[Dick Hardt <[e-mail]>]

Hi Denis

I would think in your example below, that the University's registration
system is the Client, not a Resource Server.

Have a good night's sleep!



On Fri, Jul 24, 2020 at 12:04 PM Denis <[e-mail]> wrote:

> Hi Dick,
>
> In order to send back a quick reply tonight, I will only respond to one of
> your questions:
>
> [Denis] How would be the data flow when access tokens from two GSs are
> needed by a RS ?
>
> [Dick] I don't know of a use case where two tokens would be needed by an
> RS. Would you elaborate?
>
> I already described on the list the case of a student registering to a new
> University.
>
> First, the student connects to the RS from the new University and opens an
> account
> (at this time the student is using a pseudo and a private key to
> authenticate). He fills some forms
> and indicate its citizenship, his home address and his graduation in his
> current university.
>
> When he is finished, he indicates that he wants to perform a Registration
> operation.
>
> From the information gathered in the forms, the RS informs the client that
> it needs two access tokens:
>
>    - one to demonstrate that his name and current home address are
>    correct,and
>    - another one to demonstrate that he got a graduation from its current
>    University.
>
> Depending upon the information captured in the forms, the RS also
> indicates which ASs/GSs are acceptable
> and which kind of attributes are requested.
>
> The user consent and choice is performed by the client and once approved
> by the student, two access tokens are separately requested.
> Finally, two access tokens are presented to the RS while invoking a
> Registration operation.
>
> Note that the start of the story is to open an account, e.g. using FIDO.
> The needs of the RS are only disclosed to the student once he has filled
> some forms
> and indicated that he wanted to perform a Registration operation. Thus,
> the needs that are revealed by the RS are dependant both upon the operation
> that the student is willing to perform and the information collected in
> the forms.
>
> Denis
>
> Hi Denis, comments inserted ...
>
> On Fri, Jul 24, 2020 at 9:08 AM Denis <[e-mail]> wrote:
>
>> Hi Dick,
>>
>> draft-hardt-xauth-protocol-13 describes a solution without clearly
>> stating what the problem(s) to be solved is/are.
>>
>
> I agree that the problem description is not as crisp as I would like it to
> be. A challenge is that there is a broad spectrum of use cases solved by
> OAuth 2, and OpenID Connect, as well as the new use cases that are solved
> by GNAP.
>
> That is why I am suggesting we gather some use cases so we have a common
> understanding of the problems that are in scope.
>
>
>>
>> At the moment, draft-hardt-xauth-protocol-13 includes a single figure on
>> page 4 and from previous discussions I understood that
>> it is no more up-to-date since the first data flow is now a contact with
>> a RS. The reason(s) for the GS to contact a RO has still not
>> been explained (since the inputs and outputs are not described). The
>> discovery information made available at various steps at the RS
>> is not described.
>>
>
> I have made no updates as we are in a quiet period prior to the WG meeting
> next week when documents cannot be updated.
>
>
>>
>> Figure 4 shows only a single RS. Is the relaying of one operation by that
>> RS to a second RS in the scope of this document ?
>> If yes, how is it handled ?
>>
>
> I view that as an advanced use case that would be covered in a separate
> document.
>
>
>>
>> Figure 4 shows only a single GS. How would be the data flow when access
>> tokens from two GSs are needed by a RS ?
>>
>
> I don't know of a use case where two tokens would be needed by an RS.
> Would you elaborate?
> The RS being able to accept tokens from two different GSes is covered, but
> the Client is only using a token from one GS at a time.
>
>
>
>>
>> What we need first is not a set of "use cases" but a clear model with a
>> data flows and a list of its properties/characteristics.
>>
>
> I disagree. The use cases describe the problems we are looking to solve.
> The data flows are part of the solution. For example, from my understanding
> of your use case, you don't want the GS to have visibility into the User's
> activity. Am I correct that this is one of your requirements for your use
> case?
>
>
>
>> Then after, we can understand much better which use cases can/will be
>> supported. For example, shall a RS (or its RO) have
>> prior relationships with the GS ? What is the difference/implications
>> when it has or it hasn't ?
>>
>> In order to have a fair comparison, we should try to list model
>> properties/characteristics.
>>
>> At the moment, the model I have described including the data flows is
>> clear. The discovery information made available by a RS is clear.
>> I have not listed all its properties/characteristics of that model, but I
>> am pretty sure that you already have a flavour of it.
>>
>> In the mean time, it would be nice if you could show using two figures:
>>
>>    - the case of the relaying of one operation by one RS to a second RS
>>    (if it is in the scope of your document),
>>    - the case where access tokens from two GSs are needed by one RS (if
>>    it is in the scope of your document).
>>
>>
> See above
>
>
>>
>>    -
>>
>> Denis
>>
>> Hi Denis
>>
>> I think it would be useful to take a step back and for you to describe
>> your use case.
>> After that, we can explore the different ways that your use case can be
>> addressed.
>>
>> Looking at your previous communication, it describes the solution, and
>> the justification,
>> but it is not clear what use cases you are needing to solve.
>>
>> /Dick
>>
>>
>> ᐧ
>>
>> On Wed, Jul 22, 2020 at 9:34 AM Denis <[e-mail]> wrote:
>>
>>> Hello Dick,
>>>
>>> I have identified the reason of the major difference between our two
>>> approaches.
>>>
>>> Access control may be performed using either ACLs (Access Control Lists)
>>> or Capabilities.
>>>
>>> *Note *: a capability identifies a resource and an allowed operation
>>> that can be performed on that resource.
>>>
>>> You are advocating a Capabilities approach while I am advocating an ACL
>>> approach.
>>>
>>> The capabilities approach allows the GS to trace every operation
>>> performed by the users on any RS known by a GS.
>>> The management of these capabilities is made via the GS or at the GS by
>>> the various ROs. If the management is made
>>> via the GS, then a trusted communication channel needs to be established
>>> with every RO. If the management is made
>>> at the GS, then an authentication mechanism needs to be established with
>>> every RO. In the last case, the GS has the
>>> ability to know all the capabilities of the users whether they are used
>>> or not. The less that can be said is that this model
>>> is not privacy friendly.
>>>
>>> With the ACL approach, a RO directly manages an ACL placed in front of
>>> each RS. The Access Control Decision Function
>>> (ADF) at the RS is able to keep track from prior decisions. The GS is
>>> kept ignorant of the content of these ACLs and only
>>> delivers to its clients attributes that are placed into access tokens.
>>> Such a model may be privacy friendly.
>>>
>>> Other comments are between the lines prefixed with [Denis].
>>>
>>>
>>> On Tue, Jul 21, 2020 at 11:26 AM Denis <[e-mail]> wrote:
>>>
>>>> Hello Dick,
>>>>
>>>> Thank you for your feedback. Comments are between the lines.
>>>>
>>>> comments inserted ...
>>>>
>>>> On Tue, Jul 21, 2020 at 6:03 AM Denis <[e-mail]> wrote:
>>>>
>>>>> Hello Dick,
>>>>>
>>>>> I duplicate the most important comment at the beginning of this email:
>>>>>
>>>>> You are considering using an access control model to build a workflow
>>>>> model.
>>>>>
>>>>> While it may be interesting to define a workflow model, this should be
>>>>> considered
>>>>> as a separate and different work item.
>>>>>
>>>>> See the other comments between the lines.
>>>>>
>>>>> On Mon, Jul 20, 2020 at 2:05 AM Denis <[e-mail]> wrote:
>>>>>
>>>>>> Hi Dick,
>>>>>>
>>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis <[e-mail]> wrote:
>>>>>>
>>>>>>> Hello Francis and Dick,
>>>>>>>
>>>>>>> The good news first: we are making some progress. We are now close
>>>>>>> to an agreement with steps (1) up to (3),
>>>>>>> ... except that the place where the user consent is captured is not
>>>>>>> mentioned/indicated.
>>>>>>>
>>>>>>
>>>>>> This major question which is currently left unanswered is where, when
>>>>>> and how the user consent is captured.
>>>>>>
>>>>>
>>>>> When is covered, per the sequence. How and where are out of scope of
>>>>> what I drafted.
>>>>>
>>>>> It is clear that the "User consent and choice" is not currently
>>>>> addressed in the draft, but it should.
>>>>> The support of the "User consent and choice" has strong implications
>>>>> not only in the sequences of the exchanges
>>>>> but also by which entity it should be performed.
>>>>>
>>>> "consent" is in the latest draft 7 times.
>>>>
>>>> "Consent" is present 5 times. The User consent is different from the RO
>>>> consent (when/if it is required).
>>>>
>>>> The server acquires consent and authorization from the user *and/**or
>>>> resource owner **if required.*
>>>>
>>>> User consent is *often required* at the GS. GNAP enables a Client and
>>>> GS to negotiate the interaction mode for the GS to obtain consent.
>>>>
>>>> The GS *may *require explicit consent from the RO or User to provide
>>>> these to the Client.
>>>>
>>>> The User consent is not an alternative to the RO consent. So using
>>>> "and/or" in the first sentence is incorrect.
>>>>
>>>
>>> My language is sloppy there. Consent is always from the RO. The User may
>>> be the RO.
>>>
>>> [Denis] No. Once again: The "*User consent*" is different from what you
>>> call the "*RO consent*" (when/if it is required).
>>> The "RO consent" is not in fact a consent but the release of a
>>> capability to a client by one of the many R0s with which
>>> the GS has relationships.
>>>
>>> Since the second sentence is using the wording "often required" there is
>>>> no requirement to get the User consent.
>>>>
>>> User consent may not be required. There may not be a User. The consent
>>> may have been gathered previously.
>>>
>>> [Denis] In order to follow the privacy principles, a "User consent"
>>> phase is required. The User is a natural person.
>>> A Client is called either by a User (i.e. a natural person) or by a
>>> Client application.
>>>
>>> The second sentence does not consider the possibility to get the User
>>>> consent in a place different from the GS.
>>>>
>>> Agreed. But we do agree that the GS gets the consent, either directly
>>> from the RO, or from the Client (in your example).
>>>
>>> [Denis] No. I disagree. In an ACL based systems, the GS does not need to
>>> ask or receive any consent.
>>> The client selects the set of attributes that it wants to be inserted
>>> into an access token.
>>> If the GS has the requested attributes, then it provides them, otherwise
>>> it returns an error to the Client.
>>>
>>> IMO, the User consent should be captured by the Client, i.e. not by the
>>>> GS.
>>>> The information used to obtain the User consent should be standardized
>>>> (... and it can be standardized).
>>>>
>>>> I think the abstract sequence as proposed by Francis is a great
>>>> addition, and would clarify where consent is in the sequence.
>>>>
>>>> The current sketch does not illustrate the place the User Consent is
>>>> captured, in particular by the Client.
>>>>
>>> It is an abstraction. The GS receives the consent. How consent is
>>> gathered is a detail that is dependent on the use case.
>>>
>>> [Denis] I really wonder whether there is really a "consent" to be
>>> received by the GS in both cases (i.e. ACLs or Capabilities).
>>>
>>>    - For ACLs, the consent needs to be done by the Client.
>>>    - For Capabilities, the current description is not clear since the
>>>    inputs and the outputs for this "consent" phase
>>>    are not currently described in the draft.
>>>
>>>
>>>
>>>>
>>>>
>>>>> Another important point to consider and to explain is related to the
>>>>>> assurances that the user can obtain about
>>>>>> the respect of his choices. This point is currently left unanswered
>>>>>> in draft-hardt-xauth-protocol-13.
>>>>>>
>>>>> This point is equally important: such assurance can only be obtained
>>>>> if the access token returned to the client
>>>>> is not considered to be opaque to the client. This is a necessary
>>>>> condition but not the single condition:
>>>>> the Client must also be in a position to capture/memorize the "User
>>>>> consent and choice" of the user in order to be able
>>>>> to verify it afterwards using the content of the access token(s).
>>>>>
>>>>
>>>> We disagree on this being a requirement for all use cases. It may be in
>>>> some.
>>>>
>>>> OK. Then this means that there will be no sentence in the draft such as
>>>> :
>>>> "access tokens returned to the client are not considered to be opaque
>>>> to the client".
>>>>
>>>
>>> For OAuth use cases, which GNAP supports, the access token is opaque to
>>> the Client. As you have noted, there are use cases where the access token
>>> is NOT opaque.
>>>
>>> [Denis] Wait a second. There is no requirement to support all OAuth use
>>> cases.
>>> I believe that there is a requirement to support OAuth 2.0 ASs, while
>>> the clients may be different
>>> and hence GNAP clients do not need to inherit of the limitations of
>>> OAuth 2.0 clients.
>>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>> If a RO needs to be involved and since a RO is directly associated
>>>>>>> with a RS, why can't it be directly queried
>>>>>>> by the appropriate RS after step (2) or later on ?
>>>>>>>
>>>>>>
>>>>>> Good question. Perhaps you can expand on a use case where that would
>>>>>> be useful?
>>>>>>
>>>>>> Before I expand, would you be able to explain first under which
>>>>>> circumstances a RO needs to be queried by a GS ?
>>>>>> How can the GS identify which RO to query ?
>>>>>>
>>>>> If the User is the RO, then the GS knows who to query.
>>>>>
>>>>> I still have difficulties to understand what you mean here.
>>>>> How could a GS know that "the User is the RO" ?  If "the User is the
>>>>> RO", why does the GS needs to query the User ?
>>>>>
>>>>
>>>> To get consent?
>>>>
>>>> To get a "RO consent" to himself ???
>>>>
>>>
>>> The GS needs consent from the RO. If the RO is the User, then consent
>>> from the RO is equivalent to consent from the User.
>>>
>>> [Denis] See above.
>>>
>>>
>>>
>>>>
>>>>
>>>>> If the RO is a separate entity, then the GS knows the RO from the RS
>>>>> being queried.
>>>>>
>>>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>>>> accessed by a given User and at which instant of time the access token has
>>>>> been granted.
>>>>>
>>>>> An example is a user would like access to an enterprise asset where a
>>>>> workflow is started to gain approval, and an administrator or manager
>>>>> provides consent.
>>>>>
>>>>> Thanks for this example. I finally understand what you have in mind:
>>>>> you are considering using an access control model to build a *workflow
>>>>> model*.
>>>>> While it may be interesting to define a workflow model, this should be
>>>>> considered as a *separate and different work item*.
>>>>>
>>>>
>>>> The actual workflow is out of scope.
>>>>
>>>> I am glad you agree with this. But this means that your example was not
>>>> appropriate to illustrate your point.
>>>>
>>>
>>> It illustrates a use case where the RO and User are not the same party,
>>> and why the GS needs to query the RO, which was your question if I
>>> understood it correctly.
>>>
>>> [Denis] Since the inputs and the outputs for this "RO consent" phase are
>>> not currently described in the draft, the point is still unsolved.
>>>
>>> As soon as there is a RO consent obtained at the GS, the major problem
>>>> is that the GS is able to act as Big Brother.
>>>> If a RO consent is performed at the RS, then the GS will not know who
>>>> the RS is: it is then unable to act as Big Brother,
>>>> even if it would enjoy to play that role.
>>>>
>>> In an enterprise use case, the GS's knowledge of who is accessing which
>>> RS is a feature.
>>>
>>> Do you mean that it is "normal" in an enterprise that a single point of
>>> control is able to trace all their actions ?
>>> From a security point of view, a single point of failure will have
>>> dramatic consequences.
>>>
>>> In your use cases, it seems that the RO is the User.
>>>
>>> I do hope that you have finally understood that, in my use case, the RO
>>> is **not** the User.
>>>
>>> The GS knows the User is wanting to let a Client access something. If
>>> the access token is generic, and could be presented to any RS that provides
>>> a standardized function,
>>> then the GS does not know which RS is being accessed by a Client for the
>>> User. This seems to meet your privacy objectives. If not, what is wrong?
>>>
>>> For security reasons, an access token needs to be targeted (which does
>>> not necessarily mean that an identifier of the RS shall be included into
>>> the access token).
>>>
>>> if the admin grants access, then the access granted to the client
>>>> changes.
>>>>
>>>>> The model you propose may be suited for an enterprise environment but
>>>>> is not scalable over the Internet.
>>>>>
>>>> It is one of the use cases we are working to address.
>>>>
>>>>> What is needed is an access control model usable over the Internet
>>>>> with millions of RSs and thousands of ASs/GSs.
>>>>>
>>>> I agree the model should also scale to internet scale.
>>>>
>>>> Fine. Another point on which we are in agreement.
>>>>
>>>> The model can scale to the Internet based on the following assumptions:
>>>>
>>>> The flow starts with the steps (1) to (4) as illustrated by Francis,
>>>> i.e. the flow starts with a contact with a RS.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |
>>>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     |
>>>>    |   |-------->|       |      |      |   |         |(2) Service Intent
>>>> |   |         |------>|      |      |   |         |(3) AuthZ Challenge  |
>>>> |         |<------|      |      |   |         |(4) AuthZ Request    |   |
>>>>       |------------->|      |*
>>>>
>>>> The GS/AS does not need to have any prior relationship with ROs and/or
>>>> RSs.
>>>>
>>>> Furthermore, it is possible to prevent the GS to act as Big Brother
>>>> when the identity of the RS is not disclosed to the GS.
>>>>
>>>
>>> What happens after (4) above?
>>>
>>> [Denis] The key point is that we first need to agree on the first four
>>> exchanges. Do we ?
>>>
>>> The fifth exchange is different whether ACLs or Capabilities are being
>>> used.
>>>
>>>
>>>
>>>> Which information is supposed to be presented to the RO ?
>>>>>>> Which information is supposed to be returned by the RO ?
>>>>>>>
>>>>>>
>>>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>>>> communicate is out of scope.
>>>>>>
>>>>>> At the moment, the usefulness of a dialogue between a GS and a RO has
>>>>>> not been explained, nor demonstrated.
>>>>>> The question is about the functionality of that dialogue in terms of
>>>>>> input and output information (and not about
>>>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>>>> dialogue between a GS and a RO is optional.
>>>>>>
>>>>>
>>>>> See enterprise example above.
>>>>>
>>>>> It is not an access control example, but a workflow example.
>>>>>
>>>>> Access  control has been defined a long time ago and the last edition
>>>>> of the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>>>> "Information technology — Open Systems Interconnection — Security
>>>>> frameworks for open systems: Access control framework — Part 3".
>>>>>
>>>>> Two major functions have ben defined: an Access Control Enforcement Function
>>>>> (AEF) and an Access Control Decision Function(ADF).
>>>>>
>>>>> Access Control Enforcement Function (AEF):
>>>>> A specialized function that is part of the access path between an
>>>>> initiator and a target on each access request and enforces the decision
>>>>> made by the ADF.
>>>>> Access Control Decision Function (ADF) :
>>>>> A specialized function that makes access control decisions by applying
>>>>> access control policy rules to an access request, ADI (of initiators,
>>>>> targets, access requests,
>>>>> or that retained from prior decisions), and the context in which the
>>>>> access request is made.
>>>>>
>>>>> The role of the RO is to define the "access control policy rules" at
>>>>> the RS according to the context in which the access request is made.
>>>>>
>>>> I'm pretty familiar with access control systems. :)
>>>>
>>>> I would say that the access control is happening at the RS. The client
>>>> presents a token when accessing an API.
>>>> The RS uses the token, and any policy required, to make an access
>>>> decision.
>>>>
>>>> Fine. It looks like we are in agreement. Unfortunately, this is not the
>>>> case just below.
>>>>
>>>> Here is flow:
>>>>
>>>> 1) The Client requests access to an RS from the GS.
>>>>
>>>> No. We are no more in agreement. This is different from the flow drawn
>>>> by Francis.
>>>>
>>> My bad. Typo. I meant RO.
>>>
>>>
>>>> 2) The GS queries the RS if access should be granted.
>>>>
>>>>  No. The GS should not be forced to have a flow with the RS.
>>>>
>>> Same mistake as above, I meant RO.
>>>
>>>> 3) If access is granted, the GS creates an access token representing
>>>> the granted access, and returns it to the Client.
>>>>
>>>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>>
>>> I'm unclear on why, or why it is even relevant.
>>>
>>>> 4) The Client presents the access token to the RS to show it has been
>>>> granted access.
>>>>
>>>> No. The client presents a token when accessing an API. The RS uses the
>>>> token, and any policy required, to make an access decision.
>>>> The token never contains an information like "Please grant an access to
>>>> the holder of this token".
>>>>
>>> Let me provide more clarity in the sentence:
>>>
>>> The Client presents the access token to the RS, to show the RS that the
>>> Client has been granted access to a resource at the RS by the GS.
>>>
>>> [Denis] This time, please consider both the ACLs approach and the
>>> Capabilities approach.
>>>
>>>
>>>
>>>> A couple advantages of this model:
>>>> - that the RS does not need to know much, if anything about the Client.
>>>> - the access token MAY be self contained so that the Client does not
>>>> need to query the GS on each access.
>>>>
>>>> There are so many disadvantages that I will not list them.
>>>>
>>> Darn: I clearly was not firing on all cylinders when I typed this out.
>>> Let me correct:
>>>
>>> - the access token MAY be self contained so that the RS does not need to
>>> query the GS on each access to the RS by the Client.
>>>
>>> [Denis] A few comments in the case of a capability approach:
>>>
>>> - for each GS, the RS needs to locally manage which operation(s) is/are
>>> allowed to it.
>>>
>>> - the GS needs to establish a trusted communication channel or an
>>> authentication mechanism with each RO
>>>    (which is associated with an explicit RS identifier).
>>>
>>> - the GS could play the role of the RO and hence be in a position to
>>> issue any capability for any RS (without a "RO consent").
>>>
>>>    The target of an attack will clearly be the GS.
>>>
>>> I would not say that GNAP is an access control protocol, as how the RS
>>>> uses the token to determine access is out of scope.
>>>>
>>>> This is where we have a major discrepancy: how the RS uses the token
>>>> to determine access is *within* the scope.
>>>>
>>> [Denis] Do you agree or disagree ?
>>>
>>> The RS announces in advance to the client what it needs so that the
>>>> client can perform a a given operation and if the client supplies the
>>>> requested attributes
>>>> obtained from some GS/AS(s) trusted by the RS, then access to that RS
>>>> is granted by the RS. If the RS cannot perform the requested operation on
>>>> its own,
>>>> then the client should be informed about some requested attributes that
>>>> need to be obtained from some GS/AS(s) trusted by the next RS(s) in a chain
>>>> for subsequent operations. The User consent should also be obtained
>>>> before performing the chaining operation.
>>>>
>>>> Chaining operations between RSs over the Internet is within the scope
>>>> (... and may be achieved).
>>>>
>>> [Denis] Do you agree or disagree ?
>>>
>>> Denis
>>>
>>>
>>>>>
>>>>>> For many use cases, the User is the RO, and the interaction is
>>>>>> through a user interface, not a machine protocol.
>>>>>>
>>>>>> Wait a second. You wrote "the User is the RO". The User is attempting
>>>>>> to make an access to a RS by using a Client.
>>>>>> *That* User is not the RO of the RS.
>>>>>>
>>>>> The user being the RO is the initial use case for OAuth.
>>>>>
>>>>> OAuth 2.0 is no more mandating such a case.
>>>>>
>>>>
>>>> I don't know what you mean by that.
>>>>
>>>> Copy and paste from draft-ietf-oauth-security-topics:
>>>>
>>>> OAuth initially assumed a static relationship between client,
>>>> authorization server and resource servers.  (...)
>>>> With the increasing adoption of OAuth, this simple model dissolved and,
>>>> in several scenarios, was replaced
>>>> by a dynamic establishment of the relationship between clients on one
>>>> side and the authorization and
>>>> resource servers of a particular deployment on the other side.
>>>>
>>>> This way, the same client could be used to access services of different
>>>> providers (in case of standard APIs,
>>>> such as e-mail or OpenID Connect) or serve as a frontend to a
>>>> particular tenant in a multi-tenancy environment.
>>>>
>>>>
>>> This sentence does not mention the RO or the Client. I'm confused what
>>> we are talking about
>>>
>>>>
>>>>
>>>>> A client application would like access to the user's photos at a photo
>>>>> sharing site. The resource is the user's photos. The user is the owner of
>>>>> that resource.
>>>>>
>>>>> If the user has already pre established the access control policy
>>>>> rules so that it can access to his own photos
>>>>> then he does not need to grant in real time any additional
>>>>> authorization.
>>>>>
>>>> I don't understand what you are trying to say. The photo sharing
>>>> example was a driving use case for the creation of OAuth.
>>>>
>>>> We would need to revisit the original scenario and consider if it can
>>>> be addressed in a different way than the original way.
>>>>
>>> The use case is the same. Is there a different solution you are
>>> proposing?
>>>
>>>
>>>
>>> --
>>> Txauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> ᐧ
>
>
>