Return-Path: 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 3969A3A11A5 for ; Mon, 6 Jul 2020 01:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OIA-Hk_DOBxz for ; Mon, 6 Jul 2020 01:01:28 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A980D3A11A6 for ; Mon, 6 Jul 2020 01:01:28 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id a12so38390828ion.13 for ; Mon, 06 Jul 2020 01:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9S83oqEgGX3KVp3uDjy944qfHd7CvgSMqgDB3mvWsB4=; b=m3zgy63M6ze0YEH6hHFuxcfryVrDv34+zVAazNOPqHyMQDCALfpoLWmmcf9PajywhL WzrtPoYBQLdk51akC5g0IkIYsa5jcoAxO3UHBLWUBUaxzo/+SzCkWcDwoiE6WW1qM51L B4ydTGZsz2eQmZZvYgCFp2jQEVGnLHa7VUq3ghy2XazbjeEsE6k/oIDQ0eJD0kBT82vb HdUW6sJ2K7oa21FvpClAGrG8pYia7E1nxOAas/JFFJmEak/xZkOXRX2nBVYjmvT1i/aM YYeMgnsi5m8TtMWHNr7dF58XHTttw1g+kq/dDg8sTgQdyROl+K4dHAuqXv9PtQ/VmmfD BKyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9S83oqEgGX3KVp3uDjy944qfHd7CvgSMqgDB3mvWsB4=; b=aGVNXU+mnBuaA5RhtU3bwG8TAGXU1eAz1HoeO9NYrIEZg8R6A0XICirgMA3Od1ppHN 9tmIH0RspHkRK1UU6ZYnjAq8g6AsC8HkgCaIepAaoC1wKrFxcKsmUAMpEEzU9qNWmt27 nKPTZAHPD+Pe+8ewhOMnepTqXbkSgW7XxDkKYfQW6vrtMBycYbBfnAF3s8ioPiHsshxY YVhyMOmKtjdP4AgQnJpYGPb2GOTxdpnhUJP/b9xX49ShzL4tLjgmAg5JDawxQcBXRieX SxA4+Dd46C7x1Cm+jBg7veZMbrirLFfxOEWkfAyyONlQBmVnBxkK2RYL+/42/TvbriuQ kvyw== X-Gm-Message-State: AOAM533T8taI/2kHbAoeR4cqQP/tsPWCdcKs3P9G/NLEJ9pH2amoR1TY T4dnRskr+oWD1Gu0H3ai1PYHsEG15dVgGaAXSBg= X-Google-Smtp-Source: ABdhPJyOKU9xjPymLV6/gMnWUr98ZJB+VlmXvGEBcfK8O7pp2aSBU6M69GHyZ6bmJWhUoA6uO+ji41uGqsOV86rEBfw= X-Received: by 2002:a5e:d90c:: with SMTP id n12mr23829674iop.144.1594022487866; Mon, 06 Jul 2020 01:01:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 6 Jul 2020 10:01:16 +0200 Message-ID: To: Justin Richer Cc: Dick Hardt , txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000027433e05a9c1482e" Archived-At: Subject: Re: [Txauth] Additional implementation X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 08:01:31 -0000 --00000000000027433e05a9c1482e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, My experience is that JSONLD is much simpler than RDF (which looks much more alien indeed) and, if done right, wouldn't necessarily be a burden. But of course, we'd have to demonstrate the added value. In any case, I agree that CoAP is a very different issue, and not something I would consider an extension in the sense discussed here. So I agree 100% on that, as well as on the links with other WG. Maybe we could start with some concrete examples of what we would encounter as potential extensions (of course we wouldn't get the full list, but it might help to test a few variants). Cheers. Fabien On Sun, Jul 5, 2020 at 9:15 PM Justin Richer wrote: > Getting the extensibility right is going to be one of the most important > things we need to try to balance in GNAP. I=E2=80=99ve worked with JSONLD= on a few > different things, and overall I=E2=80=99m not a fan of it for managing th= ings like > extensibility. It=E2=80=99s one of those technologies that works great if= you=E2=80=99re > already using it for everything, but it=E2=80=99s a huge learning curve i= f you=E2=80=99re > not in the space at all. Instead I would rather we see extensibility > managed at the JSON level, instead of putting this kind of up-front burde= n > of understanding on developers. > > In XYZ, for example, you can add new items to the top of the request and > response (along side =E2=80=9Ckey=E2=80=9D, =E2=80=9Cresources=E2=80=9D, = =E2=80=9Cuser=E2=80=9D, =E2=80=9Caccess_token=E2=80=9D, and the > like), and these all get their own semantics. Additionally, you can exten= d > the inner parts of the protocol, like the =E2=80=9Cinteraction=E2=80=9D s= ection of the > request can have new interaction capabilities, and the key section can ha= ve > new proofing mechanisms. And perhaps most importantly, the =E2=80=9Cresou= rces=E2=80=9D > sections can have items that are specific to a given API, since all APIs > are potentially different and GNAP shouldn=E2=80=99t make assumptions abo= ut how > they=E2=80=99re structured. The extensibility of all of these can be mana= ged > without using a formal schema language like JSONLD. We can define core > elements in the GNAP spec, and allow extension on a registry, for example= . > Or we could use a name spacing mechanism for some things like the resourc= es > where we expect a lot of variability. > > But not everything outside of our core fits this extension category. I > don=E2=80=99t see CoAP as an extension, for example, because it=E2=80=99s= a replacement for > the whole HTTP/JSON layer, not just the authentication/key-proofing > portions. I don=E2=80=99t think it makes sense to have GNAP be so abstrac= ted away > from HTTP/JSON that we end up with a model/binding style specification, a= nd > that sentiment is built into the proposed charter. An aside, you could do= a > COSE-style signature as a proof mechanism, or a CWK key format, and those > would both be extensions to GNAP, since they could be communicated over t= he > same base protocol. > > And finally, there are going to be parts of the protocol that are > controlled by other working groups and efforts. For instance, someone mig= ht > want to make it possible to return identity information or resource > information directly in the token response, but that=E2=80=99s outside of= what GNAP > is here for. We have agreement to return identifiers for users (so, thing= s > like an issuer/subject pair, an email address, a phone number, etc), but > not profile information or other identity components. > > We=E2=80=99ve got a difficult and important thing to balance here: we nee= d to have > enough detail in the protocol that it=E2=80=99s usable without having to = defer to > other groups or documentation (ie, you shouldn=E2=80=99t need a profile o= f GNAP to > be able to run GNAP), but we need to be flexible enough in our structures > to accommodate new ways of working and doing things, especially when we= =E2=80=99re > looking at things that OAuth 2 is too rigid to handle well, like flexible > interaction methods. > > =E2=80=94 Justin > > On Jul 5, 2020, at 8:47 AM, Fabien Imbault > wrote: > > Hi, > > You're spot on with you last comments, we should stay very clear on claim= s > vs tokens (and indeed they are defined in other working groups). I agree > with that. > > What I'm suggesting is that json-ld may be used as a support for providin= g > context and extendibility capabilities, as it provides a conventional > manner of defining metadata to deliver on the polymorphic feature of the > core protocol. > Request/response (and continuation) endpoints may use this metadata to > adapt their behavior to the capabilities or intent of the other party > (client and AS). The most obvious example is for resources description > ("dolphin-metadata" in the XYZ example), to provide semantic context arou= nd > common access patterns. > > Cheers, > > Fabien > > Le sam. 4 juil. 2020 =C3=A0 03:33, Dick Hardt a = =C3=A9crit : > >> >> >> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault >> wrote: >> >>> Thanks Dick. >>> >>> Likewise, comments inserted (marked with "FI"). >>> >>> On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt wrote: >>> >>>> Hi Fabien, sorry for the late reply >>>> >>>> Comments and questions inserted ... >>>> >>>> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>> >>>>> >>>>> Beyond what I said on the redirect, we could probably benefit from a >>>>> more formal definition of the flows (a bit different between the 2 >>>>> proposals), as proposed recently by Francis Pouatcha for instance >>>>> (interact/decoupled/embedded flows, TBD). >>>>> >>>> >>>> Which proposal was that? >>>> >>> >>> FI : I'll try to find it back. >>> >>>> >>>> >>>>> >>>>> What I'm missing in both proposals (personal opinion): >>>>> >>>>> - I know that JSON is the usual format, but it would be really useful >>>>> to complement the schemas with some JSON-LD descriptions as well. It = would >>>>> ease extensions and interoperability (by avoiding conflicting schemas= ), and >>>>> could even provide a more generic way of representing verifiable >>>>> presentations (challenge/nonce associated to a domain for instance). = While >>>>> most of this work on linked data has been done at W3C, it would add v= alue >>>>> to the current proposal so I think we should consider it. >>>>> >>>> >>>> I'm not understanding how JSON-LD would fit in. Would you provide an >>>> example? >>>> >>> >>> FI : when it comes to extendibility, JSON-LD and JSON schemas could wor= k >>> together to provide a more explicit information on the type of informat= ion >>> we're handling. You'll find a comparison at >>> https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs w= ith >>> standard JWT. In practice, this comes handy as a basis for verified >>> credentials, would clarify the OIDC semantics and disambiguate the mean= ing >>> of specific tokens (see for instance the discussion at >>> https://www.rfc-editor.org/rfc/rfc8417.html#section-4 on "Preventing >>> Confusion between SETs and Other JWTs"). >>> https://w3c.github.io/vc-imp-guide/#extending-jwts provides interesting >>> examples. >>> >> >> It appears that you are proposing the JSON-LD be used in claims? Am I >> correct? Or is there somewhere it would be used in the Grant Request JSO= N? >> >> My understanding of the charter is the GNAP is a transport for claims, >> and that those would be defined somewhere else. OpenID Connect and Verif= ied >> Credentials are good examples. The query for a claims similarly would be >> defined somewhere else. >> >> >>> >>> >>>> >>>>> >>>>> - from an extensibility point of view, I'm not sure it's very useful >>>>> to list all possibilities. For instance, as of now, it wouldn't be po= ssible >>>>> to use the protocol for constrained devices, so there's no real value= in >>>>> saying that it could be extended with CoAP (then we need a separate >>>>> document, that references the current GNAP rfc). What's more useful t= o know >>>>> if the context of the current document, when you're implementing it, = is >>>>> what behaviour can really be extended in a fairly straightforward >>>>> way, without changing anything in the core spec. For instance, what c= an I >>>>> do with other types of tokens than JWT? Neither proposal is very clea= r as >>>>> to how we would implement extensions in practice. >>>>> >>>> >>>> In XAuth I refer to CoAP not as an extension, but as an one example of >>>> other client authentication mechanisms. While it only applies to CoAP,= I >>>> think it is useful to call out how we intend GNAP to be extended. >>>> >>> >>> FI : isn't the charter already covering this? >>> >> >> Yes, but most people that are not in the WG don't read the charter. :) >> >> >>> >>>> Just like OAuth 2.0, the access token is opaque to the client, and it >>>> is not specified, so I'm confused what you mean by "other types of tok= ens >>>> than JWT"? >>>> >>>> FI : I mean, for instance, linked data proofs, macaroons, and so on. >>> >> >> I see. When I read 'token', I think of access tokens. You are referring >> to what I would call a claims, which per above are defined somewhere els= e. >> >> >>> >>>> >>>>> >>>>> - from an implementation perspective, it would make sense to decompos= e >>>>> the flow between the Grant Server (GS) and the login/consent part (as= done >>>>> for instance by ory.sh). This way you would separate the concerns: on= one >>>>> side you have the HTTP flows (managed by the GS, which can be very >>>>> optimized from a backend perspective), but you can delegate/customize= the >>>>> interaction UI to some agreed dedicated endpoint (typically a JS site= ). >>>>> Maybe that's just a detail which doesn't have its place in the spec, = but >>>>> since it would change the flow, it might be important to consider, at= least >>>>> as a possibility/extension. >>>>> >>>> >>>> Is the interaction UI not part of the GS though? I agree that an >>>> implementation can decompose those, but that sounds like an implementa= tion >>>> choice of the GS, and not something that requires standardization. I a= gree >>>> that we want to anticipate the decomposition.* Is there a change in th= e >>>> flow that would make that easier? >>>> >>> >>> FI : I agree with you on the principle. We're currently testing that to >>> make sure the standard is supporting these kind of implementation choic= e. >>> In XYZ, it means changing the URI for the interaction, having an additi= onal >>> nonce for the interact server (maybe we can remove that constraint late= r >>> on, because it changes details in the interaction), and the rest stays = the >>> same. >>> >> >> I'd be interested in the details on how you are implementing it! >> >> >>> >>>> *One of the reasons I favor using URIs and methods for the different >>>> functionality of the GS API is that it is easy for a router to route a >>>> request to different components of the GS. >>>> >>> >>> FI : yes, and that's something interesting that we'll need to discuss >>> further. >>> >> >> :) >> >> >>> >>>> /Dick >>>> >>>>> -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --00000000000027433e05a9c1482e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,=C2=A0

My experien= ce is that JSONLD is much simpler than RDF (which looks much more alien ind= eed) and, if done=C2=A0right, wouldn't necessarily be a burden. But of = course, we'd have to demonstrate the added value.=C2=A0

<= /div>
In any case, I agree that CoAP is a very different issue, and not= something I would consider an extension in the sense discussed here. So I = agree 100% on that, as well as on the links with other=C2=A0WG.
<= br>
Maybe we could start with some concrete examples of what we w= ould encounter as potential extensions (of course we wouldn't get the f= ull list,=C2=A0but it might help to test a few variants).=C2=A0
<= br>
Cheers.

Fabien

On Sun, Jul 5, 2020 = at 9:15 PM Justin Richer <jricher@mit= .edu> wrote:
Getting the extensibility rig= ht is going to be one of the most important things we need to try to balanc= e in GNAP. I=E2=80=99ve worked with JSONLD on a few different things, and o= verall I=E2=80=99m not a fan of it for managing things like extensibility. = It=E2=80=99s one of those technologies that works great if you=E2=80=99re a= lready using it for everything, but it=E2=80=99s a huge learning curve if y= ou=E2=80=99re not in the space at all. Instead I would rather we see extens= ibility managed at the JSON level, instead of putting this kind of up-front= burden of understanding on developers.

In XYZ, for exam= ple, you can add new items to the top of the request and response (along si= de =E2=80=9Ckey=E2=80=9D, =E2=80=9Cresources=E2=80=9D, =E2=80=9Cuser=E2=80= =9D, =E2=80=9Caccess_token=E2=80=9D, and the like), and these all get their= own semantics. Additionally, you can extend the inner parts of the protoco= l, like the =E2=80=9Cinteraction=E2=80=9D section of the request can have n= ew interaction capabilities, and the key section can have new proofing mech= anisms. And perhaps most importantly, the =E2=80=9Cresources=E2=80=9D secti= ons can have items that are specific to a given API, since all APIs are pot= entially different and GNAP shouldn=E2=80=99t make assumptions about how th= ey=E2=80=99re structured. The extensibility of all of these can be managed = without using a formal schema language like JSONLD. We can define core elem= ents in the GNAP spec, and allow extension on a registry, for example. Or w= e could use a name spacing mechanism for some things like the resources whe= re we expect a lot of variability.

But not everyth= ing outside of our core fits this extension category. I don=E2=80=99t see C= oAP as an extension, for example, because it=E2=80=99s a replacement for th= e whole HTTP/JSON layer, not just the authentication/key-proofing portions.= I don=E2=80=99t think it makes sense to have GNAP be so abstracted away fr= om HTTP/JSON that we end up with a model/binding style specification, and t= hat sentiment is built into the proposed charter. An aside, you could do a = COSE-style signature as a proof mechanism, or a CWK key format, and those w= ould both be extensions to GNAP, since they could be communicated over the = same base protocol.

And finally, there are going t= o be parts of the protocol that are controlled by other working groups and = efforts. For instance, someone might want to make it possible to return ide= ntity information or resource information directly in the token response, b= ut that=E2=80=99s outside of what GNAP is here for. We have agreement to re= turn identifiers for users (so, things like an issuer/subject pair, an emai= l address, a phone number, etc), but not profile information or other ident= ity components.=C2=A0

We=E2=80=99ve got a difficul= t and important thing to balance here: we need to have enough detail in the= protocol that it=E2=80=99s usable without having to defer to other groups = or documentation (ie, you shouldn=E2=80=99t need a profile of GNAP to be ab= le to run GNAP), but we need to be flexible enough in our structures to acc= ommodate new ways of working and doing things, especially when we=E2=80=99r= e looking at things that OAuth 2 is too rigid to handle well, like flexible= interaction methods.

=C2=A0=E2=80=94 Justin
=

On Jul 5, 2020, at 8:47 AM, Fa= bien Imbault <fabien.imbault@gmail.com> wrote:

Hi,=C2=A0

You're spot on = with you last comments, we should stay very clear on claims vs tokens (and = indeed they are defined in other working groups). I agree with that.=C2=A0<= /div>

What I'm suggesting = is that json-ld may be used as a support for providing context and extendib= ility capabilities, as it provides a conventional manner of defining metada= ta to deliver on the polymorphic feature of the core protocol.=C2=A0
<= div dir=3D"auto">Request/response (and continuation) endpoints may use this= metadata to adapt their behavior to the capabilities or intent of the othe= r party (client and AS). The most obvious example is for resources descript= ion ("dolphin-metadata" in the XYZ example), to provide semantic = context around common access patterns.=C2=A0

Cheers,

Fabien

Le sam. 4 juil. 2020 =C3=A0 03:33, Dick Hardt <dick.hardt@gmail.com&= gt; a =C3=A9crit=C2=A0:


On Fri, Jul 3, 2020 at 1:19 A= M Fabien Imbault <fabien.imbault@gmail.com> wrote:
Thanks Dick.=C2=A0

Likewise, comments= inserted (marked with "FI").

On Thu, Jul 2, 2020 at 7:34 PM Dick = Hardt <dick.hardt@gmail.com> wrote:
Hi Fabien, sorry f= or the late reply

Comments and questions=C2=A0inserted .= ..=C2=A0

On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
<snip>

Beyond what I said on the redirect, we could probably benef= it from a more formal definition of the flows (a bit different between the = 2 proposals), as proposed recently by Francis Pouatcha for instance (intera= ct/decoupled/embedded flows, TBD).

Which proposal was that?

FI : I'll try to find it back.=C2=A0
=C2=A0

What I'm missing in both proposals (personal opin= ion):=C2=A0

- I know that JSON is the usual format= , but it would be really useful to complement the schemas with some JSON-LD= descriptions as well. It would ease extensions and interoperability (by av= oiding conflicting schemas), and could even provide a more generic way of r= epresenting verifiable presentations (challenge/nonce associated to a domai= n for instance). While most of this work on linked data has been done at W3= C, it would add value to the current proposal so=C2=A0I think we should con= sider it.=C2=A0

I'm not und= erstanding how JSON-LD would fit in. Would you provide an example?

FI : when it comes to extendibili= ty, JSON-LD and JSON schemas could work together to provide a more explicit= information on the type of information we're handling. You'll find= a comparison at=C2=A0https://w3c.github= .io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs=C2=A0with standard = JWT. In practice, this comes handy as a basis for verified credentials, wou= ld clarify the OIDC semantics and disambiguate the meaning of specific toke= ns (see for instance the discussion at=C2=A0https://www.= rfc-editor.org/rfc/rfc8417.html#section-4=C2=A0on "Preventing Conf= usion between SETs and Other JWTs").=C2=A0=C2=A0
https://w3c.github.io/vc-imp-guide/#extending-jwts=C2=A0provides i= nteresting examples.=C2=A0

It appears that you are proposing the JSON-LD be used in claims? Am I cor= rect? Or is there somewhere it would be used in the Grant Request JSON?

My understanding of the charter is the GNAP is a tran= sport for claims, and that those would be defined somewhere else. OpenID Co= nnect and Verified Credentials are good examples. The query for a claims si= milarly would be defined somewhere else.
=C2=A0

=C2=A0

- fro= m an extensibility point of view, I'm not sure it's very useful to = list all possibilities. For instance, as of now, it wouldn't be possibl= e to use the protocol for constrained devices, so there's no real value= in saying that it could be extended with CoAP (then we need a separate doc= ument, that references the current GNAP rfc). What's more useful to kno= w if the context of the current document, when you're implementing it, = is what behaviour can really be extended in a fairly straightforward way,= =C2=A0without changing anything in the core spec. For instance, what can I = do with other types of tokens than JWT? Neither proposal is very clear as t= o how we would implement extensions in practice.

In XAuth I refer to CoAP not as an extension, but as an o= ne example of other client authentication mechanisms. While it only applies= to CoAP, I think it is useful to call out how we intend GNAP to be extende= d.=C2=A0

FI : isn't t= he charter already covering this?=C2=A0
=
Yes, but most people that are not in the WG don't read t= he charter. :)
=C2=A0

Just like OAuth 2.0, the access token is opaque to th= e client, and it is not specified, so I'm confused what you mean by &qu= ot;other types of tokens than JWT"?

FI : I mean, for instance, linked data proofs, macaroons, a= nd so on.=C2=A0

I see. Wh= en I read 'token', I think of access tokens. You are referring to w= hat I would call a claims, which per above are defined somewhere else.
=C2=A0
=C2= =A0

- from an implementation perspective, it would make se= nse to decompose the flow between the Grant Server (GS) and the login/conse= nt part (as done for instance by ory.sh). This way you would separate the c= oncerns: on one side you have the HTTP flows (managed by the GS, which can = be very optimized from a backend perspective), but you can delegate/customi= ze the interaction UI to some agreed dedicated endpoint (typically a JS sit= e). Maybe that's just a detail which doesn't have its place in the = spec, but since it would change the flow, it might be important to consider= ,=C2=A0at least as a possibility/extension.
Is the interaction UI not part of the GS though? I agree that = an implementation can decompose those, but that sounds like an implementati= on choice of the GS, and not something that requires standardization. I agr= ee that we want to anticipate the decomposition.* Is there a change in the = flow that would make that easier?

FI : I agree with you on the principle. We're currently testin= g that to make sure the standard is supporting these kind of implementation= choice. In XYZ, it means changing the URI for the interaction, having an a= dditional nonce for the interact server (maybe we can remove that constrain= t later on, because it changes details in the interaction), and the rest st= ays the same.=C2=A0

I'= ;d be interested in the details on how you are implementing it!
= =C2=A0

*One = of the reasons I favor using URIs and methods for the different functionali= ty=C2=A0of the GS API is that it is easy for a router to route a request to= different components of the GS.

FI : yes, and that's something interesting that we'll need = to discuss further.=C2=A0

:)
=C2=A0
=C2=A0=
/Dick
<= div dir=3D"ltr">
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--00000000000027433e05a9c1482e--