Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
Denis <denis.ietf@free.fr> Fri, 24 July 2020 16:08 UTC
Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 1DCFA3A0EAC
for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 09:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.629
X-Spam-Level:
X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001,
HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001,
KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001]
autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EHouRrndzHkE for <txauth@ietfa.amsl.com>;
Fri, 24 Jul 2020 09:08:03 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr
[80.12.242.129])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 7D52D3A0E9C
for <txauth@ietf.org>; Fri, 24 Jul 2020 09:08:02 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d14 with ME
id 747w2300R2bcEcA0347x72; Fri, 24 Jul 2020 18:08:00 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 24 Jul 2020 18:08:00 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt <dick.hardt@gmail.com>
Cc: txauth@ietf.org
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com>
<f00c75a5-f930-81a6-a50e-2eeffedac691@free.fr>
<CAOW4vyOHO1We4UpCPJBKYvj22rsFd1EN6fAXw8w6YOYTUDhF=g@mail.gmail.com>
<aa1381a2-5b11-f7c7-a547-cddb36732c0b@free.fr>
<CAD9ie-t7ZFrODeXy=Xzvsv-6gvUY=KjW0ETf8vJYkW2p=G4boQ@mail.gmail.com>
<CAOW4vyN26rnOFb+vsaxgaMzeBOsyeSUBougvjHuhQkHyYhnn2w@mail.gmail.com>
<b8a83294-771f-c1d7-0956-d0a50accbbb3@free.fr>
<CAD9ie-soUmghr-qxWFRhHkX3rx3qaf3wBqxkwRZ=ZfQaSoDwbw@mail.gmail.com>
<df110f7d-7928-4dd2-9c09-4b169860623a@free.fr>
<CAD9ie-tLpufcTACXxzCER7t=eebnPhNN9VGbyuRgQOHzQ8=Ctg@mail.gmail.com>
<37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>
<CAD9ie-uXgLrkvEJ5txkR2Un9NJ-yfYy0AhE9gZaKvAF8qjqWFw@mail.gmail.com>
<60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>
<CAD9ie-uL_rm73imCe5kMZWd_HvZPQcC_zx3HphHeNXK5JqxNwg@mail.gmail.com>
<c35d8330-780c-231c-2d03-afcc4a671187@free.fr>
<CAD9ie-t1YD+Dx5ssgUoJrGk-PRQF2aiF3Eqgi7Hi0Cm+sOb31Q@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <d983678a-4f32-b4ad-ba2b-f7e563819356@free.fr>
Date: Fri, 24 Jul 2020 18:07:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CAD9ie-t1YD+Dx5ssgUoJrGk-PRQF2aiF3Eqgi7Hi0Cm+sOb31Q@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------5575EDBC1B6F6485968D4F72"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/CU_jM8FNv4ojkwhCyPnxbKCxoPg>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>,
<mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>,
<mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2020 16:08:09 -0000
Hi Dick, draft-hardt-xauth-protocol-13 describes a solution without clearly stating what the problem(s) to be solved is/are. 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. 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 ? Figure 4 shows only a single GS. How would be the data flow when access tokens from two GSs are needed by a RS ? 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. 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). 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 <denis.ietf@free.fr > <mailto:denis.ietf@free.fr>> 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 AccessControl 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 <denis.ietf@free.fr >> <mailto:denis.ietf@free.fr>> 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 <denis.ietf@free.fr >>> <mailto:denis.ietf@free.fr>> 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 >>>> <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> wrote: >>>> >>>> Hi Dick, >>>> >>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis >>>>> <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> >>>>> 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 AccessControl >>> Enforcement Function (AEF) and an AccessControl Decision >>> Function(ADF). >>> >>> AccessControl 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. >>> >>> AccessControl 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 thecontext 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 > Txauth@ietf.org <mailto:Txauth@ietf.org> > https://www.ietf.org/mailman/listinfo/txauth >
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- [Txauth] Reviewing draft-hardt-xauth-protocol-11 Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Tom Jones
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Fabien Imbault
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Tom Jones
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Tom Jones
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Fabien Imbault
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt